MyHDL Discourse

VHDL Bit string representation



MyHDL to VHDL converter use to write bit strings in binary format.
However, MyHDL generates VHDL2008 code. So instead of generating big binary bit string it would be better to generate hexadecimal bit string.
For example, for a 37bits bit vector :
17179869184 can be written B"0010000000000000000000000000000000000"
17179869184 can also be written 37X"400000000"

Hexadecimal format is much more readable .

I propose to use hexadecimal format instead of binary format when generating VHDL.



@DrPi This definitely would be better. And shouldn’t be hard to do.



@DrPi Do you have a small working example for this? I’m a bit lazy …
I introduced a new attribute for toVHDL: standard which default value ‘2008’.



This is not really difficult but this is not very easy either.

First problem :

>>> "%X" % 12
>>> "%X" % -12

I guess this is because ints have no length. So with the expected result, like “FFF4”, Python does not know how many “F” it has to write.
So, we have to manually manage the negative numbers.

Second problem :
bin() function is also used to write single bit values (std_logic). So we have to carefully search for all bin() occurrences and analyse for which kind of signal the function is called.

Third problem :
Managing signal length is not so easy. -12 is written differently depending on the signal size :

  • 5 bits : 5X"14"
  • 6 bits : 6X"34"
  • 7 bits : 7X"74"
  • 8 bits : 8X"F4"
    However, solving first problem should solve this one.

What is the purpose of standard attribute ?


It would have been nice it you had made an example test case …

  1. this is handled by the signed/unsigned-ness of the intbv
  2. the bin() function can be replaced by a self.BitRepr() method (which is already available in the toVHDL class), also the MyHDL bin() function collides with the standard built-in function.
  3. the nX"value" syntax allows for zero or sign extension … so we can write it as 8SX"14" ->

The standard attribute is to allow us to generate also VHDL1993 compliant output.


Are you talking about a test case for all possibilities or just a simple case ?

Currently, the generated VHDL already requires a VHDL-2008 compliant synthesiser. There is no way to generate VHDL-93 code.


Sure. But you can import it with another name.


I think we have to generate full size values. Relying on VHDL bit sign extension is risky.


Something like this should work as long as you know the intended size (which, of course, is the tricky part):

def hexstring(value, nrbits):
    length = nrbits // 4 + ((nrbits % 4) != 0)
    value2c = value if value >= 0 else 2**nrbits + value
    return '%dX"%0*X"' % (nrbits, length, value2c)


@mhavu Yes, something like this. This is a smart implementation.
I didn’t know we can pass the number of digits with * like in ‘%0*X’.
I prefer to use length = (nrbits+3) // 4. You save a modulo operation and a comparison :wink:


That’s a nice optimization. Let’s see if I remember it the next time I need to round something up. :smiley:


Is it? So this must have crept in silently … But OK we can do without this standard then.

yes, but still it would require editing the code, so another name altogether would be better?
The BitRepr method is not in the toVHDL class, but in the (base) ConvertVisitor class. So I propose to use (and improve) this method instead of the bin() function.

Fair enough, as explicit is better than implicit


Or: It won’t hurt having it?


For sure, it won’t hurt :slight_smile:

I can’t find anywhere it is specified the synthesiser has to HVDL-2008 compliant. What I am sure is that if I don’t select the VHDL-2008 option in Diamond (Lattice) or in Vivado (Xilinx), the sources will not synthesise.
Maybe, MyHDL generates VHDL-2002 compliant files but this does not matter since synthesisers are either VHDL-93 or VHDL-2008 compliant today.
I remember upgrading Vivado last year since each new version enhanced the support of VHDL-2008.


Found it !


So Henry did it! And our BDFL specifically stated that from then on VHDL-2008 would be the norm. But it was updated in the docs …