myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] What logic is allowed inside an always_comb?

[Ben R. <be...@re...>]

That's exactly the documentation I was looking for.  Thank you!


On Mon, Feb 22, 2016 at 2:49 PM, Christopher Felton <chr...@gm...>
wrote:

> On 2/21/2016 8:59 PM, Ben Reynwar wrote:
> > Is there a summary of the kind of logic that one can use inside an
> > @always_comb without confusing MyHDL's black parsing magic?
> >
> > I attempted to do:
> >
> > @always_comb
> > def dostuff():
> >      for i, o in ((i1, o1), (i2, o2)):
> >          o.next = i
> >
> > but it didn't behave,
>
> When you say it didn't "behave", do you mean it
> didn't simulate as expected or it didn't convert?
>
> Code like the above will not convert, what is
> convertible is covered in the manual:
>
> http://docs.myhdl.org/en/stable/manual/conversion.html#the-convertible-subset
>
> For simulation only, I believe it is the goal
> to support all constructs.  But realistically
> this might be difficult as your example
> demonstrates(?).  We will need to investigate
> your example and determine if it is an expected
> limitation or a bug.
>
> Regards,
> Chris
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] What logic is allowed inside an always_comb?

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

On 2/21/2016 8:59 PM, Ben Reynwar wrote:
> Is there a summary of the kind of logic that one can use inside an
> @always_comb without confusing MyHDL's black parsing magic?
>
> I attempted to do:
>
> @always_comb
> def dostuff():
>      for i, o in ((i1, o1), (i2, o2)):
>          o.next = i
>
> but it didn't behave,

When you say it didn't "behave", do you mean it
didn't simulate as expected or it didn't convert?

Code like the above will not convert, what is
convertible is covered in the manual:
http://docs.myhdl.org/en/stable/manual/conversion.html#the-convertible-subset

For simulation only, I believe it is the goal
to support all constructs.  But realistically
this might be difficult as your example
demonstrates(?).  We will need to investigate
your example and determine if it is an expected
limitation or a bug.

Regards,
Chris

Re: [myhdl-list] Welcome to the "myhdl-list" mailing list

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

On 2/13/2016 10:12 AM, Utkarsh Saxena wrote:
> Dear Developers,
>
> I want to contribute to myhdl project for the coming GSoC, and hopefully
> even after that, as I am fascinated by the things this project could do to
> make Hardware Description Easy for everyone. However, I went through the
> idea list for the GSoC 2016 and realised that I am underqualified to
> contribute to this project technically. Though, I am studying electrical
> engineering(sophomore year) I am afraid I can't understand most of the
> things in the project, and completely blank on how to proceed.
>
>
> If not this year, I want to contribute next year, and I need some help and
> guidance on how to learn the prerequisites and gather sufficient knowledge
> in technical aspects so I can contribute and add value to this project.
>

Do you have any experience with Python?  If not, the first
step is to become proficient in Python.  See the Python
website for links to introduction material and courses.

Then the next step is to review the MyHDL manual [1] and
start coding some digital circuits.

[1] http://docs.myhdl.org/en/stable/

[myhdl-list] What logic is allowed inside an always_comb?

[Ben R. <be...@re...>]

Is there a summary of the kind of logic that one can use inside an
@always_comb without confusing MyHDL's black parsing magic?

I attempted to do:

@always_comb
def dostuff():
    for i, o in ((i1, o1), (i2, o2)):
        o.next = i

but it didn't behave, and looking into the implementation of always_comb I
can see that the "for" loop is not compatible.  It decides that i1, o1, i2
and o2 are all inputs and that there are no outputs.

I had a look at the documentation but didn't see a summary anywhere of the
kind of logic that I'm allowed to use here.  Does such a summary exist?
It's quite possible that I just read over it.

Cheers,
Ben

Re: [myhdl-list] Welcome to the "myhdl-list" mailing list

[Utkarsh S. <sax...@gm...>]

Dear Developers,

I want to contribute to myhdl project for the coming GSoC, and hopefully
even after that, as I am fascinated by the things this project could do to
make Hardware Description Easy for everyone. However, I went through the
idea list for the GSoC 2016 and realised that I am underqualified to
contribute to this project technically. Though, I am studying electrical
engineering(sophomore year) I am afraid I can't understand most of the
things in the project, and completely blank on how to proceed.


If not this year, I want to contribute next year, and I need some help and
guidance on how to learn the prerequisites and gather sufficient knowledge
in technical aspects so I can contribute and add value to this project.

Thank you

Utkarsh

On Sat, Feb 13, 2016 at 5:15 PM, <myh...@li...>
wrote:

