Thread: [myhdl-list] ROM inference from toVerilog output
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2005-08-19 16:02:05
Attachments:
myhdl.tar.gz
|
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 -- 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 |
From: Tom D. <td...@di...> - 2005-08-22 17:53:48
|
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. 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 > |
From: Jan D. <ja...@ja...> - 2005-08-25 09:10:33
|
--- 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 > |