myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Pythonic Test frameworks

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

On 11/07/2011 08:07 PM, Christopher Felton wrote:
> On 11/7/11 7:21 PM, Bob Cunningham wrote:
>> FWIW, py.test seems to be the way MyHDL itself is going...
>>
>> -BobC
> ...
>
> The following, http://bit.ly/sc3vrI, is a brief mention of py.test used
> instead of unittest (from a couple years ago) from the myhdl-list.
>
> But I do believe py.test is limited.  If you are ok writing with only
> simple asserts, I believe py.test is ok.  But unittest supports more
> advanced features, automatically verify raised exceptions (continue if
> raised fail if not).
>
> I guess an argument against py.test, is that it is another package that
> needs to be installed.  Where as, unittest is part of the standard
> Python library, hmmm.
>
> Regards,
> Chris

Well, MyHDL is, itself, "another package that needs to be installed"!

See the end of this page: http://www.myhdl.org/doku.php/cookbook:stopwatch

And py.test does handle *expected* exceptions: Unexpected exceptions will crash the test with a suitable dump.  See http://pytest.org/latest/getting-started.html#asserting-that-a-certain-exception-is-raised

FWIW, py.test is faster and easier, and doesn't much care about the structure of your MyHDL code, but it has limitations.  Unittest is more powerful, but is harder to use.

As a true newbie to both digital design and MyHDL, I've been coding and testing in the smallest increments possible, with tiny blocks glued together.  For this specific development path, py.test seems ideal.  At this point, I have no idea if it will work as well with more complex designs.

However, I am quite biased: In my embedded/real-time software systems I often used "programming by contract" (PBC), which is extensively assert-based (to validate the contracts), so py.test seems quite natural to me.  It is also a form of 'white-box' testing.

The complementary approach, test-driven design (TDD), puts more burden on the test harness, which means the test tools must be more powerful and sophisticated.  This is generally a form of 'black-box' testing.

In the software world, the two test methods work well together in practice:  If you use PBC at the low level, the higher-level tests can be simpler.

Has anyone tried to see if py.test and unittest can play nice together (at different levels of abstraction) within a single MyHDL project?

-BobC

Re: [myhdl-list] Pythonic Test frameworks

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

On 11/7/11 7:21 PM, Bob Cunningham wrote:
> FWIW, py.test seems to be the way MyHDL itself is going...
>
> -BobC

Yeah we have had some brief conversations in the past, that py.test was 
a convenient test framework.  Some of the new tests are written for 
py.test.  But tests are still added under the unittest framework as 
well.  I don't know if it is accurate that MyHDL is moving towards 
py.test and away from unittest.  I think it depends what is being 
tested.  Example, the tests for the modbv (recent addition) were added 
in the unittest area.

I like the py.test but I have little experience with unittest and 
limited with py.test, case in point I was not aware (or forgot) of the 
setup/tear down capabilities.  I don't have enough information at this 
point to suggest one over the other.  It looks like, if you require 
teardown along with setup you will need unittest framework and not py.test.

The following, http://bit.ly/sc3vrI, is a brief mention of py.test used 
instead of unittest (from a couple years ago) from the myhdl-list.

But I do believe py.test is limited.  If you are ok writing with only 
simple asserts, I believe py.test is ok.  But unittest supports more 
advanced features, automatically verify raised exceptions (continue if 
raised fail if not).

I guess an argument against py.test, is that it is another package that 
needs to be installed.  Where as, unittest is part of the standard 
Python library, hmmm.

Regards,
Chris

>
>
> 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
>>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1

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
>

Re: [myhdl-list] Pythonic Test frameworks

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

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

Re: [myhdl-list] Pythonic Test frameworks

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

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?

Cheers,
  Uri

~~~ [Example Code] ~~~
import itertools
import unittest
from myhdl import Signal, always, delay, Simulation

def Clock(clk):
    @always(delay(1))
    def logic():
        clk.next ^= 1
    return logic

def DUT(clk, din, dout):
    @always(clk.posedge)
    def logic():
        dout.next = din.val + 1
    return logic


