27

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 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?

Stand with Gaza
  • 267
  • 1
  • 8
Philippe
  • 1,422
  • 2
  • 13
  • 26
  • 5
    The "world" is wrong. Smart engineers use std_ulogic as because it has the correct semantics. – wjl Jul 29 '11 at 01: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

4 Answers4

18

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.

wjl
  • 1,042
  • 1
  • 8
  • 17
  • 11
    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
  • Also, the metavalues become "don't care" in synthesis, which allows for more optimizations. – Simon Richter Oct 18 '22 at 13:12
9

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...

Martin Thompson
  • 8,499
  • 1
  • 23
  • 44
  • 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 01:55
  • @wjl: sorry, yes that's what I meant. I'll update the post. – Martin Thompson Jul 29 '11 at 12:25
  • AFAIK, the std_logic and std_ulogic are assignment-compatible since they have the same base type. So, there should be no need for manual conversion. – Val Jun 05 '14 at 14:01
  • @Val: that's what wjl said (and I agree with) - but the *vector port parts still need conversions – Martin Thompson Jun 06 '14 at 07:15
  • I read the specification and wonder why. The arrays must be compatible if elements are. Modelsim says that all you need is vhdl2008 compatibility! – Val Jun 06 '14 at 08:16
  • Just to make sure that I understood the trouble that motivated you to transition from using std_ulogic_vector to std_logic_vector, if it were possible for you to use VHDL-2008 at that time, the problem wouldn't have existed, is that right? – rick Sep 08 '14 at 02:12
  • @rick - yes it was very pre-2008 when I made the shift. – Martin Thompson Sep 08 '14 at 12:02
4

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.

cmarqu
  • 239
  • 1
  • 4
2

I know its a horribly colored ppt slideshow, but it explains the difference pretty good:

http://web.archive.org/web/20151026150828/http://www.cs.auckland.ac.nz/~jmor159/reconfig/ppt/ResolutionFunctions.ppt

betontalpfa
  • 615
  • 1
  • 7
  • 21
Simon
  • 685
  • 5
  • 13
  • 2
    broken link, archived here: http://web.archive.org/web/20151026150828/http://www.cs.auckland.ac.nz/~jmor159/reconfig/ppt/ResolutionFunctions.ppt – LuisF Apr 11 '18 at 08:55