Re: [myhdl-list] Pythonic Test frameworks

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

FWIW, py.test seems to be the way MyHDL itself is going...

-BobC


On 11/07/2011 02:15 PM, Christopher Felton wrote:
> On 11/7/2011 3:50 PM, Uri Nix wrote:
>> On 7 November 2011 08:30, Christopher Felton<chr...@gm...>   wrote:
>>
>>> Looking for some opinions on methods to make my testbenches more
>>> Pythonic.  I have been humbled more often than not with my Python
>>> programming skills, or lack there of (http://bit.ly/uQeRGm).  And my
>>> testbenches seem to be old-school version of my Verilog/VHDL equivalent
>>> testbences.  Looking to move from a testbench to a test framework.
>>>
>>> Frequently I will create a single testbench and have a bunch of
>>> testcases in the testbench.  In some cases I will create multiple
>>> (different) forms in test_ functions to use with py.test.
>>>
>>> But too often, majority of my test cases are in this single testbench.
>>> What I would like to do is leverage the py.test framework but only
>>> define connections, models, etc *once*.  Using the USB interface project
>>> (USBP, http://bit.ly/sPEMC1) as an example I used something like the
>>> following.
>>>
>>> ~~~ [Example Code] ~~~
>>> class BaseSim()
>>>
>>>      def __init__(self, ...):
>>>         # all top-level signal definitions, dut instance and interface
>>>         # model instances
>>>         ...
>>>
>>>     def GetGens():
>>>         # return all the generators for
>>>
>>> def test_case1():
>>>      bs = BaseSim()
>>>
>>>      @instance
>>>      def tb_stimulus():
>>>         yield bs.WriteRegister(0x00, 42)
>>>         rval = [0]
>>>         yield bs.ReadRegister(0x00, val)
>>>         assert rval[0] == 42
>>>         raise StopSimulation
>>>
>>>      Simulation((tb_stimulus, bs.GetGens())).run()
>>>
>>> def test_case2():
>>>      bs = BaseSim()
>>>
>>>      @instance
>>>      def tb_stimulus
>>>         bs.someSignal.next = True
>>>         yield delay(3)
>>>         bs.someSignal.next = False
>>>         # check some condition
>>>         raise StopSimulation
>>>
>>>     Simulation((tb_stimulus, bs.GetGens())).run()
>>>
>>> ~~~ [End Example Code]~~~
>>>
>>> Other methods that are more flexible?  Is it worth it to add the
>>> instantiations and connection signals to a class or just in a module?
>>>
>>> Thanks in advance,
>>> Chris
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> RSA(R) Conference 2012
>>> Save $700 by Nov 18
>>> Register now
>>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>
>> Hi Chris,
>>
>>     I find the standard lib unittest flexible enough, allowing something like
>> the example below.
>>     Any special reason for using py.test?
> No special reason for the py.test.  I guess I have used py.test because
> you simply create test_ functions and use asserts.  And I have not use
> the unittest as much.  You pointed out the piece I think I was looking
> for.  The idea of a setup!  This is where all the connections etc can be
> defined and defined only once (thanks for the code example).
>
> Searching, py.test has a similar mechanism.  You need to define all the
> test_ functions/methods in a class and use the "setup_method" which is
> equivalent to the setUp in the unittest.
>
> Thanks!
> Chris
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>