Tell me more ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

It seems that the world has decided that std_logic (and std_logic_vector) are the default way of representing bits in VHDL. The alternative would be std_ulogic, which is not resolved.

This surprises me because usually, you're not describing a bus, so you do you don't want multiple drivers and you don't need to resolve a signal. The advantage of std_ulogic would be that the compiler warns you early on if you have multiple drivers.

Question: is this just a cultural / historical thing, or are there still technical reasons to use std_logic?

share|improve this question
1  
The "world" is wrong. Smart engineers use std_ulogic as because it has the correct semantics. – wjl Jul 29 '11 at 1:57
@wjl I'll interpret that as "it's a cultural/historical thing". Your answer below is much more helpful than the comment up here. – Philippe Jul 31 '11 at 18:00
I wrote the comment first, then thought it would be more appropriate to leave an answer with more specifics. Sorry, I guess it does sound a little flippant. But my comment is literal in that most people start out using std_logic because they learned it that way, then after a while they start to wonder about std_ulogic, they look up it, realize it's semantics, and then convert to it. =) – wjl Jul 31 '11 at 23:27

3 Answers

up vote 5 down vote accepted

Std_logic is a subtype of std_ulogic and has exactly one extra property: it's resolved if there are multiple drivers.

Regardless of common practice, std_ulogic is the correct type to use for non-resolved signals that need 9-valued logic. (Often, using "bit" is even more correct -- for instance, on some FPGA architectures that do not have any such thing as an 'X' or a 'U').

Basically, the best thing to do is use the correct type for the job. Often bad practices get propagated by people just parroting the style that they see others use, do without understanding why.

share|improve this answer
2  
The architecture may not have a 'U', but it's often useful to simulate as if it did as you can find incorrect initialisations. +1 for "the best thing to do is use the correct type for the job", but we tend to learn as we go along about what's "best" :) – Martin Thompson Jul 29 '11 at 12:28

My history is this:

I started off (in about 1999 IIRC) using std_ulogic* all the time - as it's the right thing to do, for just the reasons you describe.

Then I had to interface to a bunch of wizard generated vendor IP which all had std_logics all over the interface. Which meant conversions on the port-mappings (for the _vector elements), and I got lazy and moved over to using std_logic*.

However, I seem to make very few "double-driver" mistakes, so I haven't missed std_ulogic as much as I would've thought. And Modelsim's drivers command makes it very easy to find "who is driving what" when I do occasionally need to...

share|improve this answer
Yeah, IP cores (and especially stuff that is automatically translated from Verilog) tends to use std_logic. Your answer seems to suggest that the reason is mostly "cultural/historical". – Philippe Jul 28 '11 at 20:14
You never have to convert between std_logic and std_ulogic on ports. Did you mean you had to convert between std_logic_vector and std_ulogic_vector? – wjl Jul 29 '11 at 1:55
@wjl: sorry, yes that's what I meant. I'll update the post. – Martin Thompson Jul 29 '11 at 12:25

IIRC the famed Reuse Methodology Manual recommended std_logic(_vector), so maybe methodology groups in companies etc. spread that further in the form of (mandatory) coding guides. Personally, +1 for using std_ulogic when possible.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.