myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] myhdl.SimulationError: Inappriopriate argument type: <type 'NoneType'>

[Shakthi K. <sha...@gm...>]

Hi,

--- On Sat, Sep 3, 2011 at 1:55 PM, Jan Decaluwe <ja...@ja...> wrote:
| Indentation issue, HelloWorld() should return sayHello.
\--

Thanks! That fixed it.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: [myhdl-list] myhdl.SimulationError: Inappriopriate argument type: <type 'NoneType'>

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

On 09/03/2011 04:48 AM, Shakthi Kannan wrote:
> Hi,
>
> I am trying the HelloWorld example from the manual on Python 2.7 with
> python-myhdl (0.7) on Fedora 14.
>
> === hello1.py ===
>
> #!/usr/bin/python
>
> from myhdl import Signal, delay, always, now, Simulation
>
> def HelloWorld():
>      interval = delay(10)
>
>      @always(interval)
>      def sayHello():
>          print "%s Hello World!" % now()
>
>          return sayHello
>

>
> What could be the problem?
>
> SK
>
Indentation issue, HelloWorld() should return sayHello.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

[myhdl-list] myhdl.SimulationError: Inappriopriate argument type: <type 'NoneType'>

[Shakthi K. <sha...@gm...>]

Hi,

I am trying the HelloWorld example from the manual on Python 2.7 with
python-myhdl (0.7) on Fedora 14.

=== hello1.py ===

#!/usr/bin/python

from myhdl import Signal, delay, always, now, Simulation

def HelloWorld():
    interval = delay(10)

    @always(interval)
    def sayHello():
        print "%s Hello World!" % now()

        return sayHello

inst = HelloWorld()
sim = Simulation(inst)
sim.run(30)

=== END ===

I get the following error in the output when running, python hello1.py:

=== OUTPUT ===

$  python hello1.py
Traceback (most recent call last):
  File "hello1.py", line 15, in <module>
    sim = Simulation(inst)
  File "/usr/lib/python2.7/site-packages/myhdl/_Simulation.py", line
64, in __init__
    self._waiters, self._cosim = _makeWaiters(arglist)
  File "/usr/lib/python2.7/site-packages/myhdl/_Simulation.py", line
222, in _makeWaiters
    raise SimulationError(_error.ArgType, str(type(arg)))
myhdl.SimulationError: Inappriopriate argument type: <type 'NoneType'>

=== END ===

What could be the problem?

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: [myhdl-list] Convertible records

[Sébastien B. <seb...@mi...>]

On 09/02/2011 09:56 PM, Christopher Felton wrote:
> You could add signals as you
> like.  Then the converter would look at the final configuration and
> still get a list of signals.

Well, then it's dynamic :)

Re: [myhdl-list] Convertible records

[Christopher F. <chr...@gm...>]

On 9/2/2011 2:39 PM, Sébastien Bourdeauducq wrote:
> On 09/02/2011 09:20 PM, Christopher Felton wrote:
>> should limit the discussion to building
>> objects similar to VHDL record and SV struct
>
> Hmm, this would be of little help for the high level synthesizer I'm
> trying to develop :-) I tend to think I need dynamically built structures.
>

Doh, but the first post (start of the conversation) was this simple type?

    class Binary:
	def __init__(self):
	   self.a = Signal(intbv()[32:])
	   self.b = Signal(intbv()[32:])

In general, I don't think it would be a big issue.  If something like 
the SignalStruct was used dynamically.  You could add signals as you 
like.  Then the converter would look at the final configuration and 
still get a list of signals.

But I kinda want to wrap my head around the declarative types first 
(converter issues, etc) without closing the door on the dynamic.  I 
think I am struggling with a use case were dynamic is more useful than 
the declarative.

Regards,
Chris

Re: [myhdl-list] Convertible records

[Sébastien B. <seb...@mi...>]

On 09/02/2011 09:20 PM, Christopher Felton wrote:
> should limit the discussion to building
> objects similar to VHDL record and SV struct

Hmm, this would be of little help for the high level synthesizer I'm 
trying to develop :-) I tend to think I need dynamically built structures.

