BIT, STD_LOGIC,STD_ULOGIC

[RealInfo]

Hi all

There is some dilema that allways confuses me.

When I define signals and ports , which declaration is to be used ?
BIT , STD_LOGIC or STD_ULOGIC ???

What is the exact criterion to follow in the first stages of design and
declarations ?

Thanks in advance
EC

 

[no_spa2005]

std_logic

 

[Andy Peters]

Hi all

There is some dilema that allways confuses me.

When I define signals and ports , which declaration is to be used ?
BIT , STD_LOGIC or STD_ULOGIC ???

What is the exact criterion to follow in the first stages of design and
declarations ?

Use std_logic and std_logic_vector.

The bit type knows only about '1' and '0'. std_logic adds more useful
modeling constructs such as 'Z' (high-impedance), 'X' (conflicted or
unknown), 'U' (undriven), etc. std_ulogic is "unresolved," meaning
that you have to provide a resolution function to handle things like
tristate logic.

For entities that are internal to a design (meaning not brought to I/O
pins), then you can use numeric_std's unsigned and signed types, too.
Actually, you can use integer types, too, if you constrain the sizes.

The reason you probably shouldn't use unsigned or signed types at I/O
pins is because the tools might have issues with it. Specifically,
most FPGA tools create a post-P&R timing model and those ports are
always std_logic, so you can't use a test bench that expects the ports
to be something else.

-a

 

[KJ]

Hi all

There is some dilema that allways confuses me.

When I define signals and ports , which declaration is to be used ?
BIT , STD_LOGIC or STD_ULOGIC ???

What is the exact criterion to follow in the first stages of design and
declarations ?

For the top level entity in a design (assuming FPGA or CPLD, etc.),
use std_logic. This can facilitate
- Using the model within a CAD system produced VHDL netlist of a PCBA
- Switching a testbench model to the post-route netlist version if you
choose to run simulations with the post-route code.

For all other entities and all internal signals
- Use std_ulogic if the signal can only have one driver.
- Use std_logic if the signal can legitimately have more than one
driver.

If you choose to use std_logic all the time (many do) you will have to
find cases where you inadvertently connected multiple outputs
together. In order to find these cases you can
- (quick way) Synthesize the design, multiple outputs will cause an
error.
- (slow way) Simulate and debug.

If you use std_ulogic where appropriate, then simply compiling the
file with a simulator will immediately flag the error (faster than
running a synthesis tool).

Don't bother using type bit, it's lack of an unknown (i.e.
std_ulogic's 'U', 'X', 'W') can lead one to believe that the design is
'working' when in fact it will not.

KJ

 

[Dave]

Hi all

There is some dilema that allways confuses me.

When I define signals and ports , which declaration is to be used ?
BIT , STD_LOGIC or STD_ULOGIC ???

What is the exact criterion to follow in the first stages of design and
declarations ?

Thanks in advance
EC

Almost everyone uses std_logic and std_ulogic instead of the bit type,
because they are so much more flexible. They allow not only the values
of '1' and '0', but also a host of other values to represent other
states such as a high-impedance state ('Z'), a weak pull-up ('W'),
pull-ups and pull-downs ('H' and 'L'), unknown ('X'), don't care
('-'), and undefined ('U'). So I would definitely say not to use bit.

Most of the time, std_logic is all you need. It is a resolved type,
meaning that if you have multiple drivers of the same net, there is a
function which defines what the overall value of the signal will be.
For instance, if I have a std_logic signal some_sig, and I drive it
with a 'L' pull-down in one process, but drive it with a '1' in
another process, the signal will have the value '1', since the
resolution function dictates that driving a signal overrides the pull-
down, which is exactly the behavior that would happen in real life.
The resolution function provides the complete set of rules for any
combination of drivers.

Sometimes, you may want to guarantee that a signal does not have
multiple drivers on it, and in that case, you might choose to use
std_ulogic. This type is exactly like std_logic in that is has 9
values, but no resolution function, so if there are multiple drivers,
an error will result in both simulation and synthesis.

When you're doing math, it is often most convenient to use the signed
and unsigned types from the ieee.numeric_std library. These are base
on std_logic, and are resolved the same way that std_logic is, but
have the added benefit that mathematical operators are defined for
them. Do not ever use the std_logic_arith, std_logic_signed, or
std_logic_unsigned libraries.

Hope this helps.

Dave

 

[Nicholas Collin Paul Gloucester]

|-----------|
|"std_logic"|
|-----------|

I disagree. Use std_ulogic instead.

 

[RealInfo]

Many thanks for all those who took time and effor to answer my question .

Be well
EC


"Dave" <[email protected]> ???
??????:[email protected]...

Hi all

There is some dilema that allways confuses me.

When I define signals and ports , which declaration is to be used ?
BIT , STD_LOGIC or STD_ULOGIC ???

What is the exact criterion to follow in the first stages of design and
declarations ?

Thanks in advance
EC

Almost everyone uses std_logic and std_ulogic instead of the bit type,
because they are so much more flexible. They allow not only the values
of '1' and '0', but also a host of other values to represent other
states such as a high-impedance state ('Z'), a weak pull-up ('W'),
pull-ups and pull-downs ('H' and 'L'), unknown ('X'), don't care
('-'), and undefined ('U'). So I would definitely say not to use bit.

Most of the time, std_logic is all you need. It is a resolved type,
meaning that if you have multiple drivers of the same net, there is a
function which defines what the overall value of the signal will be.
For instance, if I have a std_logic signal some_sig, and I drive it
with a 'L' pull-down in one process, but drive it with a '1' in
another process, the signal will have the value '1', since the
resolution function dictates that driving a signal overrides the pull-
down, which is exactly the behavior that would happen in real life.
The resolution function provides the complete set of rules for any
combination of drivers.

Sometimes, you may want to guarantee that a signal does not have
multiple drivers on it, and in that case, you might choose to use
std_ulogic. This type is exactly like std_logic in that is has 9
values, but no resolution function, so if there are multiple drivers,
an error will result in both simulation and synthesis.

When you're doing math, it is often most convenient to use the signed
and unsigned types from the ieee.numeric_std library. These are base
on std_logic, and are resolved the same way that std_logic is, but
have the added benefit that mathematical operators are defined for
them. Do not ever use the std_logic_arith, std_logic_signed, or
std_logic_unsigned libraries.

Hope this helps.

Dave

 

[kennheinrich]

|-----------|
|"std_logic"|
|-----------|

I disagree. Use std_ulogic instead.

Sure, but...

The use of std_ulogic (as opposed to std_logic) has the characteristic
that all tri-state buffers will need to be instantiated explicitly in
the design. The automatic inference of tristate buffers for external
bus interface logic is, IMHO, a very elegant and concise capability of
the language and of (most) tools, and is reasonably well supported by
the major synthesis players. Mandating std_ulogic is right up there
with mandating SPICE netlists as your root design base. (Well, OK, I'm
exaggerating a little, but I hope you get my drift).

I once did a spec in which I required all our top-level FPGA designers
(let's say tens of them) to manually instantiate tri-state buffers on
a bus interface, in order to preserve exactly the clarity and
exactness of purpose to which I suspect you're alluding. Can you
guess how many of them got it right on the first, second, or third
tries, and how many bloody emails I had to respond to, about something
as trivial as a tri-state buffer? Finding the right balance of
pragmatism and aesthetic design purity isn't always easy :-(

- Kenn

 

[Thomas Stanka]

Sure, but...

The use of std_ulogic (as opposed to std_logic) has the characteristic
that all tri-state buffers will need to be instantiated explicitly in
the design. The automatic inference of tristate buffers for external
bus interface logic is, IMHO, a very elegant and concise capability of

Especially if you like to see internal tristate in places the designer
didn't intend to :=).

I prefer to have the tristates on a higher level of design hierarchy
and not (as often seen) on the ff descirption. This is important for
code reusability, to allow including of existing code without
inspecting each ff description.

bye Thomas

 

[Dave Farrance]

I once did a spec in which I required all our top-level FPGA designers
(let's say tens of them) to manually instantiate tri-state buffers on
a bus interface, in order to preserve exactly the clarity and
exactness of purpose to which I suspect you're alluding. Can you
guess how many of them got it right on the first, second, or third
tries, and how many bloody emails I had to respond to, about something
as trivial as a tri-state buffer? Finding the right balance of
pragmatism and aesthetic design purity isn't always easy :-(

Sorry, but I have to ask too. What do you mean by manually instantiating
a tristate?

I just put a bunch of lines like the following in the top-level module,
one line for each tristate output, which seems to me to be compact and
unambiguous:

FOO <= FOO_RD when (OE = '1') else 'Z';

 

[kennheinrich]

Sorry, but I have to ask too. What do you mean by manually instantiating
a tristate?

I just put a bunch of lines like the following in the top-level module,
one line for each tristate output, which seems to me to be compact and
unambiguous:

FOO <= FOO_RD when (OE = '1') else 'Z';

Yes, it's reasonably compact and unambiguous. But someone always
thinks it was supposed to be active high versus active low, or forgets
to put that key line in when building the final chip and kills the
whole CPU bus, or in the heat of the moment accidentally writes an
open collector output by mis-typing the one-line template, or uses the
wrong OE, or something along those lines. It's amazing how many ways
there can be to mis-interpret one line of code. Not because the guys
doing it are dumb, it's just Murphy's law.

- Kenn

 

[KJ]

Yes, it's reasonably compact and unambiguous. But someone always
thinks it was supposed to be active high versus active low, or forgets
to put that key line in when building the final chip and kills the
whole CPU bus, or in the heat of the moment accidentally writes an
open collector output by mis-typing the one-line template, or uses the
wrong OE, or something along those lines. It's amazing how many ways
there can be to mis-interpret one line of code. Not because the guys
doing it are dumb, it's just Murphy's law.

That's why you use a simulator and why you should model the actual PCBA and
use as one of your testbenches.

Kevin Jennings

 

[Nicholas Collin Paul Gloucester]

On 2009-01-09, (e-mail address removed) <[email protected]>
wrote:

|----------------------------------------------------------------------|
|"[..] |
| |
|[..], in order to preserve exactly the clarity and |
|exactness of purpose to which I suspect you're alluding." |
|----------------------------------------------------------------------|

You gave me more credit than I deserve.

|----------------------------------------------------------------------|
|"[..] Finding the right balance of |
|pragmatism and aesthetic design purity isn't always easy :-( " |
|----------------------------------------------------------------------|

Truly. There can be no completely satisfactory balance.

 

[Dave]

Many thanks for all those who took time and effor to answer my question .

Be well
EC

You may also want to keep in mind that, when using std_logic and
std_ulogic, in the following code

if some_sig = '0' then
sig2 <= '1';
else
sig2 <= '0';
end if;

sig will get '0' in simulation, even if some_sig's value is 'X', 'U',
'L', or anything other than '0'. There is a function which is
sometimes useful called to_X01, which will map the nine possible
values into three like so:

'1', 'H' => '1'
'0', 'L' => '0'
'X', 'U', '-', 'W', 'Z' => 'X'

Similarly, there is a to_X01Z function which also preserves the 'Z'
value if you'd like. They work on std_logic, std_ulogic,
std_logic_vector, and std_ulogic_vector.

Also, does anyone here know if there are any plans in the VHDL
language to allow the '-' to represent a don't-care value in
conditional and case statements for synthesis? I thought I had heard
somewhere that this idea was possibly going to be in the next
iteration.

Dave

 

[HT-Lab]

Many thanks for all those who took time and effor to answer my question .

Be well
EC

..>.
Also, does anyone here know if there are any plans in the VHDL
language to allow the '-' to represent a don't-care value in
conditional and case statements for synthesis? I thought I had heard
somewhere that this idea was possibly going to be in the next
iteration.

Dave

Yes, from Jim Lewis' presentation (www.synthworks.com) VHDL2008 will support
his, example:

-- Priority Encoder
process (Request)
begin
case? Request is
when "1---" => Grant <= "1000" ;
when "01--" => Grant <= "0100" ;
when "001-" => Grant <= "0010" ;
when "0001" => Grant <= "0001" ;
when others => Grant <= "0000" ;
end case ;
end process ;

So far only Aldec supports part of this new standard,

Hans.
www.ht-lab.com

 

[kennheinrich]

That's why you use a simulator and why you should model the actual PCBA and
use as one of your testbenches.

Kevin Jennings

Can't argue with that! It's interesting that, for every subtle,
nuanced, and intricate bug that trips you up, there's also a stupid,
simple bug that more attention to "the basics" and good design
practices should have caught. You can spend man-months designing an
insanely complicated design, simulate the heck out of it, then get
tripped up because the DRAM clock on the PCB got the + and - phases
the wrong way 'round.

- Kenn

 

[beky4kr]

Hi all

There is some dilema that allways confuses me.

When I define signals and ports , which declaration is to be used ?
BIT , STD_LOGIC or STD_ULOGIC ???

What is the exact criterion to follow in the first stages of design and
declarations ?

Thanks in advance
EC

I rarely see people use bit. I assume if your design is large, memory
consumption (by the simulator) is an issue. std logic takes more
memory, as it has more states than 0 and 1 (U, Z, X, L, H).
You may want to use bit where there is a single driver to a net.

Some VHDL and VERILOG free examples at:http://bknpk.no-ip.biz/
index.html