Conditional signal assignment or process statement

Tue Apr 19, 2011 5:25 pm   

On Apr 19, 4:01 pm, rickman <gnu...@gmail.com> wrote:

Using Riviera-PRO on Linux (YMMV on other Aldec simulators/platforms)

View->Debug Windows enable Hierarchy Viewer (shortcut alt + 5) and
Object Viewer (alt + 6)

After elaboration, navigate to the appropriate process and the
variables declared by that process will show up in Object Viewer.
Right click->Add to->Waveform.

Alternatively use the command "wave sim:/path/to/your/process/
variable"

Tue Apr 19, 2011 8:34 pm   

On Apr 19, 11:25 am, Chris Higgs <chiggs...@gmail.com> wrote:

My UI is not the same, but in the process of messing about with it to
see if it comes close to yours, I found how to do it. The Design
Browser sounds like it is similar to your Hierarchy Viewer. Once I
select the appropriate process the variables are available to add to
the waveform. It seems odd that I can add signals to the waveform
display from the source file, but not variables.

This will help with debugging variables, but it still does not
supplant the Call Stack and breakpoints because variables update in
zero time and so waveforms won't show everything that happens with
them.

Rick

Wed Apr 20, 2011 3:16 pm   

On Apr 19, 7:34 pm, rickman <gnu...@gmail.com> wrote:

[variables in the wave view]

But this is a red herring. Waveforms can't show
everything that happens with signals, either.