Re: [myhdl-list] Convertible records

[Christopher F. <chr...@gm...>]

On 9/2/2011 1:57 PM, Sébastien Bourdeauducq wrote:
> On 09/02/2011 08:15 PM, Jan Langer wrote:
>> maybe it would be a good idea to let the converter "ask" the class how
>> it wants to be converted
>
> Can't you infer the list of signals to convert from which ones get
> actually used?
>
> What would be good imo (but with my limited knowledge of Python, I don't
> know if it's possible) is to simply name signal objects in the generated
> HDL according to how they were created. For example:
>
> class some_class()
> 	def __init__(x):
> 		self.some_signal = x

I think, similar to the previous examples, we want the class with 
signals to be declarative and not dynamically building.  Not that they 
can't be, but for a start should limit the discussion to building 
objects similar to VHDL record and SV struct. (??)

The SignalStruct is a basic container of Signals.  At least for 
conversion, modeling you can do all kinds of cool stuff.  If you 
encapsulate an interface (collection of signals) into a class 
(SignalStruct) you can build in balun circuits :)  Think they are also 
know as transactors or interfaces abstractions.


> (...)
> b = Signal(bool(0))
> some_object = some_class(b)
> toVerilog(some_object.method)
>    =>  gives a signal named "b"
>
> class some_class()
> 	def __init__():
> 		self.some_signal = Signal(bool(0))
> (...)
> some_object = some_class()
> toVerilog(some_object.method)
>    =>  gives a signal named "some_object_some_signal"
>
> (We should adopt a better naming scheme to guarantee the absence of
> collisions, but you get the idea)
>
> This way (I believe) we could happily play with Python objects and still
> make nicely convertible/synthesizable code.
>
> For ports, we can maybe give references to signal objects we want
> exported to the conversion functions.

I think the port can be the class object, for the previous example

   bus1 = MyBus()
   bus2 = MyBus()
   arb  = MyBusArb(bus1, bus2)  # <-- RTL module

The converter will check the types, and will be ok with the port types 
because it will know how to handle them.

Regards,
Chris

Re: [myhdl-list] Convertible records

[Christopher F. <chr...@gm...>]

On 9/2/2011 1:15 PM, Jan Langer wrote:
> Hi all,
>
> Am 02.09.2011 um 18:06 schrieb Christopher Felton:
>> How the conversion analyzer works now, it looks at free variables (not
>> sure what a free variable is) and checks the type.  If the type were
>> to
>> be any class (object) the converter has to do more work to determine
>> if
>> appropriate signals exist in the class.  If the converter can check
>> for
>> a particular type (base class) then it knows it has signals and can
>> extract.  Make sense?  Maybe the AST easily supports this and the base
>> class is not needed.
>
>
> maybe it would be a good idea to let the converter "ask" the class how
> it wants to be converted. In a very simple case something like:
>
> class SignalStruct:
> 	def __signals__(self):
> 		return self.a,self.b
>
> Jan
>


My thought was something like this:

   class SignalStruct(object):
      def __init__(self):
         pass

      def __signals__(self):
         return self.__dict__


   class MyBus(SignalStruct):
       def __init__(self):
           self.addr = Signal(intbv(0)[16:])
           self.data = Signal(intbv(0)[8:])


   bus = MyBus()
   bus.__signals__()
   # This will return the signal objects with the names, the function
   # can also inspect each of the dict elemets and make sure they are
   # the correct types.

At this point, I think (naively) this is a big chunk.  This private 
function (__signals__) will need to dig deeper for embedded 
SignalStructs etc.

.chris

Re: [myhdl-list] Convertible records

[Sébastien B. <seb...@mi...>]

On 09/02/2011 08:15 PM, Jan Langer wrote:
> maybe it would be a good idea to let the converter "ask" the class how
> it wants to be converted

Can't you infer the list of signals to convert from which ones get 
actually used?

