Re: [myhdl-list] List of Signals == Memory

[Christopher L. F. <cf...@uc...>]

>> This seems to break a very natural way of writing HDL
>> in python.

The above is definitely a very subjective statement/argument.  Came to  
this conclusion based on my own experience and the other posts.  I  
don't think I articulated my suggestion well.  I believe I understand  
the issues that led to the current implementation (I hope).

I see that  the following may not be desired to be converted directly

   x = [Signal(intbv(0)[8:]) for i in range(4)]

   @always(clk.posedge)
   def rtl():

       for i in range(N):
           x[i] = i
   ...

Converted to Verilog as
	
     reg [7:0] x [0:3];

   always @(posedge clk) begin
       for (i=0; i<4; i=i+1) begin
           x[i] <= i;
       end
   end

In the above example, this is where the Verilog synthesis tools may  
get in trouble because it could infer a block of memory.   The memory  
may not be what the original description was intending.

What I would like to propose is that the toVerilog/toVhdl does a  
little bit more work.  When it comes across a list of signals it  
converts the original MyHDL to the following Verilog.

   reg [7:0] x_los_0;
   reg [7:0] x_los_1;
   reg [7:0] x_los_2;
   reg [7:0] x_los_3;

   always @(posedge clk) begin
       x_los_0 <= 0;
       x_los_1 <= 1;
       x_los_2 <= 2;
       x_los_3 <= 3;
   end

The Verilog/VHDL conversion will unroll the loops so list of signals  
can be used as generic containers etc.  This way the conversion is  
explicit and won't have the potential to confuse the Verilog/VHDL  
synthesis tools.

Then there is the issue of actually describing RAM/ROM and co- 
simulation.  I believe those are solvable issues if the loop-unrolling  
method was adopted.

I believe that the list extraction would allow a MyHDL developer to  
use lists in a very natural way, and the lists would always be  
expanded.  This way you could have complex structures, list of  
signals, inside a list, the python parse/converter will get to the  
primitive type (in this case a signal) and create a unique name that  
represents the structure.

I have looked at the conversion python code some, I believe I know  
where these changes / enhancements could coded.  Maybe after some more  
hashing, if this change seems to make sense I can attempt the change.

> that you're now all struggling with :-)
>
> Before doing anything else, I believe we should now review the  
> assumptions.
> Synthesis tools have evolved and so has Verilog in the mean time.  
> Based on
> that info, we may be able to do something sensible - otherwise we are
> walking in the dark.
>
> Specifically, I'd like to know how memory syntax (including member  
> slicing
> and indexing) is currently supported in (System)Verilog, and in  
> mainstream
> synthesis tools. Anyone with useful info on this - please let us know.

Personally, I like sticking with Verilog 1364-1995(2001), using basics  
of the language and converting more complex MyHDL structures to basic  
Verilog.  This puts more work in the conversion tools and kinda goes  
against the minimalist approach (doh).

> I refer to the thread "RAM inference from toVerilog output" dated  
> 08/09/2005.
> This announces the first release with RAM inteference support.
Hopefully I am not repeating the previous thread (I don't think so), I  
will study this thread a little more.

Thanks for the reply and all the work on MyHDL!