Connecting "signed" to "std_logic_vector" ports.
in [FPGA]
|
Prev: sdram stable clock
Next: temporal logic folding
From: Kolja Sulimma on 27 Jul 2010 11:30 On 27 Jul., 09:57, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > Andrew Feldhaus <Re...(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. Why? Todays FPGAs don't even have tristate buffers internally so STD_ULOGIC is clearly more appropriate than STD_LOGIC. It simulates faster and there are bugs that can be found by the synthesis tools earlier in the build process (i.e. signals with multiple drivers) SIGNED and UNSIGNED are subtypes of STD_LOGIC, so there should be no issue whatsoever in synthesizing them. Some synthesis tools throw away the type information when creating timing simulation models and replace them with STD_LOGIC which clearly is a bug of the tools. It is very easy to write a Perl script that puts the type information back in so there plainly is no excuse for the tools to do that. Kolja
From: rickman on 28 Jul 2010 19:05 On Jul 27, 11:30 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > On 27 Jul., 09:57, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > > > Andrew Feldhaus <Re...(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. > > Why? > Todays FPGAs don't even have tristate buffers internally so STD_ULOGIC > is clearly more > appropriate than STD_LOGIC. > It simulates faster and there are bugs that can be found by the > synthesis tools earlier in the > build process (i.e. signals with multiple drivers) > > SIGNED and UNSIGNED are subtypes of STD_LOGIC, so there should be no > issue whatsoever > in synthesizing them. > > Some synthesis tools throw away the type information when creating > timing simulation models > and replace them with STD_LOGIC which clearly is a bug of the tools. > It is very easy to write a Perl script that puts the type information > back in so there plainly is no excuse > for the tools to do that. > > Kolja I was giving consideration to using STD_ULOGIC, but I actually mostly use signed and unsigned for vectors and I believe they are implemented as subtypes of std_logic_vector, no? So I could use STD_ULOGIC for the control signals, but my buses would still essentially be STD_LOGIC. Would that really speed up my simulations much? I do appreciate the superior bug catching of using STD_ULOGIC, that is why I was thinking about changing my default type. But I am concerned that the conversion routines in numeric_std won't work with STD_ULOGIC and I would have to add yet another layer of conversion text. VHDL is already wordy, I hate to add to that. Rick
From: KJ on 28 Jul 2010 20:34 On Jul 28, 7:05 pm, rickman <gnu...(a)gmail.com> wrote: > On Jul 27, 11:30 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > > I was giving consideration to using STD_ULOGIC, but I actually mostly > use signed and unsigned for vectors and I believe they are implemented > as subtypes of std_logic_vector, no? No, they are implemented as arrays of std_logic. Signed, unsigned and std_logic_vector have exactly the same definition... type UNSIGNED is array (NATURAL range <>) of STD_LOGIC; type SIGNED is array (NATURAL range <>) of STD_LOGIC; TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic; Even though they have the same definition, because they are declared as *type* and not *subtype* it means that you can't just assign something of one type to something else of another. From earlier posts, I know that this is a gripe of yours, but that's the way strong type checking works. > I do appreciate the superior bug catching of using STD_ULOGIC, that is > why I was thinking about changing my default type. But I am concerned > that the conversion routines in numeric_std won't work with STD_ULOGIC > and I would have to add yet another layer of conversion text. There aren't any *extra* conversions caused by using std_ulogic versus std_logic, you will have to change some existing conversions though.... Instead of this: Some_slv_sig <= std_logic_vector(Some_unsigned); Do this Some_slv_sig <= std_ulogic_vector(Some_unsigned); Kevin Jennings
From: KJ on 28 Jul 2010 20:39 On Jul 27, 11:30 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > > SIGNED and UNSIGNED are subtypes of STD_LOGIC, Not quite...the definitions are: type UNSIGNED is array (NATURAL range <>) of STD_LOGIC; type SIGNED is array (NATURAL range <>) of STD_LOGIC; TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic; Kevin Jennings
From: Kolja Sulimma on 29 Jul 2010 06:43
On 29 Jul., 02:34, KJ <kkjenni...(a)sbcglobal.net> wrote: > Instead of this: > Some_slv_sig <= std_logic_vector(Some_unsigned); > Do this > Some_slv_sig <= std_ulogic_vector(Some_unsigned); a package numeric_unresolved would be nice.... Kolja |