class TestDUT(unittest.TestCase):
    # unittest methods
    def setUp(self):
        self.clk = Signal(0)
        self.din = Signal(0)
        self.dout = Signal(0)
        self.clk_inst = Clock(self.clk)
        self.dut_inst = DUT(self.clk, self.din, self.dout)

    def tearDown(self):
        pass

    # core test routines
    def exec_test(self, stimulus, ticks):
        sim = Simulation(self.dut_inst, self.clk_inst, stimulus)
        sim.run(ticks)

    def stim_gen(self, clk, gen_data, init_value):
        sig_gen = itertools.count(init_value)
        @always(clk.posedge)
        def logic():
            gen_data.next = sig_gen.next()
        return logic

    # specific test methods (scenarios)
    def test_1(self):
        stim_inst = self.stim_gen(self.clk, self.din, 3)
        self.exec_test(stim_inst, 7)
        self.assertEqual(self.dout.val, 6)

    def test_2(self):
        stim_inst = self.stim_gen(self.clk, self.din, 3)
        self.exec_test(stim_inst, 8)
        self.assertEqual(self.dout.val, 6)


if __name__ == '__main__':
    mytests = unittest.TestLoader().loadTestsFromTestCase(TestDUT)
    unittest.TextTestRunner(verbosity=2).run(mytests)

~~~ [End Example Code]~~~

[myhdl-list] Pythonic Test frameworks

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

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

Re: [myhdl-list] Notice

[Jose I. V. <jo...@dt...>]

Jan, whatever it was, I'm sorry you are going through this. My thoughts are
with you and your loved ones.

Regards,
José Ignacio Villar.



On Sun, Oct 23, 2011 at 6:47 AM, Martín Gaitán <ga...@gm...> wrote:

> On Fri, Oct 21, 2011 at 7:29 AM, Jan Decaluwe <ja...@ja...> wrote:
>
>> Due to a personal tragedy, I will be out of the loop
>> for an extended period of time.
>>
>> Jan
>>
>>
> Jan, whatever has happened, I wish you much peace to you and your loved
> ones. Thank you for all your work on MyHDL, and  hope you can return to it
> in the future.
>
> kind regards
> martin
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] Notice

[Martín G. <ga...@gm...>]

On Fri, Oct 21, 2011 at 7:29 AM, Jan Decaluwe <ja...@ja...> wrote:

> Due to a personal tragedy, I will be out of the loop
> for an extended period of time.
>
> Jan
>
>
Jan, whatever has happened, I wish you much peace to you and your loved
ones. Thank you for all your work on MyHDL, and  hope you can return to it
in the future.

kind regards
martin

Re: [myhdl-list] Problems with MyHDL and Modelsim cosimulation

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

On 10/21/11 1:41 PM, David Greenberg wrote:
> I'm trying to get the basic cosimulation tests to pass with modelsim,
> but they're currently failing. I built the VPI with the following
> Makefile fragment:
>
> myhdl.vpi: myhdl.c myhdl_table.c
>          gcc -c -g -fPIC -I ${MODELSIM_INC} myhdl.c myhdl_table.c
>          ld -shared -E -o myhdl_vpi.so myhdl.o myhdl_table.o
>
> Modelsim seems to like myhdl_vpi.so (so far so good).
>
> Next, I modified dff.py to use the following commands:
>
> cmd = "vlog ../../test/verilog/dff.v ../../test/verilog/dut_dff.v"
> def dff(q, d, clk, reset):
>    os.system(cmd)
>    return Cosimulation("vsim -c -pli myhdl_vpi.so dff -do sim.do", **locals())
>
> and the contents of sim.do are:
>
> run -all
> quit -f
>
> I get "Premature simulation end" errors (line 88 in _Cosimulation.py,
> MyHDL 0.7) for all the tests.
>
> Does anyone have experience getting MyHDL and Modelsim to play nicely?
>
> Thanks,
> David

If you pull the latest 0.8-dev branch there is a modelsim directory with 
updated tests.  And in the modelsim directory is a test directory.  To 
run the tests in the directory you need to do the following.

