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