What would be good imo (but with my limited knowledge of Python, I don't 
know if it's possible) is to simply name signal objects in the generated 
HDL according to how they were created. For example:

class some_class()
	def __init__(x):
		self.some_signal = x
(...)
b = Signal(bool(0))
some_object = some_class(b)
toVerilog(some_object.method)
  => gives a signal named "b"

class some_class()
	def __init__():
		self.some_signal = Signal(bool(0))
(...)
some_object = some_class()
toVerilog(some_object.method)
  => gives a signal named "some_object_some_signal"

(We should adopt a better naming scheme to guarantee the absence of 
collisions, but you get the idea)

This way (I believe) we could happily play with Python objects and still 
make nicely convertible/synthesizable code.

For ports, we can maybe give references to signal objects we want 
exported to the conversion functions.

Any comments?

Re: [myhdl-list] Convertible records

[Jan L. <jan...@et...>]

Hi all,

Am 02.09.2011 um 18:06 schrieb Christopher Felton:
> How the conversion analyzer works now, it looks at free variables (not
> sure what a free variable is) and checks the type.  If the type were  
> to
> be any class (object) the converter has to do more work to determine  
> if
> appropriate signals exist in the class.  If the converter can check  
> for
> a particular type (base class) then it knows it has signals and can
> extract.  Make sense?  Maybe the AST easily supports this and the base
> class is not needed.


maybe it would be a good idea to let the converter "ask" the class how  
it wants to be converted. In a very simple case something like:

class SignalStruct:
	def __signals__(self):
		return self.a,self.b

Jan

-- 
Jan Langer
Professorship Circuit and System Design
Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz
Phone: +49 37209 688001, Fax: +49 371 531-833158, Mobile: +49 162  
9847325
http://www.tu-chemnitz.de/etit/sse

Re: [myhdl-list] Convertible records

[Christopher F. <chr...@gm...>]

On 9/2/2011 10:35 AM, Sébastien Bourdeauducq wrote:
> On 09/02/2011 04:24 PM, Christopher Felton wrote:
>> My basic thought would be to create a type in MyHDL, SignalStruct, and
>> then create long unique variable names in the converted HDL.
>>
>> Example:
>>
>>       class MyBus(SignalStruct):
>>           def __init__(self):
>>               self.addr = Signal(intbv(0)[16:])
>>               self.data = Signal(intbv(0)[8:])
>>               # ...
>
> I'm not sure having the base "SignalStruct" would be even necessary. A
> regular object should be enough (and potentially more flexible), no?
>
> i.e. "class MyBus():" could just work as well..
>

Yes, at this point I don't have any justification for having a base 
class.  It is just a gut feeling that have a specific base class will be 
useful (user shows intent).

How the conversion analyzer works now, it looks at free variables (not 
sure what a free variable is) and checks the type.  If the type were to 
be any class (object) the converter has to do more work to determine if 
appropriate signals exist in the class.  If the converter can check for 
a particular type (base class) then it knows it has signals and can 
extract.  Make sense?  Maybe the AST easily supports this and the base 
class is not needed.

The second part would be that the base class can have helper functions 
(again, this is a gut and not fully thought out) to help the conversion. 
  Instead of the conversion analyzer having to jump down the class 
hierarchy, the SignalStruct can return signals (and signals of self 
object signals :) ).

Regards,
Chris

Re: [myhdl-list] Convertible records

[Sébastien B. <seb...@mi...>]

On 09/02/2011 04:24 PM, Christopher Felton wrote:
> My basic thought would be to create a type in MyHDL, SignalStruct, and
> then create long unique variable names in the converted HDL.
>
> Example:
>
>      class MyBus(SignalStruct):
>          def __init__(self):
>              self.addr = Signal(intbv(0)[16:])
>              self.data = Signal(intbv(0)[8:])
>              # ...

I'm not sure having the base "SignalStruct" would be even necessary. A 
regular object should be enough (and potentially more flexible), no?

i.e. "class MyBus():" could just work as well..

Re: [myhdl-list] Convertible records

[Christopher F. <chr...@gm...>]

On 9/2/2011 8:53 AM, Sébastien Bourdeauducq wrote:
> On 09/02/2011 03:45 PM, Christopher Felton wrote:
>> A class/object that contains signals will not be converted.
>
> How difficult do you think it would be to get that to work?
>
> An alternative for me is the conversion of signal lists as parameters to
> the top functions, but this is not supported either.
>
> Which of the two is easier to implement?

