In the past I had quite successfully implemented the method recommended by Gaisler. http://www.gaisler.com/doc/vhdl2proc.pdf Using variables instead of signals prevent insertion of delta time (which might boost simulation quite a lot).
Kind regards, Alain > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Tuesday, December 27, 2011 12:17 PM > To: Péteut, Alain (SPACE) > Cc: [email protected] > Subject: Re: migen, inout signals? > > Alain, > > On Tue, 27 Dec 2011 02:24:30 +0000, Péteut wrote: > > I'm currently writing a vhdl backend for migen > > Note that the Verilog backend itself is still in a rather early stage. > > Its most serious problem, which I plan to address soon, is that > putting > all combinatorial statements into one always block (i.e. process) can > cause a very problematic situation in the simulator where that block > is > run in an endless loop without giving other blocks a chance to run. > What > happens is that the block causes delta-delayed events on every > single > output signals of the block every time it is run. If some outputs of > that block also are its inputs, the simulator simply adds those to the > sensitivity list, and the simulator will run the block in a loop since > there are always events on the signals in the sensitivity list - even > though the value of those signals may not have changed! > > I find it a bit baffling that hardware designers have to waste their > time with that sort of issue. Well, so much for the event-driven > model... > > So - the Migen back-end must break down the large comb > block/process > into smaller blocks with healthier sensitivity lists. I also suspect > that having large comb blocks has a lot of potential for simulation > slow-down, as it turns out that simulators are stupid enough to even > run > into the endless loop described above. > > Other than that, you will need a respectable set of rules to generate > VHDL from the FHDL AST, handling all the annoying corner cases > correctly > (I conveniently escape these problems by letting Verilog provide > most of > the semantics). For example, the VHDL code for a 8-bit adder with > carry > output is quite an ugly mess, while it can be expressed simply in > Verilog or FHDL with something like this: > > wire [7:0] a, b; > wire carry; > wire [7:0] result; > assign {carry, result} = a + b; > > > and wonder now how to > > treat inout signals (verilog.py handles 'output reg', 'output', > > 'input'). > > FHDL signals are unidirectional, so there's no need for internal inout > ports. There's almost never a good reason for having internal tri- > states > in a modern chip, and as a matter of fact, FPGA architectures more > recent than the Spartan-2 do not have them.(*) > > However, tri-stated I/O makes sense, and is not currently supported > by > Migen, but I plan to add this feature. I would do it the following way: > * Having a way to tell the back-end to transform a (OE, I, O) signal > triplet into an inout port. Only the back-end would see the inout > port, > the rest of the Migen system sees three basic, unidirectional > signals. > * Propagating inout ports from instances to the top-level ports. > > (*) You may be mislead by the fact that those internal tri-states can > often be synthesized for recent FPGAs. But what happens in reality is > the FPGA tools attempt to silently replace them with unidirectional > signals and combinatorial glue logic in order to support legacy > designs. > > Best regards, > Sebastien > > PS: Please use the mailing list for such questions. _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