1. run the Makefile in cosimulation/modelsim
2. copy the .so file to the test directory
3. cd to the test directory, then execute
   $ vlib work
   $ vmap work work
   $ python test_all.py

This should succeed without error.

Hope that helps,
Chris

Re: [myhdl-list] Notice

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

On 10/21/11 5:29 AM, Jan Decaluwe wrote:
> Due to a personal tragedy, I will be out of the loop
> for an extended period of time.
>
> Jan
>

Sorry to hear about the unfortunate event.  Our thoughts will be with you.

Regards,
Chris

[myhdl-list] Problems with MyHDL and Modelsim cosimulation

[David G. <dsg...@gm...>]

I'm trying to get the basic cosimulation tests to pass with modelsim,
but they're currently failing. I built the VPI with the following
Makefile fragment:

myhdl.vpi: myhdl.c myhdl_table.c
        gcc -c -g -fPIC -I ${MODELSIM_INC} myhdl.c myhdl_table.c
        ld -shared -E -o myhdl_vpi.so myhdl.o myhdl_table.o

Modelsim seems to like myhdl_vpi.so (so far so good).

Next, I modified dff.py to use the following commands:

cmd = "vlog ../../test/verilog/dff.v ../../test/verilog/dut_dff.v"
def dff(q, d, clk, reset):
  os.system(cmd)
  return Cosimulation("vsim -c -pli myhdl_vpi.so dff -do sim.do", **locals())

and the contents of sim.do are:

run -all
quit -f

I get "Premature simulation end" errors (line 88 in _Cosimulation.py,
MyHDL 0.7) for all the tests.

Does anyone have experience getting MyHDL and Modelsim to play nicely?

Thanks,
David

Re: [myhdl-list] my patches

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

On 10/21/2011 12:13 PM, Jan Decaluwe wrote:
> In that case, how should the Signals in question be initialized?
> Remember, the initial value is an explicit part of the Signal
> construction, you have to choose one. (This is MyHDL, not Verilog).
> It certainly would seem confusing and dubious coding if the
> initial value would be different from the "constant driver"
> value. Any code reviewer would spot this as an obvious weak point
> in the code, and suggest to initialize the Signal to the
> "constant" value.

This does not shock me more than the signal having a different value 
than its initial one after it has been driven by, say, a AND gate.

In my opinion, directly supporting constant logic functions is more 
practical (e.g. with less typing for the user) and cleaner design than 
having to work around the MyHDL limitation by declaring a new signal 
with the constant value you need, and connecting it to the signal you 
want to drive.

Maybe the initial values could be made optional? And give an error if 
any signal without an initial value is not driven?

S.

[myhdl-list] Notice

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

Due to a personal tragedy, I will be out of the loop
for an extended period of time.

Jan

-- 
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] my patches

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

On 10/19/2011 04:20 PM, Christopher Felton wrote:

> The constant driver had a good conversation but the conversation
> remained unresolved.  Best I can tell, constant drivers are supported
> in today's MyHDL but not is a form you would like.  The previous
> question of "you disagree with being able to build constant drivers?"
> simply disregarded the previous conversations.

Right. In my view, MyHDL today has a superior solution
called initialization.

Look at it this way. Suppose there would be some kind of "constant
driver" support from some generator. (Actually, the @instance
generator may offer this today, depending on whether the solution
should be synthesizable or not. The suggestion to add this
to @always_comb seems to clash with its semantics to me.)

In that case, how should the Signals in question be initialized?
Remember, the initial value is an explicit part of the Signal
construction, you have to choose one. (This is MyHDL, not Verilog).
It certainly would seem confusing and dubious coding if the
initial value would be different from the "constant driver"
value. Any code reviewer would spot this as an obvious weak point
in the code, and suggest to initialize the Signal to the
"constant" value.

Which proves that the case for special generator support
is without merit, as simply specifying the initial value
is a solution that works today.

> The support for Signals in a class (object) being identified in an
> @always_comb sensitivity list appears to be a good addition.

