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

[Tom D. <td...@di...>]

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. This won't synthesize properly and causes some 
cosimulation problem, specifically slicing of one of the signals.

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

Tom




Jan Decaluwe wrote:

> Hi all:
>
> Attached you find a snapshot of the myhdl development tree. The
> goal is to implement RAM inference from toVerilog output.
>
> The purpose of this snapshot release is to get feedback from early
> users that are willing to test this. As the implemented features are
> especially useful in combination with the capabilities of external
> tools, their feedback is essential.
>
> Release notes
> =============
>
> The requirements to infer RAM from toVerilog output were discussed
> recently. Two features were implemented:
>
> 1. Support for lists of signals
> -------------------------------
> Lists of Signals are now supported alongside Signals in the
> hierarchy. They are mapped to Verilog memories.
>
> 2. Support to generate Verilog assign statements
> ------------------------------------------------
> always_comb blocks that are simple enough are converted to a series of
> assign statements, instead of a combinatorial always block. Note that
> you do need to use always_comb for this feature; an explicit
> combinatorial generator is not sufficient.
>
> Installation
> ============
>
> Several files have undergone changes; therefore the snapshot consists
> of a complete myhdl package directory. This should be installed as a
> replacement of the myhdl directory in the installed directory.
>
> This snapshot therefore contains several other (undocumented) features
> and improvements outside the specific goal outlined above. Testers
> should be aware of that and be careful, so that they can easily go
> back if required. That being said, all the regression tests run fine,
> of course.
>
> Implementation notes
> ====================
> (Only for those who want to know more implementation details.)
>
> 1. Support for lists of signals
> -------------------------------
> As always, I tried to make the implementation as general as
> possible. Lists of Signals are now handled as a first-class object in
> the hierarchy, alongside Signals. The Signal elements have the same
> restrictions as ordinary Signals, and additional restrictions among
> them. For example, they should all have the same type and bit width.
>
> In Python, it is easy to create lists that share elements. This can
> obviously lead to problems in Verilog conversion. An attempt was made
> to do meaningful things. Several error conditions were added and
> checked to implement meaningful restrictions. But it is possible that
> more will need to be done.
>
> I was pleasantly surprized to see that the existing
> test_RandomScrambler.py test continues to run unmodified, but uses
> memories in the Verilog output now. The usage of Lists of Signals in
> that example is more sophisticated than for a single RAM inference,
> showing that we may have an additional powerful feature now.
>
> 2. Support to generate Verilog assign statements
> ------------------------------------------------
> A simple always_comb block is converted to Verilog assign
> statements. It was reported that Xilinx tools need this to recognize
> RAM templates.
>
> One criterium for "simpleness" is that the block only contains signal
> assignments. However, this is not enough: for example, multiple
> assignments to the same signal are perfectly valid code, but don't
> qualify as simple.
>
> An additional point was that the signals driven by Verilog assignments
> should be declared as wires.
>
> Regards,
>
> Jan
>