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

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

Hi,

I am not quite following this discussion, sorry. 

Just want to make sure we would loose our ability to infer RAMs from lists, I thought that was a 
nice feature.

Tom




On Friday 22 February 2008 07:50:38 am Christopher L. Felton wrote:
> >> 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!