Tom Dillon wrote:
> I was trying to make a variable pipeline module with the following code:
>
> def pipe(q, d, clk, stages=1):
> """ pipe block
> q -- output, delayed d by stages pipe delays
> d -- input
> clk -- clock input
> stages -- number of pipeline delays, 0 is no pipes
> """
> qReg = [Signal(intbv(0,0,q.max)) for i in range(stages)]
> while 1:
> if stages == 0 :
> yield d
> q.next = d
> else :
> yield posedge(clk)
> if stages == 1 :
> q.next = d
> else :
> qReg[0].next = d
> q.next = qReg[stages-2]
> for i in range(stages-2) :
> qReg[i+1].next = qReg[i]
>
> It simulates fine but the list of signals (qReg[]) isn't liked by the
> Verilog converter.
>
> stages is meant to be a compile time parameter and I would like to make
> a variable number of signals based upon its value. Then easily use them
> else where in the module.
>
> If indeed this can't be converted, is there a simple way to accomplish
> this.
At this moment, a list of signals itself is not mapped directly to Verilog.
Whether this would be possible or meaningful, using a Verilog memory, I'm not
sure. Verilog memories have certain strange restrictions,
and they may not be supported by synthesis.
This doesn't mean that you can't use lists of signals - the trick is to
make sure to use them only during "elaboration". In other words, the
restrictions to Verilog conversion only apply to the things at the
lowest level - the generators. At the higher levels of the hierarchy,
where you use plain functions, you have a lot of freedom, because
the hierarchy is "elaborated" by the interpreter before conversion.
BTW, the above explains also why I took this approach, as opposed to
trying to map the inferred hierarchy to Verilog. The way it is now,
you may be able to things that you couldn't do in Verilog (of
course) but *still* be able to convert!
Take a look at the test_RandomScrambler.py code in the
myhdl/test/toVerilog directory for an example.
[Sidenote: there is one disturbing issue that I still need to solve.
If you use lists of instances, where the instance is the result of
a direct generator call, conversion may not work. It has to do with
the difference between a plain function and a generator as seen by
the profiler. The workaround is to convert the generator into a
plain function with a local generator. If this sounds confusing,
again see test_RandomScrambler for an example (XorGate).]
Hope this helps,
Jan
--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Python is fun, and now you can design hardware with it:
http://jandecaluwe.com/Tools/MyHDL/Overview.html
|