I agree.

And thanks for a meaningful discussion.

-- 
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] my patches

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

What a way to welcome new potential contributors :-) and yes, I will 
fork (and have a closer look at this "yield None" 'fundamental' problem 
in my first patch, thanks for pointing it out).

On 10/21/2011 01:19 AM, Jan Decaluwe wrote:
> On 10/18/2011 05:11 PM, Sébastien Bourdeauducq wrote:
>> On 10/18/2011 04:59 PM, Bob Cunningham wrote:
>>> If you think MyHDL has conservative policies, you should try to get a
>>> Linux kernel patch accepted.
>>
>> Done: http://www.mail-archive.com/st...@li.../msg00138.html
>> You might say this is a trivial patch, but the MyHDL ones aren't
>> complicated either (yet).
>
> In your simplistic view of things. In reality, you have gained zero
> understanding of what 'yield None' in MyHDL really means. Following
> the guidelines would at least have told you that there is something
> fundamentally wrong.
>
>>    >   Are you going to create your own website to host and document your
>>    >   fork?
>>
>> The MyHDL mods are part of a larger HLS project that will, indeed, have
>> its own website. So I'd simply distribute the modified MyHDL along with
>> it :-)
>>
>>    >   What I think you mean to say is that you intend for your patch to
>>    >   never have more than a single user: You.
>>
>> Certainly not, and this is also why I posted on this mailing list in
>> order to try to avoid forking. But since getting even simple patches
>> reviewed/accepted is messy, forking is probably easier for me.
>
> No, it's your patch that is messy (fundamentally broken even). The
> guidelines are there to avoid that I have to waste time on such kludgy
> work. Even after several rounds of insisting, you still didn't get the
> hint. I've really had it with that kind of unwarranted self-confidence.

Re: [myhdl-list] my patches

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

On 10/18/2011 05:11 PM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 04:59 PM, Bob Cunningham wrote:
>> If you think MyHDL has conservative policies, you should try to get a
>> Linux kernel patch accepted.
>
> Done: http://www.mail-archive.com/st...@li.../msg00138.html
> You might say this is a trivial patch, but the MyHDL ones aren't
> complicated either (yet).

In your simplistic view of things. In reality, you have gained zero
understanding of what 'yield None' in MyHDL really means. Following
the guidelines would at least have told you that there is something
fundamentally wrong.

>   >  Are you going to create your own website to host and document your
>   >  fork?
>
> The MyHDL mods are part of a larger HLS project that will, indeed, have
> its own website. So I'd simply distribute the modified MyHDL along with
> it :-)
>
>   >  What I think you mean to say is that you intend for your patch to
>   >  never have more than a single user: You.
>
> Certainly not, and this is also why I posted on this mailing list in
> order to try to avoid forking. But since getting even simple patches
> reviewed/accepted is messy, forking is probably easier for me.

No, it's your patch that is messy (fundamentally broken even). The
guidelines are there to avoid that I have to waste time on such kludgy
work. Even after several rounds of insisting, you still didn't get the
hint. I've really had it with that kind of unwarranted self-confidence.

>   >  What is the problem you are trying to solve?  Can you distill it to a
>   >  small, clear example?
>
> See my initial emails (about constant drivers and object support), and
> the links to such examples that accompanied the patches.
>
> S.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct


-- 
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] my patches

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

On 10/18/2011 11:51 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 11:42 AM, Ben wrote:
>> So what now ?
>
> Well, since I disagree with your conservative policies, I will fork MyHDL.

Yes, please fork off.

I will keep the "conservative" policies, thank you. The rest of
the community will be thankful that I didn't commit an obviously
broken patch that breaks the core tests. Which you could have
found out yourself by simply following the guidelines.

Imagine what a mess this would become if left to overly self-confident
people like you.

-- 
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] my patches

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

On 10/18/2011 10:49 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 10:03 AM, Jan Decaluwe wrote:
>> The deal is: we work efficiently by agreeing on a spec
>> first,
>
> So, do you disagree with being able to build constant drivers? Or being
> able to read signals within objects in @always_comb blocks?

