The slightly adapted example below does not work (Object type is not supported in this context: CONTENT, <type 'tuple'>). When the one ROM indexing line is replaced by the two commented lines, it works. I do not understand the essential difference between both ways of writing. So either (1) I missed an essential difference or (2) this is a bug, or any linear combination of the two ;) Please let me know what is (are) the case(s) here.
Thanks in advance,
Sjoerd
def rom(dout, addr, CONTENT):
@always_comb
def read():
dout.next = CONTENT[int(addr)] & addr
#lookup = CONTENT[int(addr)]
#dout.next = lookup & addr
return read
CONTENT = (17, 134, 52, 9)
dout = Signal(intbv(0)[8:])
addr = Signal(intbv(0)[4:])
toVerilog(rom, dout, addr, CONTENT)
toVHDL(rom, dout, addr, CONTENT)
This is documented here:
http://www.myhdl.org/doc/0.6/manual/conversion.html#the-convertible-subset
The problem is that tuple access is expanded inline to a case statement in Verilog and VHDL, for ROM inference. Hence the restrictions. A better way would be to map tuple access to a case statement in a separate function, that could be then be used generally. I'm just not sure whether all relevant synthesis tools will then still be able to do ROM inference for the simple cases - feedback on this e.g. for Xilinx and Altera synthesis is welcome.