[myhdl-list] Re: toVerilog and memories

[Jan D. <ja...@ja...>]

Tom Dillon wrote:

> ROMs are also needed and easy to infer in synthesis. It would be very 
> good if the following would produce a case statement in Verilog:
> 
> def rom(dout,addr,clk=None,dataL=None) :
>  """
>    rom : rom module
> 
>    Inputs:
>      addr        : input address
>      clk         : clock for synchronous roms, == None for async
>    Outputs:
>      dout        : output port, width determines width of rom
>    Params:
>      dataL       : list of values for rom, length is depth of rom
>  """
> 
>  memL = [intbv(data,min=dout._min,max=dout._max) for data in dataL]
>    while 1:
>        yield posedge(clk)
>        dout.next = memL[int(addr)]
> 
> 
> You would need to be able to figure out that the values in memL never 
> get modified after it is defined.
> 
> The important thing here, is the memL define and the dout.next 
> assignment need to get mapped to a case statement:
> 
> always @(posedge clk)
>  case(addr) :
>    0 : dout <= dataL[0] ;
>    1 : dout <= dataL[1] ;
>    .
>    .

I like this. It is a feature where conversion can have an additional
productivity advantage, as as lists/tuples of constants are easier
to create and maintain in Python than in Verilog.

Now for the details:

It's not necessary to use an additional memL object - the code could
just simply refer to the defining list dataL instead. That list would
not be present in Verilog - all constants would be directly present
in the code. I assume that's Ok for the synthesis tools?

There's no need for these constants to be intbv's - plain int's
are just fine and easier.

To make sure that a list of constants cannot be modified outside
the scope of toVerilog, I propose to use a tuple instead. Note
that a tuple cannot be modified after creation, which maps nicely
to the concept of a Rom. No doubt this may cause some initial
confusion with users who use lists for everything, but I think
it's worthwhile to document and explain this. Note that a
tuple can easily be created from a list:

    t = tuple(AnyList)

So in short: a tuple of ints used in an assignment in the way you
described, would be expanded into an equivalent case statement.

About the case statement: should it have synthesis attributes like
parallel_case, full_case? Should there be a default fallback or
not?

> Now you may also want some control around this, or possibly asynchronous 
> so only the list needs to become the case statement, that case statement 
> may end up inside come control statements. Possibly a clock enable.
> 
> This is very helpful. There are also dual port ROMs, so you would need 
> two case statements on the same list, with a separate address into the 
> list.

All the above will come without additional effort. The high-level
assignment will be mapped to a case statement, and all context
that surrounds it will be there as usual.

I have an initial implementation ready along the lines above and
I could generate a new snapshot. If there is feedback, send it
quickly because next week I have another assignment.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html