Ok. So I describe the methodology for *agreeing*, and you
interprete it as me disagreeing.

That is just stupid, bad faith and a sign that I'm really
wasting my time here.

-- 
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] my patches

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

On 10/18/2011 10:11 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 04:59 PM, Bob Cunningham wrote:
>> If you think MyHDL has conservative policies, you should try to get a
>> Linux kernel patch accepted.
>
> Done: http://www.mail-archive.com/st...@li.../msg00138.html
> You might say this is a trivial patch, but the MyHDL ones aren't
> complicated either (yet).

I don't know if that is a fair example.  You simply asked to have your 
USB VID/PID for your device added.  And if I read the page correctly, 
there was a month delay (3-Nov - 6.Dec).

>
>   >  Are you going to create your own website to host and document your
>   >  fork?
>
> The MyHDL mods are part of a larger HLS project that will, indeed, have
> its own website. So I'd simply distribute the modified MyHDL along with
> it :-)
>
>   >  What I think you mean to say is that you intend for your patch to
>   >  never have more than a single user: You.
>
> Certainly not, and this is also why I posted on this mailing list in
> order to try to avoid forking. But since getting even simple patches
> reviewed/accepted is messy, forking is probably easier for me.

Don't get me wrong, I don't want to discourage anyone, especially 
someone that is very enthusiastic.  But, at this point, maybe it is best 
what you propose; if your main concern is a path of least resistance.

>
>   >  What is the problem you are trying to solve?  Can you distill it to a
>   >  small, clear example?
>
> See my initial emails (about constant drivers and object support), and
> the links to such examples that accompanied the patches.

The constant driver had a good conversation but the conversation 
remained unresolved.  Best I can tell, constant drivers are supported in 
today's MyHDL but not is a form you would like.  The previous question 
of "you disagree with being able to build constant drivers?" simply 
disregarded the previous conversations.

The support for Signals in a class (object) being identified in an 
@always_comb sensitivity list appears to be a good addition.  There were 
some disconnected conversations about class support etc.  But I think it 
will take some time, without further discussion, before anyone has time 
to review the changes, add test cases to the test infrastructure, and 
determine if this is a small change that might lead to larger future 
changes and if so does the implementation fit.


Regards,
Chris

[myhdl-list] MyHDL Success Stories

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

On 10/6/2011 12:14 PM, Jan Decaluwe wrote:
> On 10/06/2011 12:35 AM, Christopher Felton wrote:
>
>> I will see if I can provide some details on the MyHDL designs I have
>> fielded.  If not I will provide some generic descriptions in the
>> user/project space.
>
> Great, thanks. Once we have 4-5 projects, I propose to
> add a "Silicon Success" page with the links, on a prominent
> position on the website.
>
>

The following are commercial projects which I have used MyHDL.

1.  [FPGA] High-speed satellite communication link, NASA's TDRSS.  The 
modem was developed for the NASA's TKUP project while I was at RTLogic. 
  MyHDL was used for modeling and verification of high-speed DSP blocks.
http://www.rtlogic.com/press_releases/TKUP_Press_Release_8.31.07.pdf.

2.  [FPGA] Custom proprietary modem used over a non-common medium. 
MyHDL was used for modeling, verification, and implementation of a 
couple IP blocks.  This project is currently deployed in small numbers.

3.  [FPGA] MyHDL is used by DSPtronics.  These were small examples 
similar to the wiki space.  The platform was used by students at the 
University of Colorado, Colorado Springs (UCCS), 
http://www.eas.uccs.edu/wickert/ece4890/lecture_notes/ece4890_RFPs_Fa2011.pdf 
(note the overused graphic :) ).  I am not geographically located near 
this anymore (haven't been for 3 years), I am a little out of the loop. 
  I don't know how much has actually been done by the students (if any 
at all).  I don't know if this qualifies as a success story.