> Welcome to the myh...@li... mailing list!
>
> To post to this list, send your email to:
>
>   myh...@li...
>
> General information about the mailing list is at:
>
>   https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
> If you ever want to unsubscribe or change your options (eg, switch to
> or from digest mode, change your password, etc.), visit your
> subscription page at:
>
>
> https://lists.sourceforge.net/lists/options/myhdl-list/saxenauts%40gmail.com
>
>
> You can also make such adjustments via email by sending a message to:
>
>   myh...@li...
>
> with the word `help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions.
>
> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe.  It is:
>
>   he1lHitler
>
> Normally, Mailman will remind you of your lists.sourceforge.net
> mailing list passwords once every month, although you can disable this
> if you prefer.  This reminder will also include instructions on how to
> unsubscribe or change your account options.  There is also a button on
> your options page that will email your current password to you.
>

[myhdl-list] tick_inst = glbl_timer_ticks(glbl, include_seconds=True).

[Edward V. <dev...@sb...>]

Hello All,

Trying to modify icestick_blinky_host.py to catboard_blinky_host.py.

Removed signals pmod, uart_dtr, and uart_rts.  In uartlite I did not see the dtr or dts.
The signal dtr & dts are part of the ports on the icestick.
Added the ports for uart_rx & uart_tx.

chg'ed clock=Clock(0, frequency=100e6),

python catboard_blinky_host.py --test

uartlite 
  baudrate: 115200.000000 actual 115200.000000 
  baud frequency: 288.000, baud limit: 15625.000
  remainder 54.253472

For icestick_blinky_host.py --test
  remainder 27.126736

The following error occurs  both on Ubuntu 12.04 & RPi2B.

pi@mysshserver ~/jpeg-2000-test/pc_fast_blinker_jpeg/input_examples $ python catboard_blinky_host.py --build

I used the error output as the commits message on my repo 

https://github.com/develone/jpeg-2000-test   

Latest commit 1a85064

The error in question is line 35 see below

tick_inst = glbl_timer_ticks(glbl, include_seconds=True).

In another example input_clk.py I use the same line to instantiate tick_inst.
In this example I do not use the signal glbl.tick_sec which is used in catboard_blinky_host.py. Thanks,Have a great day

Edward Vidal Jr. e-mail dev...@sb... 915-595-1613

Re: [myhdl-list] (rhea) icestick_blinky_host.py

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

On 2/5/16 3:02 PM, Edward Vidal wrote:
> Hi All,
>
>
> My concern was the setting the frequency to 50e6.  Is this just for
> the UART since it has a baud rate?

I am confused, why or how are you setting it
to 50e6?  Like I said before you should just
be using the clock passed during the build
so you shouldn't have to set it.

>
> In the xula2.ucf I do see NET "clock" TNM_NET = "clock"; TIMESPEC
> "TS_clock" = PERIOD "clock" 83.3333333 ns HIGH 50%; which is the
> 12MHz of the XulA2 board
 >
 > While on the catboard.pcf I never see anything related to timing.
 >

The clock constraints should be written out for
the ice flow (iceriver) as well.  I forget if
this is something that has not been implemented
yet or not supported in arachne.

In this case, correct the frequency is used for
for any time based things: buad, 1 second tick,
etc.

> Running python input_clk.py --convert generates cat_top.v. Running
> python input_clk.py --build generates iceriver/catboard.v
>
> In the catboard.v I see wire cmd_inst_clock; which is not in
> cat_top.v.
>
> Also many of the modules in catboard.v have this line always
> @(posedge cmd_inst_clock) begin

If you don't think it is correct you would have
to trace it out in the Verilog source.  Name
changes do occur in conversion.  If your simulation
tests pass it is probably ok and name changes
occurred in the conversion.

Regards,
Chris

Re: [myhdl-list] (rhea) icestick_blinky_host.py

[Edward V. <dev...@sb...>]

Hi All,

My concern was the setting the frequency to 50e6.  Is this just for the UART since it has a baud rate?
In the xula2.ucf I do see 
NET "clock" TNM_NET = "clock"; 
TIMESPEC "TS_clock" = PERIOD "clock" 83.3333333 ns HIGH 50%;which is the 12MHz of the XulA2 board
While on the catboard.pcf I never see anything related to timing.
Running python input_clk.py --convert generates cat_top.v.Running python input_clk.py --build generates iceriver/catboard.v
In the catboard.v I see wire cmd_inst_clock; which is not in cat_top.v.
Also many of the modules in catboard.v have this linealways @(posedge cmd_inst_clock) begin
What drives cmd_inst_clock? Thanks
Regards,
Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 

    On Friday, February 5, 2016 1:25 PM, Christopher Felton <chr...@gm...> wrote:
 

 On 2/5/2016 11:05 AM, Edward Vidal wrote:
> Hi All,I am trying to add these memmap_command_bridge,
> glbl_timer_ticks, Barebone and FIFOBus cores from (rhea)
> icestick_blinky_host.py  to my code. On the CAT-Board on pg 6 of the
> schematic the 100MHz oscillator provides
>
> signal USER_CLK which is connected to C8 of ICE40-HX8K-CT256.
>
> The catboard.pcf created with rhea, in the catboard.pcf file I see
> set_io clock C8.
>
> Do these 2 lines above have an impact on the ICE40 clock?
>
> clock=Clock(0, frequency=50e6) glbl = Global(clock, None)

Yes, they would but it would be an unexpected effect.  If
you are using the rhea.build, it will map the ports to
the board definitions - as long as the port names match
the pin names (which are typically the names from the
schematic / documents).

You can see in the CAT board definition this is already
defined: 
<https://github.com/cfelton/rhea/blob/master/rhea/build/boards/lattice/_catboard.py#L18>
This will be mapped to the `clock` port in your top-level
module.  So it should "just work" :)

The idea, if designing for a specific board you will have
a top-level for that board:

    def my_cat_design(clock, led, sw):
        # you might want to do more, like debounce,
        # sync, etc.
    reset = sw(0)  # sw[0] reset, get shadow signal
        glbl = Global(clock, reset)

Do note, when I tested the `memmap_command_bridge` on the
icestick it did not work with iceriver (yosys+aracne+icestorm)
but it did work with the icecube2.

Hope that helps,
Chris


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list


  

Re: [myhdl-list] (rhea) icestick_blinky_host.py

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

On 2/5/2016 11:05 AM, Edward Vidal wrote:
> Hi All,I am trying to add these memmap_command_bridge,
> glbl_timer_ticks, Barebone and FIFOBus cores from (rhea)
> icestick_blinky_host.py  to my code. On the CAT-Board on pg 6 of the
> schematic the 100MHz oscillator provides
>
> signal USER_CLK which is connected to C8 of ICE40-HX8K-CT256.
>
> The catboard.pcf created with rhea, in the catboard.pcf file I see
> set_io clock C8.
>
> Do these 2 lines above have an impact on the ICE40 clock?
>
> clock=Clock(0, frequency=50e6) glbl = Global(clock, None)

Yes, they would but it would be an unexpected effect.  If
you are using the rhea.build, it will map the ports to
the board definitions - as long as the port names match
the pin names (which are typically the names from the
schematic / documents).

You can see in the CAT board definition this is already
defined: 
<https://github.com/cfelton/rhea/blob/master/rhea/build/boards/lattice/_catboard.py#L18>
This will be mapped to the `clock` port in your top-level
module.  So it should "just work" :)

The idea, if designing for a specific board you will have
a top-level for that board:

     def my_cat_design(clock, led, sw):
         # you might want to do more, like debounce,
         # sync, etc.
	reset = sw(0)  # sw[0] reset, get shadow signal
         glbl = Global(clock, reset)

Do note, when I tested the `memmap_command_bridge` on the
icestick it did not work with iceriver (yosys+aracne+icestorm)
but it did work with the icecube2.

Hope that helps,
Chris

[myhdl-list] (rhea) icestick_blinky_host.py

[Edward V. <dev...@sb...>]

Hi All,I am trying to add these memmap_command_bridge,  glbl_timer_ticks, Barebone and FIFOBus
cores from (rhea) icestick_blinky_host.py  to my code.
On the CAT-Board on pg 6 of the schematic the 100MHz oscillator provides 

signal USER_CLK which is connected to C8 of ICE40-HX8K-CT256.

The catboard.pcf created with rhea, in the catboard.pcf file I see set_io clock C8.

Do these 2 lines above have an impact on the ICE40 clock?
 
clock=Clock(0, frequency=50e6)
glbl = Global(clock, None) 

Running python input_clk.py --convert generates cat_top.v.Running python input_clk.py --build generates iceriver/catboard.v
In the catboard.v I see wire cmd_inst_clock; which is not in cat_top.v.
Also many of the modules in catboard.v have this linealways @(posedge cmd_inst_clock) begin
What drives cmd_inst_clock?
https://github.com/develone/jpeg-2000-test/blob/master/pc_fast_blinker_jpeg/input_examples/input_clk.py
 Thanks,
Edward Vidal Jr. e-mail dev...@sb... 915-595-1613

Re: [myhdl-list] how is it with gtkwave and tracing interfaces?

[David B. <da...@be...>]

I have just played around. With the proposed modification it gives still the same results. e.g. i_dut exported signals are only DxD, DxE and QxD. No clock, no reset.
Then I started to play with the register definition, and some surprise comes:

1) Using this declaration the reset and clock is not exported (in fact, only signals which are directly used in the generator function are exported):

@always_seq(rc.ClkxC.posedge, rc.ResetxRN)
def ilogic():
    if DxE:
        QxD.next = DxD


2) if I modify the decorator not using always_seq, but only always as follows:

def register(rc, DxD, DxE, QxD):
    @always(rc.ClkxC, rc.ResetxRN)
    def ilogic():
        if rc.ResetxRN == 0:
            QxD.next = 0
        elif rc.ClkxC.posedge:
            if DxE:
                QxD.next = DxD
    return ilogic,

I can see in gtkwave all variables, including  reset and clock, which are exported as rc_ClkxC and rc_ResetxRN. It almost seems to me like the always_seq decorator just does not recognize rc.ClkxC.posedge and rc.ResetxRN as (interface) signals and thus does not export them. Or do I miss something?


many thanks for your feedback

.d.

----------------------------------------------
Dr. David Belohrad, Div. BE-BI
C.E.R.N. Site de Prevessin, F-01631 CERN CEDEX
http://www.cern.ch
Dav...@ce...
Tel +41.22.76.76318  Fax +41.22.76.69056
GSM +41.75.411.3455
----------------------------------------------



Christopher Felton <chr...@gm...> writes:

> On 1/31/16 6:59 AM, David Belohrad wrote:
>> ok, try this one. Do you see rc.ClkxC and rc.ResetxRN under i_dut in
>> gtkwave? I don't
>
> In your `i_dut` instance the generators access
> the `ClkxC` and `ResetxRN` ports, they don't access
> the interface, these are the local variables the
> tracer decides to traces these (as seen in the hierarchy).
>
> (from VCD file):
>      $var reg 1 # ClkxC $end
>      $var reg 1 $ ResetxRN $end
>
> I imagine if you pass `rc` and use `rc.*` in the
> `i_dut` instance you will see the interface hierarchy?
>
>
> I modified it to reference clock and reset in the
> testbench function.
>
>
>      def wrapper(self):
>          rc = self.rc
>          clock = self.rc.ClkxC
>          reset = self.rc.ResetxRN
>
>          def testbench():
>              @instance
>              def doreset():
>                  yield reset.pulse( (10, 12, 18) )
>
>              @instance
>              def stimulus():
>                  yield func(self)
>                  raise StopSimulation
>
>              i_clk = clock.gen()
>              i_dut = self.dut(*self.args)
>
>              return i_dut, i_clk, stimulus, doreset
>
>
> I use interfaces quite extensively and typically
> don't run into tracing issues - not sure what might
> be different here ...
>
>>
>> # really disgusting way how to link relative import sys
>> sys.path.append('/home/belohrad/git/didt/MyHDL/rhea')
>
> You can get around this by using in the rhea
> directory.
>
>     >> python setup.py develop
>
>>
>> from myhdl import *
>> import unittest from functools
>  > import wraps
>> from rhea.system.clock import *
>> from rhea.system.reset import *
>
> The intended use is
>
>    from rhea.system import Clock, Reset
>
> In Python3 the above won't work.
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] how is it with gtkwave and tracing interfaces?

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

On 1/31/16 6:59 AM, David Belohrad wrote:
> ok, try this one. Do you see rc.ClkxC and rc.ResetxRN under i_dut in
> gtkwave? I don't

In your `i_dut` instance the generators access
the `ClkxC` and `ResetxRN` ports, they don't access
the interface, these are the local variables the
tracer decides to traces these (as seen in the hierarchy).

(from VCD file):
     $var reg 1 # ClkxC $end
     $var reg 1 $ ResetxRN $end

I imagine if you pass `rc` and use `rc.*` in the
`i_dut` instance you will see the interface hierarchy?


I modified it to reference clock and reset in the
testbench function.


     def wrapper(self):
         rc = self.rc
         clock = self.rc.ClkxC
         reset = self.rc.ResetxRN

         def testbench():
             @instance
             def doreset():
                 yield reset.pulse( (10, 12, 18) )

             @instance
             def stimulus():
                 yield func(self)
                 raise StopSimulation

             i_clk = clock.gen()
             i_dut = self.dut(*self.args)

             return i_dut, i_clk, stimulus, doreset


I use interfaces quite extensively and typically
don't run into tracing issues - not sure what might
be different here ...

>
> # really disgusting way how to link relative import sys
> sys.path.append('/home/belohrad/git/didt/MyHDL/rhea')

You can get around this by using in the rhea
directory.

    >> python setup.py develop

>
> from myhdl import *
> import unittest from functools
 > import wraps
> from rhea.system.clock import *
> from rhea.system.reset import *

The intended use is

   from rhea.system import Clock, Reset

In Python3 the above won't work.

Regards,
Chris

Re: [myhdl-list] how is it with gtkwave and tracing interfaces?

[David B. <da...@be...>]

ok, try this one. Do you see rc.ClkxC and rc.ResetxRN under i_dut in gtkwave? I don't

# really disgusting way how to link relative
import sys
sys.path.append('/home/belohrad/git/didt/MyHDL/rhea')

from myhdl import *
import unittest
from functools import wraps
from rhea.system.clock import *
from rhea.system.reset import *

class RC(object):
    def __init__(self):
        self.ClkxC = Clock(0, frequency=160e6)
        self.ResetxRN = Reset(0, active = 0, async=True)


def register(rc, DxD, DxE, QxD):
    @always_seq(rc.ClkxC.posedge, rc.ResetxRN)
    def ilogic():
        if DxE:
            QxD.next = DxD
    return ilogic,

_trace = False

# decorator to trace problematic function
def trace(func):
    func.trace = True
    return func

#decorator with main bench initialization
def myhdltest(func):
    @wraps(func)
    def wrapper(self):

        def testbench():
            @instance
            def clockGen():
                yield self.rc.ClkxC.gen()

            @instance
            def reset():
                yield self.rc.ResetxRN.pulse( (10,12,18) )

            @instance
            def stimulus():
                yield func(self)
                raise StopSimulation

            i_dut = self.dut(*self.args)
            return i_dut, stimulus, reset, clockGen

        #tracedec = getattr(wrapper, 'trace', None)  # True or None
        #tracesel = getattr(self, 'trace', None)  # True or None
        #tracecmd = _trace  # True or False
        #trace = (x for x in (tracedec, tracesel, tracecmd) if x is not None).next()

        g = traceSignals(testbench) #if trace else self.dut(*self.args)
        Simulation(g).run()

    return wrapper


class testRegister(unittest.TestCase):

    def setUp(self):
        # prepare instance of the item

        self.DxD, self.QxD = [Signal(intbv(0)[8:]) for x in xrange(2)]
        self.DxE = Signal(bool(0))
        self.rc = RC()

        # test instance
        self.args = (self.rc, self.DxD, self.DxE, self.QxD)
        self.dut=register



    @trace
    @myhdltest
    def testRegister(self):

        # stimulus
        self.rc.ClkxC.next = 0
        self.DxD.next = 0
        self.DxE.next = 1
        yield join(self.rc.ClkxC.posedge, self.rc.ResetxRN.posedge)

        # reset stage finished
        self.DxD.next = 1
        for i in range(10):
            yield (self.rc.ClkxC.posedge)
            self.DxD.next = 0
        yield(delay(150))



unittest.main()

Re: [myhdl-list] how is it with gtkwave and tracing interfaces?

[David B. <da...@be...>]

did you run it with interface modification?  the test bench I attached does 
not use interface and runs just fine. when you modify it as I have 
described in my last email, I.e calling register using self.rc instead of 
clock and reset,  gtkwave does not show me the interface signals.


On January 31, 2016 12:44:38 Marcel Hellwig 
<1he...@in...> wrote:

> Hmmm. When I open gtkwave and look at the i_dut instance, I can see 5
> signals: ClkxC, DxD[7:0], DxE, QxD[7:0], ResetxRn
>
> so.. i don't get your problem, sorry :/
>
> Greetings
> Marcel
>
> On 31.01.2016 11:42, David Belohrad wrote:
>> Dear All,
>>
>> based on my previous question on how to do efficiently testbench I have 
>> made a small demo register, including a testbench to see the signals in the 
>> gtkwave (see below). It is a combination of Marcel's and Christopher's 
>> approaches. In addition I have added an interface having reset and clock 
>> signals.
>>
>> The testbench how it is below works fine, and in GTKwave under i_dut I have 
>> all the signals, including a reset and clock, so ... satisfaction.
>>
>> How, I want to pass the interface into the DUT, hence line
>>
>> self.args = (self.rc.ClkxC, self.rc.ResetxRN, self.DxD, self.DxE, self.QxD)
>>
>> becomes
>>
>> self.args = (self.rc, self.DxD, self.DxE, self.QxD)
>>
>> and register declaration:
>>
>> def register(ClkxC, ResetxRN, DxD, DxE, QxD):
>>     @always_seq(ClkxC.posedge, ResetxRN)
>>
>> becomes
>>
>> def register(rc, DxD, DxE, QxD):
>>     @always_seq(rc.ClkxC.posedge, rc.ResetxRN)
>>
>>
>> and now the mystery comes. I can run such testbench, and it runs again 
>> fine. Problem is, when looking on gtkwave signals, the interface signals 
>> are not there. Hence I cannot see ClkxC and I cannot see ResetxRN. I can 
>> somehow see the clock, as i_dut instantiates ClockList with register 
>> ClockList(0), which indeed contains the clock. ResetxRN however disappeared.
>>
>> Why is that? And how can I avoid this?
>>
>> thanks
>>
>> .d.
>>
>>
>>
>> --------------------------------------------------------------------------------
>> # really disgusting way how to link relative
>> import sys
>> sys.path.append('/home/belohrad/git/didt/MyHDL/rhea')
>>
>> from myhdl import *
>> import unittest
>> from functools import wraps
>> from rhea.system.clock import *
>> from rhea.system.reset import *
>>
>> class RC(object):
>>     def __init__(self):
>>         self.ClkxC = Clock(0, frequency=160e6)
>>         self.ResetxRN = Reset(0, active = 0, async=True)
>>
>>
>> def register(ClkxC, ResetxRN, DxD, DxE, QxD):
>>     @always_seq(ClkxC.posedge, ResetxRN)
>>     def ilogic():
>>         if DxE:
>>             QxD.next = DxD
>>     return ilogic,
>>
>> _trace = False
>>
>> # decorator to trace problematic function
>> def trace(func):
>>     func.trace = True
>>     return func
>>
>> #decorator with main bench initialization
>> def myhdltest(func):
>>     @wraps(func)
>>     def wrapper(self):
>>
>>         def testbench():
>>             @instance
>>             def clockGen():
>>                 yield self.rc.ClkxC.gen()
>>
>>             @instance
>>             def reset():
>>                 yield self.rc.ResetxRN.pulse( (10,12,18) )
>>
>>             @instance
>>             def stimulus():
>>                 yield func(self)
>>                 raise StopSimulation
>>
>>             i_dut = self.dut(*self.args)
>>             return i_dut, stimulus, reset, clockGen
>>
>>         #tracedec = getattr(wrapper, 'trace', None)  # True or None
>>         #tracesel = getattr(self, 'trace', None)  # True or None
>>         #tracecmd = _trace  # True or False
>>         #trace = (x for x in (tracedec, tracesel, tracecmd) if x is not None).next()
>>
>>         g = traceSignals(testbench) #if trace else self.dut(*self.args)
>>         Simulation(g).run()
>>
>>     return wrapper
>>
>>
>> class testRegister(unittest.TestCase):
>>
>>     def setUp(self):
>>         # prepare instance of the item
>>
>>         self.DxD, self.QxD = [Signal(intbv(0)[8:]) for x in xrange(2)]
>>         self.DxE = Signal(bool(0))
>>         self.rc = RC()
>>
>>         # test instance
>>         self.args = (self.rc.ClkxC, self.rc.ResetxRN, self.DxD, self.DxE, self.QxD)
>>         self.dut=register
>>
>>
>>
>>     @trace
>>     @myhdltest
>>     def testRegister(self):
>>
>>         # stimulus
>>         self.rc.ClkxC.next = 0
>>         self.DxD.next = 0
>>         self.DxE.next = 1
>>         yield join(self.rc.ClkxC.posedge, self.rc.ResetxRN.posedge)
>>
>>         # reset stage finished
>>         self.DxD.next = 1
>>         for i in range(10):
>>             yield (self.rc.ClkxC.posedge)
>>             self.DxD.next = 0
>>         yield(delay(150))
>>
>>
>>
>> unittest.main()
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
>
>
> ----------
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>
>
> ----------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] how is it with gtkwave and tracing interfaces?

[Marcel H. <1he...@in...>]

Hmmm. When I open gtkwave and look at the i_dut instance, I can see 5
signals: ClkxC, DxD[7:0], DxE, QxD[7:0], ResetxRn

so.. i don't get your problem, sorry :/

Greetings
Marcel

On 31.01.2016 11:42, David Belohrad wrote:
> Dear All,
> 
> based on my previous question on how to do efficiently testbench I have made a small demo register, including a testbench to see the signals in the gtkwave (see below). It is a combination of Marcel's and Christopher's approaches. In addition I have added an interface having reset and clock signals.
> 
> The testbench how it is below works fine, and in GTKwave under i_dut I have all the signals, including a reset and clock, so ... satisfaction.
> 
> How, I want to pass the interface into the DUT, hence line
> 
> self.args = (self.rc.ClkxC, self.rc.ResetxRN, self.DxD, self.DxE, self.QxD)
> 
> becomes
> 
> self.args = (self.rc, self.DxD, self.DxE, self.QxD)
> 
> and register declaration:
> 
> def register(ClkxC, ResetxRN, DxD, DxE, QxD):
>     @always_seq(ClkxC.posedge, ResetxRN)
> 
> becomes
> 
> def register(rc, DxD, DxE, QxD):
>     @always_seq(rc.ClkxC.posedge, rc.ResetxRN)
> 
> 
> and now the mystery comes. I can run such testbench, and it runs again fine. Problem is, when looking on gtkwave signals, the interface signals are not there. Hence I cannot see ClkxC and I cannot see ResetxRN. I can somehow see the clock, as i_dut instantiates ClockList with register ClockList(0), which indeed contains the clock. ResetxRN however disappeared.
> 
> Why is that? And how can I avoid this?
> 
> thanks
> 
> .d.
> 
> 
> 
> --------------------------------------------------------------------------------
> # really disgusting way how to link relative
> import sys
> sys.path.append('/home/belohrad/git/didt/MyHDL/rhea')
> 
> from myhdl import *
> import unittest
> from functools import wraps
> from rhea.system.clock import *
> from rhea.system.reset import *
> 
> class RC(object):
>     def __init__(self):
>         self.ClkxC = Clock(0, frequency=160e6)
>         self.ResetxRN = Reset(0, active = 0, async=True)
> 
> 
> def register(ClkxC, ResetxRN, DxD, DxE, QxD):
>     @always_seq(ClkxC.posedge, ResetxRN)
>     def ilogic():
>         if DxE:
>             QxD.next = DxD
>     return ilogic,
> 
> _trace = False
> 
> # decorator to trace problematic function
> def trace(func):
>     func.trace = True
>     return func
> 
> #decorator with main bench initialization
> def myhdltest(func):
>     @wraps(func)
>     def wrapper(self):
> 
>         def testbench():
>             @instance
>             def clockGen():
>                 yield self.rc.ClkxC.gen()
> 
>             @instance
>             def reset():
>                 yield self.rc.ResetxRN.pulse( (10,12,18) )
> 
>             @instance
>             def stimulus():
>                 yield func(self)
>                 raise StopSimulation
> 
>             i_dut = self.dut(*self.args)
>             return i_dut, stimulus, reset, clockGen
> 
>         #tracedec = getattr(wrapper, 'trace', None)  # True or None
>         #tracesel = getattr(self, 'trace', None)  # True or None
>         #tracecmd = _trace  # True or False
>         #trace = (x for x in (tracedec, tracesel, tracecmd) if x is not None).next()
> 
>         g = traceSignals(testbench) #if trace else self.dut(*self.args)
>         Simulation(g).run()
> 
>     return wrapper
> 
> 
> class testRegister(unittest.TestCase):
> 
>     def setUp(self):
>         # prepare instance of the item
> 
>         self.DxD, self.QxD = [Signal(intbv(0)[8:]) for x in xrange(2)]
>         self.DxE = Signal(bool(0))
>         self.rc = RC()
> 
>         # test instance
>         self.args = (self.rc.ClkxC, self.rc.ResetxRN, self.DxD, self.DxE, self.QxD)
>         self.dut=register
> 
> 
> 
>     @trace
>     @myhdltest
>     def testRegister(self):
> 
>         # stimulus
>         self.rc.ClkxC.next = 0
>         self.DxD.next = 0
>         self.DxE.next = 1
>         yield join(self.rc.ClkxC.posedge, self.rc.ResetxRN.posedge)
> 
>         # reset stage finished
>         self.DxD.next = 1
>         for i in range(10):
>             yield (self.rc.ClkxC.posedge)
>             self.DxD.next = 0
>         yield(delay(150))
> 
> 
> 
> unittest.main()
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

[myhdl-list] how is it with gtkwave and tracing interfaces?

[David B. <da...@be...>]

Dear All,

based on my previous question on how to do efficiently testbench I have made a small demo register, including a testbench to see the signals in the gtkwave (see below). It is a combination of Marcel's and Christopher's approaches. In addition I have added an interface having reset and clock signals.

The testbench how it is below works fine, and in GTKwave under i_dut I have all the signals, including a reset and clock, so ... satisfaction.

How, I want to pass the interface into the DUT, hence line

self.args = (self.rc.ClkxC, self.rc.ResetxRN, self.DxD, self.DxE, self.QxD)

becomes

self.args = (self.rc, self.DxD, self.DxE, self.QxD)

and register declaration:

def register(ClkxC, ResetxRN, DxD, DxE, QxD):
    @always_seq(ClkxC.posedge, ResetxRN)

becomes

def register(rc, DxD, DxE, QxD):
    @always_seq(rc.ClkxC.posedge, rc.ResetxRN)


and now the mystery comes. I can run such testbench, and it runs again fine. Problem is, when looking on gtkwave signals, the interface signals are not there. Hence I cannot see ClkxC and I cannot see ResetxRN. I can somehow see the clock, as i_dut instantiates ClockList with register ClockList(0), which indeed contains the clock. ResetxRN however disappeared.

Why is that? And how can I avoid this?

thanks

.d.



--------------------------------------------------------------------------------
# really disgusting way how to link relative
import sys
sys.path.append('/home/belohrad/git/didt/MyHDL/rhea')

from myhdl import *
import unittest
from functools import wraps
from rhea.system.clock import *
from rhea.system.reset import *

class RC(object):
    def __init__(self):
        self.ClkxC = Clock(0, frequency=160e6)
        self.ResetxRN = Reset(0, active = 0, async=True)


def register(ClkxC, ResetxRN, DxD, DxE, QxD):
    @always_seq(ClkxC.posedge, ResetxRN)
    def ilogic():
        if DxE:
            QxD.next = DxD
    return ilogic,

_trace = False

# decorator to trace problematic function
def trace(func):
    func.trace = True
    return func

#decorator with main bench initialization
def myhdltest(func):
    @wraps(func)
    def wrapper(self):

        def testbench():
            @instance
            def clockGen():
                yield self.rc.ClkxC.gen()

            @instance
            def reset():
                yield self.rc.ResetxRN.pulse( (10,12,18) )

            @instance
            def stimulus():
                yield func(self)
                raise StopSimulation

            i_dut = self.dut(*self.args)
            return i_dut, stimulus, reset, clockGen

        #tracedec = getattr(wrapper, 'trace', None)  # True or None
        #tracesel = getattr(self, 'trace', None)  # True or None
        #tracecmd = _trace  # True or False
        #trace = (x for x in (tracedec, tracesel, tracecmd) if x is not None).next()

        g = traceSignals(testbench) #if trace else self.dut(*self.args)
        Simulation(g).run()

    return wrapper


class testRegister(unittest.TestCase):

    def setUp(self):
        # prepare instance of the item

        self.DxD, self.QxD = [Signal(intbv(0)[8:]) for x in xrange(2)]
        self.DxE = Signal(bool(0))
        self.rc = RC()

        # test instance
        self.args = (self.rc.ClkxC, self.rc.ResetxRN, self.DxD, self.DxE, self.QxD)
        self.dut=register



    @trace
    @myhdltest
    def testRegister(self):

        # stimulus
        self.rc.ClkxC.next = 0
        self.DxD.next = 0
        self.DxE.next = 1
        yield join(self.rc.ClkxC.posedge, self.rc.ResetxRN.posedge)

        # reset stage finished
        self.DxD.next = 1
        for i in range(10):
            yield (self.rc.ClkxC.posedge)
            self.DxD.next = 0
        yield(delay(150))



unittest.main()

Re: [myhdl-list] please help with best way how to construct unittest testbench

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

Hi David,

A technique I find very useful is unittest's test discovery protocol that
simplifies collecting tests.
You can see a working sample here: https://github.com/unixie/myhdl_arch
I also like a CLI per test suite to enable debug of specific cases.

Cheers,
Uri

On 29 January 2016 at 19:31, David Belohrad <da...@be...> wrote:

> Dear both,
>
> thanks for the quick answer. It seems to be exactly what i've been looking
> for. And it seems to be insanely powerful. I just have to digest it a bit,
> because my python level is not up to date :)
>
> .d.
>
>
>
> Christopher Felton <chr...@gm...> writes:
>
> > On 1/29/16 9:05 AM, David Belohrad wrote:
> >> Dear all,
> >>
> >> my question is simple: when using unittest/testcase, one can write
> >> more testbenches. I have wrote one, like the one below. As you can
> >> see, the 'testbench' is quite long, as one has to initialize all the
> >> signals, instantiate the DUT, provide reset and clock, and it does
> >> nothing (yet).
> >>
> >> I want to add a second test-bench, but I'd like to re-use the
> >> fraction of instantiation and initialization of the DUT.
> >
> >
> > This is where things get fun :)  Yes, use the power of
> > Python to create reusable things, the following are some
> > reusability items I have used in the past:
> >
> > 1) This is the testbench template I use (I am sure it
> > can be improved upon):
> > https://gist.github.com/cfelton/17bfc798550aa9ed8e04
> >
> > 2) Clock object with gen method
> >
> >       clock = Clock(frequency=125e6)
> >       tbclk = clock.gen()
> >
> > https://github.com/cfelton/rhea/blob/master/rhea/system/clock.py
> >
> > 3) Reset object with `pulse` method
> >
> >       reset = Reset(0, active=0, async=True)
> >       ...
> >       @instance
> >       def tbstim():
> >           yield reset.pulse(10)
> >
> > 4) Interfaces with transactor methods!  This simplifies
> > a lot.
> >
> >      class SomeInterface():
> >          ...
> >
> >      bus = SomeInterface()
> >
> >      tbdut = my_dut(clock, reset, bus)
> >
> >      @instance
> >      def tbstim():
> >          yield bus.write()
> >          yield bus.read()
> >          # ...
> >
> > 5) portmap dicts, I create a dict with all the signals
> > in the module port arguments, the portmap can be reused.
> > Often I connect a portmap to a top-level (since top-level
> > ports a tied to the physical hardware and fixed)
> >
> >      def my_top_level_module(clock, reset, sdi, sdo):
> >          ...
> >      my_top_level_module.portmap = {
> >          clock: Clock(),
> >          reset: Reset(),
> >          sdi: Signal(bool(0))
> >          sdo: Signal(bool(0))
> >      }
> >
> >
> > Use functions to wrap common tasks, use generators to
> > wrap common simulation sequences, etc.
> >
> >      # another reset resuse
> >      def doreset(reset):
> >          reset.next = reset.active
> >          yield delay(30)
> >          reset.next = not reset.active
> >
> >     @instance
> >     def tbstim():
> >         # reuse in various stimulus
> >         yield doreset(reset)
> >
> >
> > As others have pointed out, use the various features
> > of Python to make reusable objects.
> >
> > Keerthan has some utilities to simplify some of these
> > task as well (setting up cosim, testbench generators, etc.)
> > https://github.com/jck/uhdl
> >
> > You don't need to limit yourself to the above examples,
> > there is a lot you can do with Python and reusability.
> >
> > Regards,
> > Chris
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Absolute timing

[Edward V. <dev...@sb...>]

Hi All,Yes Chris, what you provided helped quite a bit.
I have continued to add more work to the simulation and have tested on both the a 6 core AMD with Ubuntu 12.04 
and the RPi2B with RaspBian Jessie.
The results are below. 
 On a 6-Core AMD runningUbuntu 12.04 the simulation takes 
vidal@ws009:~/wkg/jpeg-2000-test/pc_fast_blinker_jpeg$time python test_top_a.py --testreal 1m6.287suser 1m6.036ssys 0m0.228s
On a RPi2B with pypy thesimulation takes 
time/opt/pypy-4.0.1-linux-armhf-raspbian/bin/pypy test_top_a.py --testreal 4m22.736suser 4m17.710ssys 0m2.180s
pi@mysshserver~/jpeg-2000-test/pc_fast_blinker_jpeg $ time python test_top_a.py--testreal 12m31.381suser 12m19.160ssys 0m2.330sUsing pypy provides a 1.43times improvement over python.
Simulation time in GTKWave.
23,039,990 ns 23.03 msec at50MHzIs this what I could expect on a XulA2-LX9 running at 120MHz or CAT-Board at 100MHz.

 
| 120000000 | 2.4 | 9.60E-003 |
| 100000000 | 2 | 1.15E-002 |


My simulation is "python test_top_a.py --test" https://github.com/develone/jpeg-2000-test/blob/master/pc_fast_blinker_jpeg/test_top_a.py

In the document https://github.com/develone/jpeg-2000-test/blob/master/pc_fast_blinker_jpeg/multi_instance_simulation.pdf 
In Appendix B I have python code that I need to convert to HDL, since it is currently used twice in the simulation.What is the best method to do this conversion?  Would like to use 16 instances instead of 4 which I am currently using.
 Thanks in advance.Regards,
Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 

    On Wednesday, January 27, 2016 11:28 AM, Christopher Felton <chr...@gm...> wrote:
 

 On 1/27/2016 10:01 AM, Edward Vidal wrote:
> Hello All, When you convert to Verilog, I see that `timescale
> 1ns/10ps near the top of the file .I don't see any timing information
> when you convert to VHDL. On the CAT-Board the default clock is
> 100MHz & on XulA2-LX9 the default clock is 12MHz.With the DCM I
> convert to 120MHz. For my simulation my clock is always 20nsec or
> 50MHz.  Why? Can someone explain? @always(delay(10)) def clkgen():
> clock.next = not clock If my simulation takes 1m35.611s using pypy,
> but total simulation time is 9139190 ns. What is the FPGA time?

