use binary strings instead of hex literals to assign values to signals

[glencoe]

Using binary instead of hex literals allows us to specify signal values that do not lie within the range of n nibbles, thus giving more flexibility.

[julianhoever]

@glencoe I have tested this. Currently we only use hex values in the rom value array. But when I try to synthesize it with Vivado, I get several errors regarding mismatched bit widths:

ERROR: [Synth 8-690] width mismatch in assignment; target has 16 bits, source has 6 bits [/build/fplinear_0/fplinear_0_w_rom.vhd:14]
ERROR: [Synth 8-690] width mismatch in assignment; target has 16 bits, source has 6 bits [/build/fplinear_0/fplinear_0_w_rom.vhd:14]
ERROR: [Synth 8-690] width mismatch in assignment; target has 16 bits, source has 4 bits [/build/fplinear_0/fplinear_0_w_rom.vhd:14]
ERROR: [Synth 8-690] width mismatch in assignment; target has 16 bits, source has 1 bits [/build/fplinear_0/fplinear_0_w_rom.vhd:14]
ERROR: [Synth 8-690] width mismatch in assignment; target has 16 bits, source has 1 bits [/build/fplinear_0/fplinear_0_w_rom.vhd:14]

[...]

Do you think the feature you want is possible with our current templates? Or do we need to create a new rom template to implement it? Or is there a misunderstanding on my side about this issue?

The code you can find in the draft pull request #271

[julianhoever]

When I use the same bit width for all values in a rom file it works ;). I guess it was a misunderstanding from my side that I had implemented different bit widths in a single rom file.