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

[George P. <ge...@ga...>]

Jan Decaluwe wrote:
> 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.
>   
Hi Jan,
  
   I don't have time for a full reply at the moment, but in brief:

   1) I want to run a unit test where there are sequential "stages"

   2) Some of the stages need a driver/monitor pair running "in lockstep".
      The "driver" manipulates the signals going into the dut.
      The "monitor" checks the dut outputs.

      My coding efforts in this thread stem from the above points. Can I 
help you further by elaborating on any of my ideas? I'm confident you 
will come to an understanding soon.

Thanks,
George

> Jan
>
>