Correct, neither of these are supported.  I don't know how much effort 
it would require to support these feature.  But I wouldn't mind 
researching this feature, because I recently also had a need to use a 
record type to convert some VHDL to MyHDL.

My basic thought would be to create a type in MyHDL, SignalStruct, and 
then create long unique variable names in the converted HDL.

Example:

    class MyBus(SignalStruct):
        def __init__(self):
            self.addr = Signal(intbv(0)[16:])
            self.data = Signal(intbv(0)[8:])
            # ...

    # ... some code
    bus = MyBus()
    # ... some generator
       bus.addr.next = x
       bus.data.next = y

The the converter, when in encountered a SignalStruct in the port list 
(parameter) or generator it would simple expand the name.
    // example of converted code
    bus_addr_mybus_t = x
    bus_data_mybus_t = y


The generated code would be a little obfuscated but I think the 
generated code should attempt to use the basics of the underlying HDL. 
This way, the Verilog can be Verilog and not SV.  The base class 
SignalStruct is used to guide the converters and built it can contain 
helper functions.

I am not familiar enough with the backend conversion to determine how 
much work it would be to find the primitive Signal type from a composite 
type in the converters.  But it seems like a nice enhancement and I 
would be willing to take it on.  But I have a couple other things I am 
trying to complete currently, it would need to be added to the queue.

Regards,
Chris Felton

Re: [myhdl-list] Convertible records

[Sébastien B. <seb...@mi...>]

On 09/02/2011 03:45 PM, Christopher Felton wrote:
> A class/object that contains signals will not be converted.

How difficult do you think it would be to get that to work?

An alternative for me is the conversion of signal lists as parameters to 
the top functions, but this is not supported either.

Which of the two is easier to implement?

Re: [myhdl-list] Convertible records

[Christopher F. <chr...@gm...>]

On 9/2/2011 7:16 AM, Sébastien Bourdeauducq wrote:
> Hi,
>
> The topic of records has been brought in quite some time ago:
> http://sourceforge.net/mailarchive/forum.php?thread_name=20040216193128.11905.qmail%40web60309.mail.yahoo.com&forum_name=myhdl-list
>
> However, while I managed to get them to work in simulation, they won't
> convert to VHDL or Verilog. I'm not an expert at Python, so I'm
> wondering if there is some fundamental issue that prevents this (useful)
> feature from being implemented, or is it that no one ever got down to
> it? Or am I just doing it wrong?
>

Conversion of a composite type is not supported.  The converted will 
examine the types to be converted and expects, either int or long, 
Signal, homogeneous list of signals, or a tuple of ints.

A class/object that contains signals will not be converted.  But the 
simulator has no problem modeling this convention.

Hope this helps,
Chris

[myhdl-list] Convertible records

[Sébastien B. <seb...@mi...>]

Hi,

The topic of records has been brought in quite some time ago:
http://sourceforge.net/mailarchive/forum.php?thread_name=20040216193128.11905.qmail%40web60309.mail.yahoo.com&forum_name=myhdl-list

However, while I managed to get them to work in simulation, they won't 
convert to VHDL or Verilog. I'm not an expert at Python, so I'm 
wondering if there is some fundamental issue that prevents this (useful) 
feature from being implemented, or is it that no one ever got down to 
it? Or am I just doing it wrong?

My example code is below.

Best regards,
Sébastien

from myhdl import *

class Binary:
	def __init__(self):
		self.a = Signal(intbv()[32:])
		self.b = Signal(intbv()[32:])

def Adder(clock, r, operands):
	@always(clock.posedge)
	def logic():
		r.next = operands.a + operands.b
	return logic

def TB(clock, r, operands):
	d = delay(10)
	@always(d)
	def tb():
		operands.a.next = operands.a + 1
		operands.b.next = operands.b + 1
		clock.next = not clock
		print r
	return tb

ops = Binary()
r = Signal(intbv()[32:])
clock = Signal(bool(0))