A signal's driver can be updated many times in a
given delta cycle, and only the last such update
will actually affect the signal in the upcoming
delta. (Of course the story isn't even that
simple in the general case, but for zero-delay
RTL code it's close.) You can't see these driver
updates unless you watch the code executing.

I know, of course, that people tend to do more
complicated things with variables than they do
with repeated assignment to signals, so the
problem may be more severe with variables in
practice. But there isn't much difference
in principle.

The truth is that we EEs have grown accustomed
to a level of visibility of our code's activity
that makes little sense to software people, for
whom invisible variables are a matter of routine.
We get that visibility only because almost all
the objects whose values we care about are static
and can be traced/dumped easily as a function of
simulation time. As soon as you start to do
anything interesting and software-like, you
can't do that quite so easily and it becomes
much more important to be able to trace code
execution - there's no shortage of ways to do it.

Better still is to be able to reason about your
code so that you can think your way through the
offending code's behaviour to see where you
messed-up. For me, a great way to achieve that
is to add plenty of assertions; figuring out
how to write the assertions is a powerful
encouragement to think rigorously about your
code, and if you find you *can't* write assertions
that make sense, it's a fair bet that the code
in question isn't properly designed. And well-
written assertions often find the cause of an
error long before its effect would be visible
in waves.
--
Jonathan Bromley

Wed Apr 20, 2011 6:40 pm   

On Apr 19, 11:25 am, Chris Higgs <chiggs...@gmail.com> wrote:

When you do that, does it show the entire history of the variable from
t=0 until t=now? Or does it only allow you to see the variable from
t=now until t=future?

KJ

Wed Apr 20, 2011 7:04 pm   

On Apr 20, 5:40 pm, KJ <kkjenni...@sbcglobal.net> wrote:

The variable is traced from t=now onwards (this is the same behaviour
as tracing signals). Recording everything in the database in case you
want to retrospectively view it (to allow t=0 until t=now) sounds
expensive! There may be an option to do that but I've never needed it
- I trace whatever signals/variables (using wildcards) before starting
the simulation.

Wed Apr 20, 2011 9:23 pm   

On Apr 20, 1:04 pm, Chris Higgs <chiggs...@gmail.com> wrote:

OK, good to know. For Modelsim, the 'log -r /*' logs all signals to
disk (one can also be more specific about which signals if one
chooses). I agree it *seems* like it should be expensive, but I
haven't really found that to be the case. Then when I need a signal
for debug it can be added to the wave window and the entire history is
displayed. Having the entire history of every signal available to be
waved is mighty handy.


Since I don't generally know what assertion will fail ahead of time, I
don't know what signals I would be interested in prior to starting the
simulation. I dislike restarting and re-running simulations because I
guessed wrong about which signals I might want.

Kevin Jennings

Thu Apr 21, 2011 2:35 am   

On Apr 20, 9:16 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

I think you misrepresent what happens with a signal. Although many
assignments can be made to a signal, it is never updated until the
process reaches a stopping point, either a wait or the end of the
process. Only then is the value of the signal updated. You may feel
this is semantics, but the point is that I don't care about
assignments that don't impact the value of the signal, the intention
of the code is for them to be ignored.

A variable is different. It is updated just like a variable in
software where each intermediate value can be significant. If I can't
see those intermediate values, I have lost information about the
process which can make it harder to debug.

Perhaps there is value in single stepping multiple assignments to a
signal if you want to debug the code making those assignments. But
the way I write code this is seldom and issue. About the only time I
have multiple assignments to a signal in a process is when I first
assign a default value and later assign another value in specific
instances. This is not complex to debug and does not require single
stepping or breakpoints. Waveform viewing works just fine for that.



In theory, theory and practice are the same; in practice they can
differ considerably. The reality is that I very seldom use
breakpoints and single stepping to debug signals. My logic design
methods are easy to debug using waveforms. I don't see any reason to
make that more complex than it is.



I use assertions in my test benches. I don't use them in my target
code. Maybe there are things I can learn about that idea.

Rick

Thu Apr 21, 2011 4:49 am   

On Apr 20, 8:58 pm, rickman <gnu...@gmail.com> wrote:

Assertions should also be placed wherever possible, definitely not
restricted to testbench code. What you get then is a self checking
design which is even better but usually not as comprehensive as a self
checking testbench.

Assertions in the design can be thought of as 'better' in that they
will be active and checked which each and every instantiation of that
widget, not just in the original testbench for the widget.

Assertion in the design are usually 'not as comprehensive' in that it
is not always practical to compute all of the outputs within the
design itself. Interface handshake signal protocols can almost always
be checked, the data path might not short of writing a second copy of
the code. As an example, if you were to write the code for a JPEG
encoder, you would probably be better off validating correct operation
by reading files that have been computed by some separate widely used
tool that presumably has a few miles under its belt. This type of
thing though would best be put into a testbench for the encoder. If
you put that form of checking into the encoder than each and every
instantiation would have to somehow get the file name inputs through
some private interface.

In any case, it quickly becomes obvious which things 'could' be
checked in the design and which probably should not...and then put
those that 'could' be checked into the design so that they will be
checked forever and for always. You'll get a more robust design since
your self-checking design will catch bugs (or validate correct
operation) as that design gets reused in other applications.

On the other hand, if you don't develop any reusable widgets, it
probably doesn't matter where you put your assertions.

Kevin Jennings

Fri Apr 22, 2011 4:30 am   

On 4/19/2011 10:34 AM, rickman wrote:


Not odd at all.
Suppose that two processes
each had a variable named cnt_v.
Since the variables are not the same,
the only way to properly
label the waves is by process.


In a synchronous design,
the value of the wave is probably the one I want.
If I really need to see the
"gate by gate" (delta by delta) value,
I trace code and break on a variable value.

-- Mike Treseler

Fri Apr 22, 2011 7:45 pm   

On Apr 22, 12:30 am, Mike Treseler <mtrese...@gmail.com> wrote:

Why wouldn't the tool know which process a variable is in from the
source??? Everything else comes from the source...



Not delta by delta, but yes, gate by gate flow. That is what I'm
saying. You don't get a choice with variables. If you need to see
how they are calculated when used for intermediate values you have to
trace the code. With signals every time the value changes, it is
reflected in the state of the signal in the waveform display and you
only need to look at the source once you have found the location of
the problem.

Of course there is no one size fits all, but waveforms seem to be the
best approach for most problems.

Rick

Fri Apr 22, 2011 9:02 pm   

On Apr 20, 9:49 pm, KJ <kkjenni...@sbcglobal.net> wrote:

It is much easier to control the conditions under which an assertion
is evaluated when the assertion is inserted into the design (RTL)
code. A single concurrent assertion statement can make sure something
allways/never happens. Strategically placing a sequential assertion
statement inside an existing branch of the code allows specifically
targeting that part of the code. And it is easier to access local
variables/signals from within their scope.

On the other hand, RTL assertions don't do much good when verifying
the gate level model!

Andy