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

[Jan D. <ja...@ja...>]

--- Tom Dillon <td...@di...> wrote:

> Jan,
> 
> This version works very well. All list of signals
> troubles are fixed.
> 
> The only trouble I'm having is with dual port ROMs.
> I am checking to see 
> how to fix that. I don't think the dual case
> statement is the answer.

What is the Verilog coding style to infer this, if
any?

I see the issue: expansion into a case removes info
and makes it hard to infer that this can be "shared"
resource. The Verilog code would have to keep the info
about the original list in some way.  Using a function
perhaps?`

Jan
> 
> Thanks for the new features, they are very useful.
> 
> Tom
> 
> 
> 
> 
> Jan Decaluwe wrote:
> 
> > Hi all:
> >
> > Attached you find a snapshot of the myhdl
> development tree. The
> > goal is to implement ROM inference from toVerilog
> output. This
> > snapshot is for testing purposes.
> >
> > Release notes
> > =============
> >
> > The requirements to infer ROMs from toVerilog
> output were discussed
> > recently. See the discussions elsewhere in the
> mailing list for
> > more background.
> >
> > A tuple of ints is conceptually viewed as a ROM,
> and indexing it
> > is viewed as accessing the ROM. If such indexing
> is the RHS of
> > an assignment, that assignment is mapped to a case
> statement
> > in Verilog, with a case item per address. This is
> done because
> > certain synthesis tools know how to map such code
> into a ROM.
> >
> > The tuple of ints can be defined at the same
> places where signals
> > can be defined, that is, outside generators.
> (Note:
> > everything outside a generator is "elaborated" by
> the Python
> > intepreter.)
> >
> > This snapshot also changes the rules for mapping
> lists of signals
> > to memories in the Verilog output. Only lists of
> "anonymous" signals
> > (signals that don't have a name at any
> hierarchical level) are
> > mapped to memories. This preserves both the older
> functionality
> > and the new functionality for RAM inference.
> >
> > Note: in the near future, I won't use the mailing
> list for snapshots,
> > but the MyHDL web site once it has been
> "wikified".
> >
> > Installation
> > ============
> >
> > This snapshot should be installed as a replacement
> of the myhdl
> > subdirectory in the installation directory.
> >
> > Regards,
> >
> > Jan
> >
> 
> 
>
-------------------------------------------------------
> SF.Net email is Sponsored by the Better Software
> Conference & EXPO
> September 19-22, 2005 * San Francisco, CA *
> Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects
> & Teams * Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
>