dut = Adder(clock, r, ops)
tb = TB(clock, r, ops)

# this is fine
sim = Simulation(dut, tb)
sim.run(50)

# this last line won't work
# myhdl.ConversionError: in file essai.py, line 11:
#    Unsupported attribute: a
toVHDL(Adder, clock, r, ops)

[myhdl-list] Getting better all the time :-)

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

With PyPy 1.6, I see additional significant improvements
on my benchmarks. Speedup compared to cPython now
stands at 8-20x (was 6-12x).

     http://www.myhdl.org/doku.php/performance

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
      Python as a HDL: http://www.myhdl.org
      VHDL development, the modern way: http://www.sigasi.com
      World-class digital design: http://www.easics.com

Re: [myhdl-list] pypy test_all.py

[Christopher F. <chr...@gm...>]

>>        $ pypy --version
>>        Python 2.7.1 (?, Aug 19 2011, 23:16:54)
>>        [PyPy 1.6.0 with GCC 4.6.1]
>>
>>        $ pypy ./test_all.py
>>         ... Delete many lines ending in 'ok' ...
>>        ----------------------------------------------------------------------
>>        Ran 285 tests in 50.190s
>>
>>        OK
>>
>> Yay!
>>
>> -BobC

Thanks for the update!  D'oh pypy is slightly slower on test_all.py.  I 
ran one of my projects and it was slightly faster with the pypy 1.6 
release versus the 1.5 release.

It looks like full MyHDL support in pypy 1.6, *pypy* is pretty damn cool.

Regards,
Chris

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

For comparison purposes, on my system:

     $ python --version
     Python 2.7.1

     $ python ./test_all.py
      ... Delete many lines ending in 'ok' ...
     ----------------------------------------------------------------------
     Ran 285 tests in 66.255s

     OK

-BobC


On 08/22/2011 10:56 PM, Bob Cunningham wrote:
> I got impatient and grabbed pypy 1.6&  pypy-libs 1.6 from Rawhide(fc17) and installed them into my fc15 system:
>
>       $ pypy --version
>       Python 2.7.1 (?, Aug 19 2011, 23:16:54)
>       [PyPy 1.6.0 with GCC 4.6.1]
>
>       $ pypy ./test_all.py
>        ... Delete many lines ending in 'ok' ...
>       ----------------------------------------------------------------------
>       Ran 285 tests in 50.190s
>
>       OK
>
> Yay!
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

I got impatient and grabbed pypy 1.6 & pypy-libs 1.6 from Rawhide(fc17) and installed them into my fc15 system:

     $ pypy --version
     Python 2.7.1 (?, Aug 19 2011, 23:16:54)
     [PyPy 1.6.0 with GCC 4.6.1]

     $ pypy ./test_all.py
      ... Delete many lines ending in 'ok' ...
     ----------------------------------------------------------------------
     Ran 285 tests in 50.190s

     OK

Yay!

-BobC

Re: [myhdl-list] pypy test_all.py

[Bob C. <Fl...@gm...>]

