[myhdl-list] Re: RAM inference from toVerilog output

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

Tom Dillon wrote:
> Jan,
> 
> Thanks for the update. So far it is making memories properly including 
> true dual port rams with separate always blocks. I will run some more 
> cases over the next few days.
> 
> One problem, it looks like all lists of signals are being mapped to 
> memory structures in Verilog, even true lists of signals as described in 
> 3.1.2 of the manual.

Yes. I figured this would be a feature :-)

> This won't synthesize properly and causes some
> cosimulation problem, specifically slicing of one of the signals.

Well spotted. I agree that this will cause problems.

> Is it possible for you to distinguish between a list for memory and a 
> true list of signals?

Yes. The difference is that a list intended for a memory will only
contain "anonymous" signals. They can only be accessed through list
indexing. In the other type of usage (as described in the manual) the
signals in the list will have a regular signal name at other levels of
the hierarchy. In this case, as the output Verilog code is flat,
the convertor has to choose which name to keep and declare: the "memory"
name, or the signal names.

In the code snapshot, the "memory" name is kept when it is higher in the
hierarchy. But this has problems as you point out. So instead, the
signal names should always be used when available. For conversion
purposes, such a list name cannot be referenced inside a generator -
this will result in an error.

I have already modified the code an checked it in. My test suite
continues to run unchanged, but now again signals are used in
the output of test_RandomScrambler.py. The code will be included
in a future snapshot with additional features - but you can thus
assume that it will work as desired.

Regards, 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