4.  [ASIC] Latest project, MyHDL was used for all verification of a 
digital subsystem in a mixed-signal IC.  The die have been received and 
are in the process of hardware testing.  I will be able to share more on 
this development in a couple months (maybe 6mos or more) after the 
research announcements/publications have been released.  In addition 
MyHDL was used completely to develop all logic for test/interface FPGA.

 From my perspective, MyHDL saved effort in developing and verifying 
these projects.  In the latest projects, kinda fallen into a nice flow, 
where:

   Tests and Test Infrastructure developed
   ASIC logic developed
   ASIC logic verified with test environment
     (post-syn and post-layout cosims)
   Final HW test fixture development
     FPGA logic, verified with previous test and design
   ASIC logic prototyped of FPGA (early FPGA proto to FW devs)
   Test fixture and prototype FPGA tested together
   Final hardware interface/tested with test-fixture

I liked this flow because it had multiple items cross checking each 
other as well as reuse.  The simulation test environment and FPGA test 
fixture are able to use the same Python test code.  As test code evolved 
it could be run against HDL simulations, FPGA prototype, and eventually 
final hardware.

Regards,
Chris

Re: [myhdl-list] Driving constants

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

Perhaps it is inappropriate to rewind the prior discussion, but here goes...

On 09/04/2011 02:26 AM, Sébastien Bourdeauducq wrote:
> Ok, then here is some more background:
>
> I have an abstract class FunctionalUnit which implements dataflow
> processing units. This abstract class creates handshaking signals (ack,
> strobe) common to all functional units which are used to control the
> flow of data.
> The method ImplementControl is overloaded by derived classes to
> implement the actual handshaking logic, and returns instances. Now, when
> some functional units need to drive handshaking signals constants, and
> if it is not possible to build "constant drivers" instances, it becomes
> messy.

So, from my admittedly limited (and likely incorrect) perspective, here's what I think is going on:

Let's say I have some 'dataflow 3-input NAND gates', where each of the three inputs sinks a data and strobe, and drives a return ack.  When the 3rd input has been strobed, the output will fire (as well as generate the returning ack to the last input), sending its own data and strobe to the downstream dataflow element until the returning ack is seen.

The problem, as I see it, is what if I need only a 2-input NAND gate at a particular point in the dataflow?  And let's say I'd prefer to reuse my standard element rather than define a new 2-input element (though an optimizer may do it for me).  To do this, I'd need to drive the unused input with a constant value, in this case a True or intvb(1) value.  And the resulting ack would be ignored.

Is that the gist of it?  If so, can we reduce the above example to the application domain, and toss around some candidate solutions (and simulations) in MyHDL code?

-BobC

Re: [myhdl-list] my patches

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

On 10/18/2011 08:11 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 04:59 PM, Bob Cunningham wrote:
> > What is the problem you are trying to solve?  Can you distill it to a
> > small, clear example?
>
> See my initial emails (about constant drivers and object support), and the links to such examples that accompanied the patches.

I've read your recent messages, and they all started way above my present level of knowledge.  I didn't even know what questions to ask!  The best I could think to do was to save them, with the hope of returning to them when I've learned more.  But by then the issue itself will likely be long forgotten.

Not that I need to be involved, but I was hoping to understand a point of view that appears to be somewhat different from the default MyHDL perspective.  If I can grab onto a low-hanging branch, I will work very hard to climb up and learn enough to hopefully become a useful participant in the discussion.

If you have the time, and if it is worth the effort, would you please try to explain your intent from 'first principles'?  As if to an EE sophomore?

I'm a 25 year embedded/real-time software developer and Python user, a veteran system and algorithm designer who is comfortable both at the bottom level of DeMorgan's Theorems, and also at the top level of complex digital devices (as black boxes).  Way back in the early days of tiny PALs, I did all the PALASM programming on several projects, until it became part of the EE curriculum.  More recently, I've spec'ed algorithms for portions of several FPGAs, worked closely with the EEs who implemented them, then tested the programmed hardware.  Unfortunately, I haven't been able to understand their implementation, other than to ensure it correctly implemented the specification.  I'm presently trying my best to fill in that knowledge gap!  Needless to say, I'm also coming from quite a different perspective than most on this list (mainly lack of an EE education and experience).

