[myhdl-list] RAM inference from toVerilog output
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2005-08-09 19:05:48
|
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 |