The MyHDL simulator does not specify an absolute physical
time unit for each simulation time-step.  It's yours to
determine (e.g. `delay(1)` can be 1ns if you like).

It gets a little more complicated when creating VCD files
and converting.  When "tracing" the VCD file and the V*
time literals need to know the units.  For tracing the
time unit embedded in the VCD file and is controlled by
the `traceSignals.timescale` attribute and the default
is "1ns".

    In [2]: traceSignals.timescale
    Out[2]: '1ns'

If you are using the defaults and in your waveform viewer
you see 9,139,160 ns your real-time will be 9.1ms and
your clock will be the 50MHz as viewed in the waveform
viewer.

If I change `traceSignals.timescale = '1ps' and nothing
else in my test code.  The clock will be 50GHz and the
simulated time will be 9.1us as observed in the waveform
viewer

Hope that helps,
Chris


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list


  

Re: [myhdl-list] please help with best way how to construct unittest testbench

[David B. <da...@be...>]

Dear both,

thanks for the quick answer. It seems to be exactly what i've been looking for. And it seems to be insanely powerful. I just have to digest it a bit, because my python level is not up to date :)

.d.



Christopher Felton <chr...@gm...> writes:

> On 1/29/16 9:05 AM, David Belohrad wrote:
>> Dear all,
>>
>> my question is simple: when using unittest/testcase, one can write
>> more testbenches. I have wrote one, like the one below. As you can
>> see, the 'testbench' is quite long, as one has to initialize all the
>> signals, instantiate the DUT, provide reset and clock, and it does
>> nothing (yet).
>>
>> I want to add a second test-bench, but I'd like to re-use the
>> fraction of instantiation and initialization of the DUT.
>
>
> This is where things get fun :)  Yes, use the power of
> Python to create reusable things, the following are some
> reusability items I have used in the past:
>
> 1) This is the testbench template I use (I am sure it
> can be improved upon):
> https://gist.github.com/cfelton/17bfc798550aa9ed8e04
>
> 2) Clock object with gen method
>
>       clock = Clock(frequency=125e6)
>       tbclk = clock.gen()
>
> https://github.com/cfelton/rhea/blob/master/rhea/system/clock.py
>
> 3) Reset object with `pulse` method
>
>       reset = Reset(0, active=0, async=True)
>       ...
>       @instance
>       def tbstim():
>           yield reset.pulse(10)
>
> 4) Interfaces with transactor methods!  This simplifies
> a lot.
>
>      class SomeInterface():
>          ...
>
>      bus = SomeInterface()
>
>      tbdut = my_dut(clock, reset, bus)
>
>      @instance
>      def tbstim():
>          yield bus.write()
>          yield bus.read()
>          # ...
>
> 5) portmap dicts, I create a dict with all the signals
> in the module port arguments, the portmap can be reused.
> Often I connect a portmap to a top-level (since top-level
> ports a tied to the physical hardware and fixed)
>
>      def my_top_level_module(clock, reset, sdi, sdo):
>          ...
>      my_top_level_module.portmap = {
>          clock: Clock(),
>          reset: Reset(),
>          sdi: Signal(bool(0))
>          sdo: Signal(bool(0))
>      }
>
>
> Use functions to wrap common tasks, use generators to
> wrap common simulation sequences, etc.
>
>      # another reset resuse
>      def doreset(reset):
>          reset.next = reset.active
>          yield delay(30)
>          reset.next = not reset.active
>
>     @instance
>     def tbstim():
>         # reuse in various stimulus
>         yield doreset(reset)
>
>
> As others have pointed out, use the various features
> of Python to make reusable objects.
>
> Keerthan has some utilities to simplify some of these
> task as well (setting up cosim, testbench generators, etc.)
> https://github.com/jck/uhdl
>
> You don't need to limit yourself to the above examples,
> there is a lot you can do with Python and reusability.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] please help with best way how to construct unittest testbench

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

On 1/29/16 9:05 AM, David Belohrad wrote:
> Dear all,
>
> my question is simple: when using unittest/testcase, one can write
> more testbenches. I have wrote one, like the one below. As you can
> see, the 'testbench' is quite long, as one has to initialize all the
> signals, instantiate the DUT, provide reset and clock, and it does
> nothing (yet).
>
> I want to add a second test-bench, but I'd like to re-use the
> fraction of instantiation and initialization of the DUT.


This is where things get fun :)  Yes, use the power of
Python to create reusable things, the following are some
reusability items I have used in the past:

1) This is the testbench template I use (I am sure it
can be improved upon):
https://gist.github.com/cfelton/17bfc798550aa9ed8e04

2) Clock object with gen method

      clock = Clock(frequency=125e6)
      tbclk = clock.gen()

https://github.com/cfelton/rhea/blob/master/rhea/system/clock.py

3) Reset object with `pulse` method

      reset = Reset(0, active=0, async=True)
      ...
      @instance
      def tbstim():
          yield reset.pulse(10)

4) Interfaces with transactor methods!  This simplifies
a lot.

     class SomeInterface():
         ...

     bus = SomeInterface()

     tbdut = my_dut(clock, reset, bus)

     @instance
     def tbstim():
         yield bus.write()
         yield bus.read()
         # ...

5) portmap dicts, I create a dict with all the signals
in the module port arguments, the portmap can be reused.
Often I connect a portmap to a top-level (since top-level
ports a tied to the physical hardware and fixed)

     def my_top_level_module(clock, reset, sdi, sdo):
         ...
     my_top_level_module.portmap = {
         clock: Clock(),
         reset: Reset(),
         sdi: Signal(bool(0))
         sdo: Signal(bool(0))
     }


Use functions to wrap common tasks, use generators to
wrap common simulation sequences, etc.

     # another reset resuse
     def doreset(reset):
         reset.next = reset.active
         yield delay(30)
         reset.next = not reset.active

    @instance
    def tbstim():
        # reuse in various stimulus
        yield doreset(reset)


As others have pointed out, use the various features
of Python to make reusable objects.

Keerthan has some utilities to simplify some of these
task as well (setting up cosim, testbench generators, etc.)
https://github.com/jck/uhdl

You don't need to limit yourself to the above examples,
there is a lot you can do with Python and reusability.

Regards,
Chris

Re: [myhdl-list] please help with best way how to construct unittest testbench

[Marcel H. <1he...@in...>]

On 29.01.2016 16:05, David Belohrad wrote:
> Dear all,
> 
> my question is simple: when using unittest/testcase, one can write more testbenches. I have wrote one, like the one below. As you can see, the 'testbench' is quite long, as one has to initialize all the signals, instantiate the DUT, provide reset and clock, and it does nothing (yet).
> 
> I want to add a second test-bench, but I'd like to re-use the fraction of instantiation and initialization of the DUT. This is quite a work (not for this design, but for more complex designs). So far I have seen only testbenches, which were implementing each test case as a separate test function, which contained each time copy of signal assignments and instantiation of DUT. Is there any way, how to write a second test bench, and re-use the instances and signal assignments aready done? In fact, it would be great if I could just instantiate it once, assign signals, and then in the test functions just by driving the signals and compare with expected *without re-starting the simulation*.
> 
> Any hint appreciated.

I had the same issue this week and decided to make up my mind and try
some things out. I decided to use decoraters to wrap the tests to
instantiate the clock etc.

https://gist.github.com/punkkeks/9594800803bff9c57853

You have to use the _@myhdltest_ decoratetor to use this. In the setup
method you have to instantiate all your signals (for an example, just
see the gist).
To trace a testcase you can use one of the three methods:
  1. @trace decorator
  2. self.trace = True in the setUp method
  3. --trace as commandline argument

If you have any improvements, let me know ;)

Regards
Marcel

[myhdl-list] please help with best way how to construct unittest testbench

[David B. <da...@be...>]

Dear all,

my question is simple: when using unittest/testcase, one can write more testbenches. I have wrote one, like the one below. As you can see, the 'testbench' is quite long, as one has to initialize all the signals, instantiate the DUT, provide reset and clock, and it does nothing (yet).

I want to add a second test-bench, but I'd like to re-use the fraction of instantiation and initialization of the DUT. This is quite a work (not for this design, but for more complex designs). So far I have seen only testbenches, which were implementing each test case as a separate test function, which contained each time copy of signal assignments and instantiation of DUT. Is there any way, how to write a second test bench, and re-use the instances and signal assignments aready done? In fact, it would be great if I could just instantiate it once, assign signals, and then in the test functions just by driving the signals and compare with expected *without re-starting the simulation*.

Any hint appreciated.

thaaanks

.d.




--------------------------------------------------------------------------------
from unittest import TestCase

class testFIFO(TestCase):

    def __init__(self):
        self.FIFO_DEPTH = 4
        self.width = 8

    def testbench(self):
        # prepare instance of the item
        print "Testbench"

        rc = RC()
        DxD, QxD = [Signal(intbv(0)[self.width:]) for x in xrange(2)]
        DxE, QValidxS = [Signal(bool(0)) for x in xrange(2)]

        # test instance
        dut=fifo(rc, DxD, DxE, QxD, QValidxS, self.FIFO_DEPTH)

        # clock generation
        @always(delay(10))
        def clockGen():
            rc.ClkxC.next = not rc.ClkxC

        @instance
        def reset():
            rc.ResetxRN.next = 0
            yield(delay(147))
            rc.ResetxRN.next = 1

        # stimulus
        @instance
        def stimulus():
            rc.ClkxC.next = 0
            DxD.next = 0
            # yield (rc.ResetxRN.posedge)
            # yield (rc.ClkxC.posedge)
            yield join(rc.ClkxC.posedge, rc.ResetxRN.posedge)

            # unit
            self.assertEqual(QValidxS, 0)
            # reset stage finished
            for i in xrange(10):
                DxD.next = i
                yield (rc.ClkxC.posedge)
            DxD.next = 0

            yield(delay(200))
            raise StopSimulation()

        return dut, stimulus, clockGen, reset,

    def testOutputFlow(self):
        tb = traceSignals(self.testbench)
        sim = Simulation(tb)
        sim.run()
--------------------------------------------------------------------------------

Re: [myhdl-list] myhdl with cython?

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

On 1/28/2016 2:02 AM, David Belohrad wrote:
> when talking about pypy - has anyone succeeded to install there
> scipy? I'm using that quite a lot to do all the signal analysis. I
> did not manage to install it so for the moment I have to stick to
> cPython to do myhdl (as from such analyses I usually get bit widths
> and coefficients and other funny stuff).
>
> .d.

No, I have not successfully used numpy/scipy with pypy.
In the past I have done one of the following: 1) ran
the HDL simulation separate in pypy and analysis in
cpython; 2) implemented the functions I needed in pure
python [1].

There seem to be some pure numpy implementations that
can be used with pypy:

   https://github.com/wadetb/tinynumpy
   https://bitbucket.org/dblank/pure-numpy

Regards,
Chris

[1] 
https://speakerdeck.com/cfelton/python-scientific-and-numerical-computing-fast-with-pypy


>
>
>
> Christopher Felton <chr...@gm...> writes:
>
>>> My question, what would taking all of time?
>>
>> The pypy jit has a "warm-up" time it will not improve run-time on
>> simulations that execute quickly (less than a minute?).
>>
>> Regards, Chris
>>
>>

Re: [myhdl-list] myhdl with cython?

[David B. <da...@be...>]

when talking about pypy - has anyone succeeded to install there scipy? I'm using that quite a lot to do all the signal analysis. I did not manage to install it so for the moment I have to stick to cPython to do myhdl (as from such analyses I usually get bit widths and coefficients and other funny stuff).

.d.



Christopher Felton <chr...@gm...> writes:

>  > My question, what would taking all of time?
>
> The pypy jit has a "warm-up" time it will not improve
> run-time on simulations that execute quickly (less
> than a minute?).
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Absolute timing

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

On 1/27/2016 10:01 AM, Edward Vidal wrote:
> Hello All, When you convert to Verilog, I see that `timescale
> 1ns/10ps near the top of the file .I don't see any timing information
> when you convert to VHDL. On the CAT-Board the default clock is
> 100MHz & on XulA2-LX9 the default clock is 12MHz.With the DCM I
> convert to 120MHz. For my simulation my clock is always 20nsec or
> 50MHz.  Why? Can someone explain? @always(delay(10)) def clkgen():
> clock.next = not clock If my simulation takes 1m35.611s using pypy,
> but total simulation time is 9139190 ns. What is the FPGA time?

The MyHDL simulator does not specify an absolute physical
time unit for each simulation time-step.  It's yours to
determine (e.g. `delay(1)` can be 1ns if you like).

It gets a little more complicated when creating VCD files
and converting.  When "tracing" the VCD file and the V*
time literals need to know the units.  For tracing the
time unit embedded in the VCD file and is controlled by
the `traceSignals.timescale` attribute and the default
is "1ns".

     In [2]: traceSignals.timescale
     Out[2]: '1ns'

If you are using the defaults and in your waveform viewer
you see 9,139,160 ns your real-time will be 9.1ms and
your clock will be the 50MHz as viewed in the waveform
viewer.

If I change `traceSignals.timescale = '1ps' and nothing
else in my test code.  The clock will be 50GHz and the
simulated time will be 9.1us as observed in the waveform
viewer

Hope that helps,
Chris