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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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