I just noticed PyPy 1.6 is out (http://morepypy.blogspot.com/2011/08/pypy-16-kickass-panda.html).

I volunteer to test the new RPM when it is ready!

I can't wait to run "pypy test_all.py" again...


-BobC

Re: [myhdl-list] Verilog flat file

[Christopher F. <chr...@gm...>]

On 8/11/11 8:58 AM, Wesley New wrote:
> Good Day,
>
> I am have been experimenting with including MyHDL in our toolflow setup
> that we are currently using and have noticed that the generated verilog
> is a flat file.
>
> I do understand that the idea behind MyHDL is that the designer is
> ultimely independent of any HDL language. But it is quite useful for me
> to know fpga resource usage per module/core in a design as this helps us
> when optimizing designs.
>
> So my question is, is there any way that I can keep the python hierarchy
> though into the generated verilog code?
>
> Thanks for you time.
>
> Regards
>
> Wesley
>

The idea was not to generate a flat file but rather have an 
"elaboration" phase in the Python code.  If you look at a MyHDL module 
there are two distinct sections of code.  The Python code inside a 
generator and the Python code outside of a generator.

Essentially, the code outside of the generator can be any valid Python 
code.  The code inside the generator has to be conversion compatible. 
To support this "elaboration" phase and leverage the built in Python 
compiler the _hierarchy_ is lost.  The flat-file generation was a result 
of this.

The previous comments are to the best of my understanding.  Jan D. the 
creator and main (99.999%) developer can correct me if I am wrong.

Regards,
Chris Felton

[myhdl-list] Verilog flat file

[Wesley N. <we...@sk...>]

Good Day,

I am have been experimenting with including MyHDL in our toolflow setup that
we are currently using and have noticed that the generated verilog is a flat
file.

I do understand that the idea behind MyHDL is that the designer is ultimely
independent of any HDL language. But it is quite useful for me to know fpga
resource usage per module/core in a design as this helps us when optimizing
designs.

So my question is, is there any way that I can keep the python hierarchy
though into the generated verilog code?

Thanks for you time.

Regards

Wesley

Re: [myhdl-list] Wait within @always()

[Uri N. <ur...@gm...>]

On 3 August 2011 17:03, Christopher Felton <chr...@gm...> wrote:

> On 8/3/2011 2:50 AM, Uri Nix wrote:
>
>> Hi,
>>
>> I'm using MyHDL to model a FSM, and would like to wait/delay the state
>> transitions, something like this:
>>
>> @always(clk.posedge)
>>  def logic():
>>     if state == t_State.ONE:
>>         state.next = t_State.TWO
>>         # wait for something comparable to myhdl.delay(x)
>>     ...
>>
>> If I understand correctly, this would require changing the function's
>> sensitivity list dynamically - is it possible?
>> I'd prefer to keep using the @always() pattern instead of yielding
>> explicitly.
>>
>> Cheers,
>> Uri
>>
>>
> Using the @instance approach isn't too overbearing (not too many yields).
>
>   @instance
>   def logic():
>      while True:
>         yield clk.posedge
>
>
>         if state == t_State.ONE:
>            state.next = t_State.TWO
>            yield delay(133)
>         # ... rest of the state-machine conditions
>
>   return logic
>
> The only yields you require are the initial clk and where ever you want the
> delays.  I would think something like the above should work for modeling.
>
> Note : this will not be convertible (might convert but not synthesizable).
>  If you want it to be convertible & synthesizable (C&S) you can add a
> variable (using the above method) and have a simple counter of clock ticks
> for the delay.  Or use @always(clk.posedge) and a Signal for a counter of
> clock events.
>
>
> Attached is the example I tested.
>
> Regards,
> Chris Felton
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
Thanks, works like a charm!
As this is comparable to SystemC's SC_THREAD/wait() idiom, it also helped me
understand the yield business better.

Re: [myhdl-list] Wait within @always()

[Christopher F. <chr...@gm...>]

On 8/3/2011 2:50 AM, Uri Nix wrote:
> Hi,
>
> I'm using MyHDL to model a FSM, and would like to wait/delay the state
> transitions, something like this:
>
> @always(clk.posedge)
>   def logic():
>      if state == t_State.ONE:
>          state.next = t_State.TWO
>          # wait for something comparable to myhdl.delay(x)
>      ...
>
> If I understand correctly, this would require changing the function's
> sensitivity list dynamically - is it possible?
> I'd prefer to keep using the @always() pattern instead of yielding
> explicitly.
>
> Cheers,
> Uri
>

Using the @instance approach isn't too overbearing (not too many yields).

    @instance
    def logic():
       while True:
          yield clk.posedge

          if state == t_State.ONE:
             state.next = t_State.TWO
             yield delay(133)
          # ... rest of the state-machine conditions

    return logic

The only yields you require are the initial clk and where ever you want 
the delays.  I would think something like the above should work for 
modeling.

Note : this will not be convertible (might convert but not 
synthesizable).  If you want it to be convertible & synthesizable (C&S) 
you can add a variable (using the above method) and have a simple 
counter of clock ticks for the delay.  Or use @always(clk.posedge) and a 
Signal for a counter of clock events.


Attached is the example I tested.

Regards,
Chris Felton