Should we use std_logic or std_ulogic?

[Paebbels]

While PCB signals in an I²C interface need resolution capabilities, type std_logic is fixed. But what about fabric internal signals. Here is no multiple-source behavior / driving value resolution needed. Moreover, std_ulogic could prevent lots of coding errors.

Earlier revisions of the VHDL language had problem, because std_logic_vector and std_ulogic_vector where not compatible. This was changed in VHDL-2008.

I propose to skip the std_logic only rule and propose:

• Use std_ulogic and std_ulogic_vector for fabric internal interfaces
• Limit usage of std_logic and std_logic_vector to external interfaces (PCB level) where multiple driven wires are needed.
• Use unresolved_unsigned for address buses.
  Note: unsigned has also an unresolved variant.

---

/cc @JimLewis, @LarsAsplund

[JimLewis]

Agree

[LarsAsplund]

I've never really worked with std_ulogic because of old habits and compatibility issues. It should be the better option so why not.

[Paebbels]

@LarsAsplund I think compatibility issues have been solved since years, but no one tried if it works now :).

[NJDFan]

The compatibility issues I've run into are with brand X synthesis tools, and largely revolve around the redefinition of the vectors in 2008. Given that all this is only even a discussion if 2019 is well supported, compatibility shouldn't be an issue.

…

On Sat, Jul 18, 2020, 14:59 Patrick Lehmann ***@***.***> wrote: @LarsAsplund <https://github.com/LarsAsplund> I think compatibility issues have been solved since years, but no one tried if it works now :). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBCACBL5TYYUCTXSQM3JYTR4ILMXANCNFSM4OQTMLAA> .