Connecting "signed" to "std_logic_vector" ports.
in [FPGA]
|
Prev: sdram stable clock
Next: temporal logic folding
From: Andrew Feldhaus on 26 Jul 2010 08:30 Hi, As I understand it, good practice dictates that in a synthesis-targeted setting, components should use ports of type std_logic or std_logic_vector only. Certainly Xilinx's IP generation tools provide components with this philosophy. My design is well-suited to the use of signed types from IEEE.Numeric_Std. From my investigations I believe that the correct way to connect signed signals to std_logic_vector ports is by converting the types in the component instantiation port map. E.g., where x and y are compatibly- sized signed signals: U1: somedevice port map ( DIN => std_logic_vector(x), signed(DOUT) => y); Xilinx ISE (12.1) simulates this without problems. Xilinx XST complains, however, with "ERROR:Xst:1539 - <VHDL file name> line xx: Formal port in component U1 must be an identifier". The obvious work-around, suggested at http://www.xilinx.com/support/answers/18188.htm, is to add a signal: signal U1DOUT : std_logic_vector(7 downto 0); .... y < signed(U1DOUT); U1: somedevice port map ( DIN => std_logic_vector(x), DOUT => U1DOUT); This is pretty ugly and gets uglier with dynamic widths, "generate" statements and so on. Is the simpler approach above invalid VHDL or is XST just exhibiting yet more broken behaviour? Thanks in advance, 0xADF
From: rickman on 26 Jul 2010 10:27 On Jul 26, 8:30 am, Andrew Feldhaus <Re...(a)thread.pls> wrote: > Hi, > > As I understand it, good practice dictates that in a synthesis-targeted > setting, components should use ports of type std_logic or std_logic_vector > only. > > Certainly Xilinx's IP generation tools provide components with this > philosophy. > > My design is well-suited to the use of signed types from IEEE.Numeric_Std.. > > From my investigations I believe that the correct way to connect signed > signals to std_logic_vector ports is by converting the types in the > component instantiation port map. E.g., where x and y are compatibly- > sized signed signals: > > U1: somedevice > port map ( DIN => std_logic_vector(x), > signed(DOUT) => y); > > Xilinx ISE (12.1) simulates this without problems. > > Xilinx XST complains, however, with "ERROR:Xst:1539 - <VHDL file name> > line xx: Formal port in component U1 must be an identifier". The obvious > work-around, suggested athttp://www.xilinx.com/support/answers/18188.htm, > is to add a signal: > > signal U1DOUT : std_logic_vector(7 downto 0); > ... > y < signed(U1DOUT); > U1: somedevice > port map ( DIN => std_logic_vector(x), > DOUT => U1DOUT); > > This is pretty ugly and gets uglier with dynamic widths, "generate" > statements and so on. Is the simpler approach above invalid VHDL or is > XST just exhibiting yet more broken behaviour? > > Thanks in advance, > > 0xADF I don't recall the syntax used for conversions in port maps. Have you tried port map ( DIN => std_logic_vector(x), DOUT => std_logic_vector(y)); I just use the clunkier method you outline above since this seems to be a sticky issue with various tools. Better to have the code work across tools than to worry about being "pretty". BTW, you use the term "correct" to describe the port map conversion. If it doesn't work, then I don't consider it to be "correct". Git 'er done! Rick
From: KJ on 26 Jul 2010 11:53 On Jul 26, 8:30 am, Andrew Feldhaus <Re...(a)thread.pls> wrote: > > This is pretty ugly and gets uglier with dynamic widths, "generate" > statements and so on. Is the simpler approach above invalid VHDL or is > XST just exhibiting yet more broken behaviour? > The code is correct, brand X tools are deficient in this instance. One way to hide the ugliness a bit is to create a wrapper around the X generated IP that then has the interface that you want. Then do the work around in the architecture of the wrapper. If you're only using a small number of such IP blocks but instantiating them several places this may not be too bad. If you only instantiate the IP block once, and you're married to using X and their toolset then you'll have to live with the workaround. KJ
From: KJ on 26 Jul 2010 11:57 On Jul 26, 10:27 am, rickman <gnu...(a)gmail.com> wrote: > If it doesn't > work, then I don't consider it to be "correct". > If 'it' is the brand X tools, then I agree. If 'it' is standard compliant code that is not being processed properly by brand X tools, then I disagree. Correctness is determined by compliance to the standard, not to some lowest common denominator implementation of that standard. The need to get the job done though is determined by working around whatever shortcomings come along with the tools and parts that have been chosen. KJ
From: Martin Thompson on 27 Jul 2010 03:57
Andrew Feldhaus <Reply(a)thread.pls> writes: > Hi, > > As I understand it, good practice dictates that in a synthesis-targeted > setting, components should use ports of type std_logic or std_logic_vector > only. I'd disagree. I use numeric (and other) types all the time on component ports (integers, unsigneds, records...). Only on the topmost entity do I stick to std_logic(_vector)s throughout - simply because it means I can drop the post-synth or post-PAR netlist straight into my topmost testbench without having to faff around writing a wrapper. > > Certainly Xilinx's IP generation tools provide components with this > philosophy. > Hmmm, yes. They also produce use "ieee.std_logic_arith.all" clauses by default (unless that changed in 12.1). They (vendors' example code) are not the best place to find best-practise :) > My design is well-suited to the use of signed types from IEEE.Numeric_Std. > By all means use them - I don't think XST has a problem synthesising them. I've snipped the rest of your, post, as I think you're better off using the appropriate types, rather than trying to force them all to by std_logics (But I can't see anything wrong with what you've done either.) Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardware |