Re: [myhdl-list] difficulty using itertools with MyHDL

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

George Pantazopoulos wrote:
>>>So at this point I would look for a workaround and convert
>>>iterator objects to the "officially" supported types
>>>(for behavior or structure) as desired. The advantage is
>>>of course that no change to MyHDL would be required.
>>>
>>>A workaround for your case could be the following. Just use
>>>itertools to set up your iterator as desired. Then convert
>>>it to a generator using a one-liner generator expression, e.g.:
>>>
>>>ordered_tests = (t for t in chain(stage1, stage2, stopsim()))
>>>
>>>This should work for any iterator you can imagine.
>>>
>>>    
> 
> Hi Jan, I like your solution, but I've hit a snag and I'm not sure why 
> I'm getting the error message below. Could you perhaps enlighten me? ;-)

Ok - let's backtrack. You're still doing something different
from what I thought. Actually itertools introduce behavior which
I haven't anticipated (and is currently confusing me).

With a generator expression, you first "unroll" an iterator
and then re-pack it into a generator again. The iterator
in question is a MyHDL generator in your case - so after
"unrolling" it's done,  and that's not what you want.

The error message you get is because something like
   yield delay(1), delay(2)

is not supported by MyHDL (of course, it should be
flagged as an error instead of giving a traceback.) But the
real problem lies elsewhere (that is, the generators
are done already before starting the simulation.)

With itertools, the orignal generators stay "alive" but you
still manage to run their yield statements in "lockstep". This
is something I haven't anticipated. It "works" when using
a real generator (instead of a generator expression)
explicitly as follows:

         c = itertools.izip(driver(sigs), monitor(sigs, cts))
         @instance
         def combo():
             while True:
                 yield c.next()

         return combo

However, I'm really not sure that the interaction of this
with the MyHDL scheduler works meaningfully. Normally the
scheduler should decide when a MyHDL generator is run, and
this seems to inferere with that. I'll have to experiment
with itertools.

I'd also like to go back to what you actually want to
achieve. Running "in lockstep" in event-driven simulation
is best achieved by waiting on signal changes. This should
be possible using "conventional" simulator usage. Perhaps
there are other ways to achieve what you want, or at
least give more insight in the problem.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com