I believe your perspective may be very important, if only I understood it.

-BobC

Re: [myhdl-list] my patches

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

On 10/18/2011 04:59 PM, Bob Cunningham wrote:
> If you think MyHDL has conservative policies, you should try to get a
> Linux kernel patch accepted.

Done: http://www.mail-archive.com/st...@li.../msg00138.html
You might say this is a trivial patch, but the MyHDL ones aren't 
complicated either (yet).

 > Are you going to create your own website to host and document your
 > fork?

The MyHDL mods are part of a larger HLS project that will, indeed, have 
its own website. So I'd simply distribute the modified MyHDL along with 
it :-)

 > What I think you mean to say is that you intend for your patch to
 > never have more than a single user: You.

Certainly not, and this is also why I posted on this mailing list in 
order to try to avoid forking. But since getting even simple patches 
reviewed/accepted is messy, forking is probably easier for me.

 > What is the problem you are trying to solve?  Can you distill it to a
 > small, clear example?

See my initial emails (about constant drivers and object support), and 
the links to such examples that accompanied the patches.

S.

Re: [myhdl-list] my patches

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

On 10/18/2011 02:51 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 11:42 AM, Ben wrote:
>> So what now ?
> Well, since I disagree with your conservative policies, I will fork MyHDL.

That is certainly your prerogative, but I'd recommend against it.  Becoming part of a community can be difficult, but I believe both the process and the result are best for everyone.

The goal isn't personal glory or self-aggrandizement.  The goal is to evolve the product in a direction that benefits the entire community.

If you think MyHDL has conservative policies, you should try to get a Linux kernel patch accepted.  The MyHDL guidelines distill the wisdom of the engineering process in a manner that invites community participation.

I once tried to submit a Linux memory management patch, and by the time I was pushed and shoved through the community process, another programmer had created a patch that solved my specific problem much better than my original patch, while also solving other issues raised during the discussion.  Plus, his code was smaller, simpler, faster, and far better than mine.  It was a humbling experience, but it was also massively educational.  My main contribution wasn't my patch, but my description of the problem I was trying to solve.  Once the community agreed there was a problem, had fully fleshed it out, then agreed that it did need solving, the issue gained a life of its own.  I would have saved myself a lot of time, and gotten my problem solved sooner and better, if I had gone to the LKML before I had written a single line of code.

Plus, I doubt you really mean you are going to 'fork MyHDL'.  Are you going to create your own website to host and document your fork?  Are you going to port future changes to the MyHDL base over to your fork?  I doubt it: If you were willing to do that much work, you would have started it in this list.  What I think you mean to say is that you intend for your patch to never have more than a single user: You.  What a waste!

I'm very much a digital design and MyHDL newbie, and I was looking forward to the discussions that could have surrounded your patch, not starting with the patch (the patch is the END of the story, not the start).  I'm far from ready to look at your code: I would very much prefer to understand the problem you are trying to solve, to see why MyHDL can't handle it as-is, to learn from you, to see how you think, to see how the rest of the MyHDL community responds so I can learn more about how THEY think.

But when asked to start at the beginning, you instead choose to take your toy and run away from the playground.  Which is absolutely your right to do:  The code you wrote is your property, and you can do whatever you want with it.  But it leaves me feeling cheated of a great learning opportunity.

Please, take a deep breath, take a step back from your code, and try to start from the beginning:  What is the problem you are trying to solve?  Can you distill it to a small, clear example?  Can you help us see that a change to MyHDL (rather than a different design approach to the problem) is the best way to solve the issue?

Please?

-BobC

Re: [myhdl-list] my patches

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

On 10/18/2011 4:51 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 11:42 AM, Ben wrote:
>> So what now ?
>
> Well, since I disagree with your conservative policies, I will fork MyHDL.
>

Since when is *good* Engineering anything but good Engineering?

I don't think what is being asked is much different than many other 
open-source efforts.  If you wanted to contribute a change (not a bug 
fix) to the Python source, I believe you would need to do the same.

.chris

>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct