std_logic vs bit

[Mohammed A.khader]

Hi all;

The significance of std_ulogic is to simulate the digital circuits
at electrical level, for synthesis it does'nt have any significance.
So when I write code for RTL synthesis I can use binary logic since
this the one which is going to be implemented. But many books suggest
to use std_logic though I am not using any buses . My question is why
should one choose other than bit logic for RTL synthesis . (Expection
is std_logic for bus).

Thanks in advance.

Regards,
A.khader.

 

[Nicolas Matringe]

Mohammed A.khader a écrit:

Hi all;

The significance of std_ulogic is to simulate the digital circuits
at electrical level, for synthesis it does'nt have any significance.
So when I write code for RTL synthesis I can use binary logic since
this the one which is going to be implemented. But many books suggest
to use std_logic though I am not using any buses . My question is why
should one choose other than bit logic for RTL synthesis . (Expection
is std_logic for bus).

Hi
There are many reasons.
If you use std_logic for busses, you will need std_logic for its
elements, logic feeding it or being fed by it, unless you want to use
conversion function.
You design for synthesis, that's OK. We all do that too. But before you
implement your code you will have to simulate it, and std_logic is much
nicer than bit (unitialized or conflicting signals appear, for example)

These are the 2 reasons that come to my mind but I'm sure I can think of
others )

 

[David Bishop]

Hi all;

The significance of std_ulogic is to simulate the digital circuits
at electrical level, for synthesis it does'nt have any significance.
So when I write code for RTL synthesis I can use binary logic since
this the one which is going to be implemented. But many books suggest
to use std_logic though I am not using any buses . My question is why
should one choose other than bit logic for RTL synthesis . (Expection
is std_logic for bus).

There is a reason for this, but it's a silly one.

It turns out that in many synthesis tools, no matter what type
you give your ports (std_ulogic, std_ulogic_vector, signed, unsigned
bit_vector, etc) will always output ports of the type "std_logic_vector"
or "std_logic".

What I tell users to do is to make your ports at your top level
std_logic_vector and std_logic, then convert them to a more useful
type on the lower level.

 

[Mohammed A.khader]

Hi
There are many reasons.
If you use std_logic for busses, you will need std_logic for its
elements, logic feeding it or being fed by it, unless you want to use
conversion function.

Yes, you are right, std_logic is needed for busses but all the
other logic is of type bit. conversion functions can be used once to
change logic to & fro std_logic.Using std_logic logic for this only
reason for the whole system makes the simulator much slower.

You design for synthesis, that's OK. We all do that too. But before you
implement your code you will have to simulate it, and std_logic is much
nicer than bit (unitialized or conflicting signals appear, for example)

No, If a desingner assigns multiple sources to a signal mistakenly
then simulator would'nt show it as a error(mistake).

These are the 2 reasons that come to my mind but I'm sure I can think of
others )

Waiting for your more resons...

To believe as you think please answer one more question.
what would synthesis tool would do if I write this code.....

All signals are of type std_logic.
process (SEL, A, B, C, D)
begin
case SEL is
when "00" => MUX_OUT <= A;
when "01" => MUX_OUT <= B;
when "10" => MUX_OUT <= C;
when "11" => MUX_OUT <= D;
when others => MUX_OUT <= 'X';
end case;
end process;

what would synthesis tool would do if 1)I declare signals as of type
bit 2)I declare signals as of type std_logic.(what would it do with
others clause in this case).

Thanks in Advance.

Regards,
Mohamemd A.khader.

 

[valentin tihomirov]

Yes, you are right, std_logic is needed for busses but all the

other logic is of type bit.

I was sure it is bit_vector that is needed for describing buses.

 

[rickman]

I was sure it is bit_vector that is needed for describing buses.

The term bus is being misused to describe a signal shared between
multiple sources. Think tri-state bus.

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

To believe as you think please answer one more question.
what would synthesis tool would do if I write this code.....

All signals are of type std_logic.
process (SEL, A, B, C, D)
begin
case SEL is
when "00" => MUX_OUT <= A;
when "01" => MUX_OUT <= B;
when "10" => MUX_OUT <= C;
when "11" => MUX_OUT <= D;
when others => MUX_OUT <= 'X';
end case;
end process;

I believe synthesis tools ignore the others since all of the states of
interest to a synthesis tool have been listed. You will get warnings in
a simulator, but in synthesis you can leave off the "others" clause.

what would synthesis tool would do if 1)I declare signals as of type
bit 2)I declare signals as of type std_logic.(what would it do with
others clause in this case).

The same in both cases. Why don't you try it and let us know if you get
a difference?


--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[ivailokroumov]

Hi Mohammed,
You know me just through my e-mail. I am Ivaylo Krumov from Bulgaria.
About your question
"My question is why should one choose other than bit logic for RTL
synthesis"
You should use std_logic because it can be syntesisable and this type
cover different electronic levels. You know that has logic "0" and logic
"1" where represent LOW and HIGH levels It's OK of course, these are real
representation about 0 Voltage and Vcc. Actually this is something
relative. For digital circuits are recognized different Vil, Vih, Vol and
Voh. These are different logic levels. And of course, if you use TTL logi
they are with values Vil belongs between 0 and 0,8V and Vih belongs
between 2V and 5V. Vol belongs between 0 and 0.4V VoH belongs between 2.4V
and 5V. These values are different for other kind logic like LV, CMOS,
HCMOS, HCTMOS, F, ALS, ALVC e.g.
In this way, imagine that you operate with 2-input XOR and need to manage
input_A with different bits either "0" or "1" Actually You can connect
this input directly to ground or Vcc. it is going to be either HARD 1 or
HARD 0 and if you use bit type everything is OK. But imagine that you are
going to connect this input through resistor, it's going to represent wake
"0" or wake "1" Actually these aren't real "0" and "1" and if you use bit
type, you cann't produce implementation. At rise time of digital
electronic and design different company showed up to 46 different leves
for coverring. So you neet to use std_logic or std_logic_vector if you
wish to make syntesisable models and to see real design. But if you wish
just to make models or design, for simulation, no problem to use bit or
bit_vector.
At the other view point, has difference betweeen std_logic and std_ulogic,
std_logic_vector and std_ulogic_vector. The difference is that std_ulogic
or std_ulogic_vector kinds are used in components that have JUST one
driving source. Where as The signals aren't share between the sources
Best Regards:
Ivaylo Krumov

 

[Jim Lewis]

Mohammed,

process (SEL, A, B, C, D)
begin
case SEL is
when "00" => MUX_OUT <= A;
when "01" => MUX_OUT <= B;
when "10" => MUX_OUT <= C;
when "11" => MUX_OUT <= D;
when others => MUX_OUT <= 'X';
end case;
end process;

what would synthesis tool would do if 1)I declare signals as of type
bit 2)I declare signals as of type std_logic.(what would it do with
others clause in this case).

1) Syntax error: bit does not support an 'X'
However, once you fix that, I would expect both to be
the same.

The real difference is in simulation. Since bit does not
have an 'X', it gets a '0' at initialization. Hence,
what happens if you forget to reset the register that
drives SEL? With bit it looks like it was reset, with
std_logic it has "UU" and propagates the 'X'.

I have heard of projects where they have spent many iterations
through synthesis just to get all the required registers reset.

If you have a sound reset strategy, perhaps it does not matter.
However, does bit really buy you simulation performance?
Logically maybe, but what happens after optimization?

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Mike Treseler]

What I tell users to do is to make your ports at your top level
std_logic_vector and std_logic, then convert them to a more useful
type on the lower level.

For vectors, I agree.
For in or out bit ports, std_ulogic will map
without conversion to a std_logic wrapper port.

--Mike Treseler

 

[Mohammed A.khader]

Hi JIM,

Consider the code below……

ARCHITECTURE arch OF nothing IS

BEGIN

PROCESS(a,b,c)
BEGIN
…
z <= not b;
…
END PROCESS;

PROCESS(e,f,g)
BEGIN
…
z <= e and f;
…….
END PROCESS;

END ARCHITECTURE arch;


If the above signals are std_logic then above example WILL NOT
give any ERROR when simulated. Though my intention was not to make a
buffer (multiple source) there (Suppose it was mistakenly assigned 2
times to z).
Ok I accept the the advantages of detecting uninitialized signals etc
from the above discussion . std_logic type is a resolved type so use
it for that purpose. The function of detecting uninitized signals can
be done by using std_ulogic too.

Regards,
Mohammed Khader.

 

[Jim Lewis]

Mohammed,
I too would prefer to have chosen an unresolved type
as our base - like std_ulogic, however, I cannot undo
what is already done (note this did not stop me from
proposing it).

Given that we are stuck with std_logic, what you really
want is for a simulator to warn you during compilation
that a signal that does not have a tristate is multiply
driven. I think I have seen this from some newer tools.
If your tool is not doing this, it would not be unreasonable
to ask them to.

Cheers,
Jim

Consider the code below……

ARCHITECTURE arch OF nothing IS

BEGIN

PROCESS(a,b,c)
BEGIN
…
z <= not b;
…
END PROCESS;

PROCESS(e,f,g)
BEGIN
…
z <= e and f;
…….
END PROCESS;

END ARCHITECTURE arch;


If the above signals are std_logic then above example WILL NOT
give any ERROR when simulated. Though my intention was not to make a
buffer (multiple source) there (Suppose it was mistakenly assigned 2
times to z).
Ok I accept the the advantages of detecting uninitialized signals etc
from the above discussion . std_logic type is a resolved type so use
it for that purpose. The function of detecting uninitized signals can
be done by using std_ulogic too.

Regards,
Mohammed Khader.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~