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
