Is it possible to watch variables and signals during debug?

Discussion in 'VHDL' started by Dufour, Aug 24, 2006.

  1. Dufour

    Dufour Guest

    I'm new in vhdl programming and I'm writing simple programs (I'm using
    xilinx ise webpack 7.1). When I debug my programs I would to watch the value
    of some variables and signals (they are not input/output), but I can't. By
    working with ISE I can see that the Test Bench Waveform permits to watch
    only input and output signals. How can I do?
    Thank you.
     
    Dufour, Aug 24, 2006
    #1
    1. Advertising

  2. Dufour wrote:
    > I'm new in vhdl programming and I'm writing simple programs (I'm using
    > xilinx ise webpack 7.1). When I debug my programs I would to watch the value
    > of some variables and signals (they are not input/output), but I can't.


    I write a testbench and use modelsim commands to display the waves.
    add wave * ;# Signals
    add wave /$mytb/main/* ;# Test variables
    add wave /$mytb/dut/main/* ;# UUT variables

    See the testbench here for more details:
    http://home.comcast.net/~mike_treseler/

    -- Mike Treseler
     
    Mike Treseler, Aug 24, 2006
    #2
    1. Advertising

  3. Dufour

    KJ Guest

    "Mike Treseler" <> wrote in message
    news:...
    > I write a testbench and use modelsim commands to display the waves.
    > add wave * ;# Signals
    > add wave /$mytb/main/* ;# Test variables
    > add wave /$mytb/dut/main/* ;# UUT variables
    >

    Is there a way to add variables to the wave 'after the fact'? By that I
    mean, if I'm at sim time 1 ms and want to see the entire history of some
    variable. I use the log -r /* in my Modelsim testbench script which allows
    signals to be added to the wave window and show the entire history but I
    haven't found how to do that with variables.

    KJ
     
    KJ, Aug 24, 2006
    #3
  4. KJ wrote:

    > Is there a way to add variables to the wave 'after the fact'? By that I
    > mean, if I'm at sim time 1 ms and want to see the entire history of some
    > variable. I use the log -r /* in my Modelsim testbench script which allows
    > signals to be added to the wave window and show the entire history but I
    > haven't found how to do that with variables.


    Me neither. However, sims on signal-less DUTs
    are so speedy that just adding the waves and restarting
    may be fast enough.

    -- Mike Treseler
     
    Mike Treseler, Aug 24, 2006
    #4
  5. Dufour

    Ricardo Guest

    You may start a simulation, select signals and vaiables you wish to
    see, then save a "wave.do" file.

    Next, you may take a look at auto-generated scripts for modelsim
    generated by ISE. Edit it. change the line "add wave *" (something like
    this) for "do wave.do"

    They are generated in the project folder (the *.FDO). You may edit them
    and change the way ise call modelsim (right click, edit properties and
    select a custom *.do file: you will find this there.

    You must save your file with another *.do extension (do not overwrite
    wave!!!). It may look annooying at firt look, but you will get familiar
    to it.

    Sds,

    Ricardo

    KJ escreveu:

    > "Mike Treseler" <> wrote in message
    > news:...
    > > I write a testbench and use modelsim commands to display the waves.
    > > add wave * ;# Signals
    > > add wave /$mytb/main/* ;# Test variables
    > > add wave /$mytb/dut/main/* ;# UUT variables
    > >

    > Is there a way to add variables to the wave 'after the fact'? By that I
    > mean, if I'm at sim time 1 ms and want to see the entire history of some
    > variable. I use the log -r /* in my Modelsim testbench script which allows
    > signals to be added to the wave window and show the entire history but I
    > haven't found how to do that with variables.
    >
    > KJ
     
    Ricardo, Aug 24, 2006
    #5
  6. Dufour

    KJ Guest

    Ricardo wrote:
    > You may start a simulation, select signals and vaiables you wish to
    > see, then save a "wave.do" file.
    >
    > Next, you may take a look at auto-generated scripts for modelsim
    > generated by ISE. Edit it. change the line "add wave *" (something like
    > this) for "do wave.do"
    >
    > They are generated in the project folder (the *.FDO). You may edit them
    > and change the way ise call modelsim (right click, edit properties and
    > select a custom *.do file: you will find this there.
    >
    > You must save your file with another *.do extension (do not overwrite
    > wave!!!). It may look annooying at firt look, but you will get familiar
    > to it.
    >


    I'm not sure I understand how that addresses my question, could you
    clarify. The scenario is that I'm already into a simulation (say
    t=1ms) and I find a problem that I need to investigate. What I would
    normally do is...

    - Add the signal being flagged as a problem by the testbench to the
    wave window so that I can see the entire history of what went on with
    that signal up to now where I see that there is the problem that I'm
    trying to fix.
    - Iteratively add signals to the wave window to backtrack through the
    logic until I get to the point where I can see in the source code where
    the root cause error is.

    Generally speaking, the first point where the testbench detects a
    problem is reporting only the first detected symptom of something gone
    wrong and is not the root cause of the problem. That root cause
    problem that started the chain of events happened at some earlier time
    in the simulation so you need to have the history of each of those
    signals in order to fix the problem. With the Modelsim log -r /*
    command prior to run I can capture that entire history for later
    display in the wave window when I so choose. But if you replace the
    word 'signal' with 'variable' in all of the above I haven't found out
    how to display the history of any variables that led up to the current
    time.

    I think what you've described is a way to save the list of signals and
    pull them back up again on a subsequent simulation but that's not what
    I was looking for.

    KJ
     
    KJ, Aug 24, 2006
    #6
  7. Dufour

    KJ Guest

    Mike Treseler wrote:
    > However, sims on signal-less DUTs are so speedy


    Do you have any reference designs that demonstrate this? I wrote one
    for a simple counter a while back using signals and then variables and
    I think I remembered measuring about a 10% improvement using variables.
    At the time I didn't feel that 10% was worth the risk of having to
    restart sim just to see history on variables that are in the logic path
    towards the root problem but I also didn't think a counter was
    necessarily representative of the extensive use that you make with
    variables either.

    I realize that the entity boundaries will be signals that can be waved
    to backtrack through during debug, but I know I also tend to wave
    internal signals within the architecture during that debug time.

    > that just adding the waves and restarting may be fast enough.


    Agreed, depending on what is being test, it may be fast enough to
    restart. But even so, the time lost doing so would need to be deducted
    from the 10% speedup (or whatever that number that you see).

    KJ
     
    KJ, Aug 24, 2006
    #7
  8. Dufour

    Dufour Guest

    "Mike Treseler" :

    > I write a testbench and use modelsim commands to display the waves.
    > add wave * ;# Signals
    > add wave /$mytb/main/* ;# Test variables
    > add wave /$mytb/dut/main/* ;# UUT variables
    >
    > See the testbench here for more details:
    > http://home.comcast.net/~mike_treseler/
    >
    > -- Mike Treseler


    I'll try.
    Thank you very much.
     
    Dufour, Aug 24, 2006
    #8
  9. KJ wrote:

    > Do you have any reference designs that demonstrate this?


    No, I've just noticed that testbench elaboration
    and run times increase with the number of signal bits
    in the DUT.

    > I wrote one
    > for a simple counter a while back using signals and then variables and
    > I think I remembered measuring about a 10% improvement using variables.


    That sounds about right if the output register
    is the only register. However, a complex design entity
    has many more internal registers than output registers.

    I write a command (do) file that lights up the processes I am working
    on, and just run that when I need to look at waves.
    You are correct that this is something I wouldn't
    have to do if everything I needed to look at were a signal.
    But then, writing the command file is a simple task
    and typing "do mywaves.do" isn't much harder
    than typing "add waves * "

    > At the time I didn't feel that 10% was worth the risk of having to
    > restart sim just to see history on variables that are in the logic path
    > towards the root problem


    Certainly not worth modifying working code,
    but something to consider for next time.
    I am certain that the speedup is better
    than 10% for processes with hundreds
    or thousands of internal register bits.

    > but I also didn't think a counter was
    > necessarily representative of the extensive use that you make with
    > variables either.


    I agree. A better speed battle might be a single
    variable array of 1000 prescale counters vs
    a generate loop or instances of the same counters.

    > I realize that the entity boundaries will be signals that can be waved
    > to backtrack through during debug, but I know I also tend to wave
    > internal signals within the architecture during that debug time.


    I find that looking at the output
    waves is often enough to debug a problem
    using code inspection or by tracing code
    and variables. These debugging
    techniques much less useful for a
    multiprocess design.

    >> that just adding the waves and restarting may be fast enough.

    >
    > Agreed, depending on what is being test, it may be fast enough to
    > restart. But even so, the time lost doing so would need to be deducted
    > from the 10% speedup (or whatever that number that you see).


    My best argument is above.
    I don't really ever have to restart to see waves.


    -- Mike Treseler
     
    Mike Treseler, Aug 24, 2006
    #9
  10. Dufour

    Ajeetha Guest

    Sometime back I faced similar issue, and IIRC - I managed to add VHDL
    variables (those inside processes, and named processes to be specific)
    by explicitly naming them i.e.

    p1 : process
    variable a_var : bit;
    begin
    wait;
    end process p1;

    I do:

    log /top/dut/p1/a_var

    May be that limitation is still around! It is such a pain to list all
    named variables. VCS-MX (and its GUI - DVE) is lot easier in this
    aspect - IMHO. Not sure what NC does.

    HTH
    Ajeetha, CVC
    www.noveldv.com
    * A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
    h**p://www.systemverilog.us/
    * SystemVerilog Assertions Handbook
    * Using PSL/Sugar
     
    Ajeetha, Aug 25, 2006
    #10
  11. Ajeetha wrote:

    > log /top/dut/p1/a_var


    I just tried it for a whole process, and that works too!
    For example:

    log /top/dut/p1/*

    Covers all the variables in p1.
    Thank you very much for sharing this tip!

    > May be that limitation is still around! It is such a pain to list all
    > named variables.


    If Modelsim had the problem, it is solved at or before version 6.2a.

    -- Mike Treseler
     
    Mike Treseler, Aug 25, 2006
    #11
  12. Dufour

    Ajeetha Guest

    Mike,
    Glad that someone was able to help the all time helper - Mike :)

    > log /top/dut/p1/*
    >
    > Covers all the variables in p1.


    BTW - what I was indeed referring to (from my original tests, didn't
    verify it recently) was - issue with unnamed prcoesses, but I guess
    even VCSMX has that issue per-se. Anyway I personally name all my
    prcoesses and IMHO that's the right way.


    Regards
    Ajeetha, CVC

    Mike Treseler wrote:
    > Ajeetha wrote:
    >
    > > log /top/dut/p1/a_var

    >
    > I just tried it for a whole process, and that works too!
    > For example:
    >
    > log /top/dut/p1/*
    >
    > Covers all the variables in p1.
    > Thank you very much for sharing this tip!
    >
    > > May be that limitation is still around! It is such a pain to list all
    > > named variables.

    >
    > If Modelsim had the problem, it is solved at or before version 6.2a.
    >
    > -- Mike Treseler
     
    Ajeetha, Aug 25, 2006
    #12
  13. Ajeetha wrote:

    > Anyway I personally name all my
    > processes and IMHO that's the right way.


    Me too.
    Modelsim uses a line number otherwise.

    one : process(reset, clock) is ...

    There, that didn't take long :)

    -- Mike Treseler
     
    Mike Treseler, Aug 25, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Taras_96
    Replies:
    5
    Views:
    2,259
    Taras_96
    Apr 14, 2005
  2. David Binnie

    signals and variables

    David Binnie, Feb 2, 2006, in forum: VHDL
    Replies:
    3
    Views:
    4,016
    Ralf Hildebrandt
    Feb 2, 2006
  3. Brad
    Replies:
    8
    Views:
    419
  4. Dmitry Korolyov

    Datagrid not updated during delete, but updated during insert and update

    Dmitry Korolyov, Sep 22, 2003, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    439
    Dmitry Korolyov
    Sep 22, 2003
  5. mmxmsmmzm@.
    Replies:
    3
    Views:
    113
    Sn!pe
    Sep 8, 2008
Loading...

Share This Page