Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Conditional signal assignment or process statement

Reply
Thread Tools

Conditional signal assignment or process statement

 
 
KJ
Guest
Posts: n/a
 
      04-14-2011
On Apr 14, 4:18*am, Tricky <(E-Mail Removed)> wrote:
> On Apr 13, 11:31*pm, Andy <(E-Mail Removed)> wrote:
>
> Ideally, your final test
> should be a black box test, with a self checking testbench. It worries
> me when I see designers stare at waveforms all day and using this for
> their verification. They should be using output data as the test - no
> waveforms needed.


Just to be clear, I'm not talking about using waveforms for
verification. What they are used for is investigation when the
verification assertion fails...after all, one does not intentionally
write bad code in the first place so the fact that an assertion has
failed implies there is a problem somewhere that needs investigating.

If the root cause of the problem (which you do not know a priori)
happens to have occurred at the same time as the assertion (which is a
symptom, not the problem itself), then one will have access to the
*current* state of all signals and variables. Maybe that's enough to
solve the problem, but many times one needs to see some history in
addition to the current state of signals and variables in order to
make the definitive diagnosis.

By Andy's own admission he does not solve the current problem but
typically can wait for the problem to occur again after the first time
- "just catch it again on the next time around"
- "and insert a few breakpoints and monitors if necessary" (implies
running the sim s'more)

Sometimes (maybe many times) that is sufficient. But it is just as
likely that whatever the original problem that caused the first
assertion, if you continue running the sim, has now caused a second
downstream problem that just makes it more difficult because the
symptoms of this secondary problem is less directly related to the
original problem.

Even the software guys write out a trace log file which captures
important (to them) information about events that happen. They don't
simply capture the current state of everything at the point of the
failure...the history of what leads up to the problem is generally the
key to solving the problem. The fact that this history gets stored in
a file that is viewable as signals in a sim tool and not as a list of
statement executions is not relevant and has nothing to do with
'source code debugging'. It means you're making use of the tools that
are available. Not using the history that is available to you is a
choice and has a cost, but that choice is not about 'source code
debugging' versus 'waveform debugging'

Kevin Jennings
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      04-14-2011
On Apr 14, 4:18*am, Tricky <(E-Mail Removed)> wrote:
> On Apr 13, 11:31*pm, Andy <(E-Mail Removed)> wrote:
>
>
>
> > I use waveforms occasionally to get a look at an interface (external
> > or internal) but those are always signals anyway (ports). I use
> > assertions in both the RTL and the testbench which stop the simulation
> > when something goes wrong, then I can observe the variables and
> > signals I need, and insert a few breakpoints and monitors if
> > necessary. Given the cyclical nature of most hardware designs, it is
> > often not necessary to "back up" to see what happened, just catch it
> > again on the next time around. Backing up can be a pain though if I
> > have to. Most of the RTL assertions get put in during design or unit
> > testing, so they are already there by the time I have a larger system
> > simulation that would be time consuming to restart (and that would be
> > severely slowed down by dumping every signal to a file "just in
> > case".) I'm a big proponent of self-checking testbenches, and they
> > don't use waveforms either.

>
> > Most of us use methods we are most comfortable with, and using
> > waveforms is very similar to the typical test equipment in the lab
> > that we learned on. I started using the source code debugger after
> > working with the SW driver guys to debug HW/SW issues in the lab. I
> > had also taken a couple of Ada courses to sharpen my VHDL, and was
> > exposed to the techniques there. Then I started trying some of those
> > techniques in my VHDL simulations, and it worked well for me.

>
> > But what works well for me may not work for others. Having multiple
> > examples to accomplish the same thing allows users to find what works
> > best for them individually.

>
> > Andy

>
> I can see where you're coming from andy. Ideally, your final test
> should be a black box test, with a self checking testbench. It worries
> me when I see designers stare at waveforms all day and using this for
> their verification. They should be using output data as the test - no
> waveforms needed. Working in video I use bitmaps for input and output
> data. Its so much easier looking at a whole picture than looking at a
> stream of pixels. Often this output picture gives you a clue as to
> whats wrong - its normally very obviously when something has gone
> wrong doing this. Then I can get in amongst the waveform for more
> specific debugging, using the clues from the output.


I agree that verification is best done by the code and not by viewing
waveforms. In fact, sometimes I think that my project is actually a
matter of debugging the test bench and the FPGA design being verified
is just a side effect!

The importance of proper verification is drummed into me every time I
don't do it. Just like the time they omitted an unnecessary test on
the Hubble Space Telescope.

Rick
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      04-14-2011
On Apr 14, 4:37*am, Martin Thompson <(E-Mail Removed)> wrote:
> Andy <(E-Mail Removed)> writes:
> > I use waveforms occasionally to get a look at an interface (external
> > or internal) but those are always signals anyway (ports). I use
> > assertions in both the RTL and the testbench which stop the simulation
> > when something goes wrong, then I can observe the variables and
> > signals I need, and insert a few breakpoints and monitors if
> > necessary.

>
> That's much the same as the methods I use (and even the odd printf^H^H^H^H^H
> report statement *
>
> I'm sure Aldec can put variables in the wave window - it may be that (as with
> Modelsim) you have to do it before the sim for it to log them. *At the subblock
> level, adding a few variables and restarting is not usually a killer - especially
> when you have asserts already in to stop the simulation as soon as thingsgo
> wrong.


Please show me how to do this. I have added variables to the waveform
window until I was blue in the face and their values never show up.
It makes some sense. Variables are not defined outside of the
process, function or procedure and in many cases do not retain a value
between invocations. So what would be displayed?

I add variables by selecting them in the source file, right clicking
and selecting "Add to waveform". But I can do this with anything in
the design including VHDL keywords, so being able to add it to the
waveform display doesn't mean anything.

If I set a breakpoint and single step, I can see the variables in the
Call Stack window and watch them change. But they never show up in
the waveform. That further makes sense since a variable can change
value several times with no time ticking off. How would you display
that in a time based waveform?


> (The variables I want to see are usually state variables - it'd be great
> to be able to do "log -r *state" on variables
>
> > Most of us use methods we are most comfortable with, and using
> > waveforms is very similar to the typical test equipment in the lab
> > that we learned on. I started using the source code debugger after
> > working with the SW driver guys to debug HW/SW issues in the lab. I
> > had also taken a couple of Ada courses to sharpen my VHDL, and was
> > exposed to the techniques there. Then I started trying some of those
> > techniques in my VHDL simulations, and it worked well for me.

>
> And there are times when I'm writing embedded software that I'd really like a
> waveform trace of my C variables


Too bad they don't have signals in C... Sometimes I turn variables
into signals by outputting them on pins which can be displayed as
waveforms by a logic analyzer. ;^)

Rick
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      04-14-2011
On Apr 13, 7:04*pm, Jonathan Bromley <(E-Mail Removed)>
wrote:
> On Wed, 13 Apr 2011 04:28:06 -0700 (PDT), rickman wrote:
> > you are making claims without
> >supporting them. *Can you tell me why you believe your position? *So
> >far you have simply stated it.

>
> OK, let's keep separate things separate.
>
> The bit that got my dander up was your implied, but
> clear, statement that fewer lines of code makes for
> fewer bugs. *


Mistake #1. I didn't say that and you inferred rather than my
implying it.

"Which do you think is easier to read and provides fewer opportunities
for errors?"

I was comparing the two sets of code, not making a general
statement.


....snipped resulting conclusions...

> More directly related to what you posted
> is the question of the most desirable
> granularity to which you should decompose
> a problem. *


At least here you don't say that I made a statement about
granularity. This is your topic. I'm not even clear on how this
issue results from the OP's post. I do see how it relates to a wider
conversation about coding in general, but not how it connects to me or
my post. What did I write in regards to this?

....snip resulting discussion...

> Despite all this fence-sitting, there is
> something that seems obvious to me. *
> Breaking a design into excessively small
> pieces (transistors!!) clearly obscures
> its functionality. *Leaving a design in
> huge monolithic chunks (an entire FPGA
> in one VHDL process!!) is clearly hopeless
> too; no-one could possibly understand it.
> Somewhere in the middle there is an
> optimum - not ideal, but certainly better
> than either end of that spectrum. *Merely
> saying "simpler is better" is inadequate.


I don't agree that any of the three approaches is the "right" one.
Rather to understand the design you need to understand as many levels
as are important to the design. Typically there are parts of an HDL
design that I want to see from the 10,000 m view, some I want to see
from 10 m, some while sitting in front of it and some I want to see
with a microscope. It all depends on which parts are standard,
straightforward stuff and which parts are doing something more complex
that needs to be explained more clearly. There are many times I use
concurrent code because adding it to a process adds nothing to the
clarity. It is still an assignment, but now, for example, a data path
mux is obscured by all the control logic statements or vice versa.
But mostly I just don't use combinatorial processes except for
exceptions where it makes the code more clear.


> For me, pieces of design small enough to
> write as a single concurrent statement are
> almost never big enough to give me useful
> clues about how they contribute to the
> overall functionality (unless you put a
> function call in the expression).


I'm curious, how do you write, for example, a data path mux if you
don't put it in a concurrent statement? Do you lump it in with
unrelated stuff? I had a design for a mulaw encoder with two sources,
the data from the CODEC and a tone generator as well as a mute
function. I added the data path mux (with mute function) using a
combinatorial statement because to me it was not part of the mulaw
logic so I didn't want to put it in the process for the mulaw logic.
In fact, all of the data path to connect the mulaw logic with the
CODEC and the IP interface was concurrent statements, some just simple
assignments with no logic to connect wires... er, I mean signals. Can
you tell I've been working with Verilog lately?

What would you have done differently?

Funny, I think is was one time I used variables for the mulaw encoding
because that seemed like the right way to go given that it was all
combinatorial and required several sequential steps. It also
translated easier from the C code I used as a reference. It had it's
own test bench so debugging with variables was not really an issue.


> Sorry about the lengthy ramblings. *You
> did ask for a justification


Yup, be careful what you ask for... ;^)

You are always good for some interesting perspectives. Thanks.

Rick
 
Reply With Quote
 
Martin Thompson
Guest
Posts: n/a
 
      04-15-2011
rickman <(E-Mail Removed)> writes:
<on waveforms of variables>
> Please show me how to do this. I have added variables to the waveform
> window until I was blue in the face and their values never show up.
> It makes some sense. Variables are not defined outside of the
> process, function or procedure and in many cases do not retain a value
> between invocations. So what would be displayed?


I'm not an Aldec user, but on a brief perusal of the manual, I can't see how to
do it either How disappointing!

> If I set a breakpoint and single step, I can see the variables in the
> Call Stack window and watch them change. But they never show up in
> the waveform. That further makes sense since a variable can change
> value several times with no time ticking off. How would you display
> that in a time based waveform?


Modelsim shows the value at the end of the process - effectively it wires it to
a signal at the end of the process and displays that.

>> And there are times when I'm writing embedded software that I'd really like a
>> waveform trace of my C variables

>
> Too bad they don't have signals in C... Sometimes I turn variables
> into signals by outputting them on pins which can be displayed as
> waveforms by a logic analyzer. ;^)
>


Yep, BTDT too

Cheers,
Martin

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities...ronic-hardware
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      04-15-2011
On Apr 14, 1:12*pm, rickman <(E-Mail Removed)> wrote:
> I'm curious, how do you write, for example, a data path mux if you
> don't put it in a concurrent statement? *Do you lump it in with
> unrelated stuff? *I had a design for a mulaw encoder with two sources,
> the data from the CODEC and a tone generator as well as a mute
> function. *I added the data path mux (with mute function) using a
> combinatorial statement because to me it was not part of the mulaw
> logic so I didn't want to put it in the process for the mulaw logic.
> In fact, all of the data path to connect the mulaw logic with the
> CODEC and the IP interface was concurrent statements, some just simple
> assignments with no logic to connect wires... er, I mean signals. *Can
> you tell I've been working with Verilog lately?
>
> What would you have done differently?
>


It depends... How is the datapath (mux) controlled? Is it some
external control, or is it a mode within the encoder? If the encoder
has a requirement that under certain internal modes or conditions, it
needs to load data from a different source, then I generally code that
behavior into the encoder. On the other hand, if something external is
directly controlling the source of the data, then I might break that
functionality out into a separate mux. And if that mux was the only
thing related to that control, I might even make it a concurrent
statement.

The focus is more about the function than it is about the circuit that
will implement the function. Think of the function not as a mux but as
a choice of which data to load. Then asks questions like "who/what
determines (not implements) the choice?" The answer will often lead to
the appropriate coding. Also, a functional approach will more often
lead to closer coupling between that code and the requirements
documents for that code. Good requirements don't usually include
"shall have a mux to select data...," but more like "shall load
different data based on..."

Andy
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      04-15-2011
On Apr 15, 10:16*am, Andy <(E-Mail Removed)> wrote:
> On Apr 14, 1:12*pm, rickman <(E-Mail Removed)> wrote:
>
> > I'm curious, how do you write, for example, a data path mux if you
> > don't put it in a concurrent statement? *Do you lump it in with
> > unrelated stuff? *I had a design for a mulaw encoder with two sources,
> > the data from the CODEC and a tone generator as well as a mute
> > function. *I added the data path mux (with mute function) using a
> > combinatorial statement because to me it was not part of the mulaw
> > logic so I didn't want to put it in the process for the mulaw logic.
> > In fact, all of the data path to connect the mulaw logic with the
> > CODEC and the IP interface was concurrent statements, some just simple
> > assignments with no logic to connect wires... er, I mean signals. *Can
> > you tell I've been working with Verilog lately?

>
> > What would you have done differently?

>
> It depends... How is the datapath (mux) controlled? Is it some
> external control, or is it a mode within the encoder? If the encoder
> has a requirement that under certain internal modes or conditions, it
> needs to load data from a different source, then I generally code that
> behavior into the encoder. On the other hand, if something external is
> directly controlling the source of the data, then I might break that
> functionality out into a separate mux. And if that mux was the only
> thing related to that control, I might even make it a concurrent
> statement.


The mux is controlled by configuration register settings in a
different module, but also has a real time Left/Right control. Really
the mux is completely independent of the mulaw encode/decode. I wrote
that up as a independent, reusable module and instantiate it.


> The focus is more about the function than it is about the circuit that
> will implement the function. Think of the function not as a mux but as
> a choice of which data to load. Then asks questions like "who/what
> determines (not implements) the choice?" The answer will often lead to
> the appropriate coding. Also, a functional approach will more often
> lead to closer coupling between that code and the requirements
> documents for that code. Good requirements don't usually include
> "shall have a mux to select data...," but more like "shall load
> different data based on..."


Yes, exactly. Many of these independent functions that can be made
peripheral to a given function are coded as concurrent statements.
But there are times when I use concurrent signals to support easier
debugging. I don't recall the exact portion of the design, but I had
another function in this same design that was largely arithmetic. To
facilitate debugging I coded each step as concurrent so that each
intermediate value was a signal. Even if Active HDL would display
variables, they can't really be viewed properly if they are not
updated in a signal like manner. How do you view a sum of products
when it is updated in a loop as a variable? It all happens in one
instant in time when viewed in a waveform. Yes, you can use
breakpoints and such, but that is a separate issue.

Maybe there are things I can learn about this. I'll give code
debugging (vs waveform debugging) another try next time I code up some
HDL.

Rick
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      04-16-2011
On Apr 15, 7:25*pm, rickman <(E-Mail Removed)> wrote:
>
> Maybe there are things I can learn about this. *I'll give code
> debugging (vs waveform debugging) another try next time I code up some
> HDL.
>


Just curious here...
- Would you turn off your monitor and use a speech synthesizer to read
what is on your display to you?
- Do you close the source window (and not view the source code via an
editor) when you're debugging HDL designs today?

Presuming the answer to these questions is 'no', then what do you
think is to be gained by not using information that is currently
available to you? Do you think you would be more productive? If so,
can you explain why?

I'm making the assumption with these question that when you say "I'll
give code debugging (vs waveform debugging) another try" that this
would mean, among other things, not displaying waveforms, instead
using only the source code window and their tools. Which leads to the
questions above about why you think it would be better to not use
information that is available to solve the problem at hand.

But of course, based on your postings, you seem a bit more practical
than that and the reality is that you probably mean that you would try
supplementing using waveforms with source code tools such as
breakpoints and single stepping and such. On that premise...

- If a problem occurs, do you typically try to solve it by waiting for
it to happen again?
- Even if, in your experience, it has turned out that 'waiting for it
to happen again' will not usually mask the true problem and allows you
to fix the problem, do you think that is a good methodology?
- When you've solved problems in the past, are you always (or almost
always) able to solve it using no other information than what is
currently available right now? Looking only at present signal and
variable values at the time of the failure, with no history of what
led up to the event other that what you must infer by knowledge of the
design and must retain in your head (or perhaps scribbled down on
paper) since there is no history that can be displayed?

Presumably the answer to all of these questions is also 'no' which
suggests that making use of information that is readily available in
whatever form would be a 'good thing' that most anyone with experience
would make use of when solving the problem at hand...which then brings
us around to the wrap up...

Othen than if you've measured and found that logging signal activity
to the disk during sim to be too high of a cost, then there really is
no rationale to saying "code debugging vs waveform debugging". I'm
not trying to slam you or anyone here on methods, being proficient in
using source code tools is not a handicap. But those source code
tools can only be applied to events *after* the bad thing has
happened, they are of no help in diagnosing what has *already* ocurred
short of restarting the sim (i.e. turning back the clock) so you must
live with that limitation and work around it.

Source code tools do allow you to step through and watch things
unfold...but that would be using those tools for verification rather
than debug....personally, I prefer testbenches for that task.

Kevin Jennings
 
Reply With Quote
 
Chris Higgs
Guest
Posts: n/a
 
      04-19-2011
On Apr 15, 9:02*am, Martin Thompson <(E-Mail Removed)> wrote:
> rickman <(E-Mail Removed)> writes:
>
> <on waveforms of variables>
>
> > Please show me how to do this. *I have added variables to the waveform
> > window until I was blue in the face and their values never show up.
> > It makes some sense. *Variables are not defined outside of the
> > process, function or procedure and in many cases do not retain a value
> > between invocations. *So what would be displayed?

>
> I'm not an Aldec user, but on a brief perusal of the manual, I can't see how to
> do it either *How disappointing! *
>


IIRC, compiling with the debug flag (acom -dbg) will allow variables
to be traced in the same way as signals.

 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      04-19-2011
On Apr 19, 5:57*am, Chris Higgs <(E-Mail Removed)> wrote:
> On Apr 15, 9:02*am, Martin Thompson <(E-Mail Removed)> wrote:
>
> > rickman <(E-Mail Removed)> writes:

>
> > <on waveforms of variables>

>
> > > Please show me how to do this. *I have added variables to the waveform
> > > window until I was blue in the face and their values never show up.
> > > It makes some sense. *Variables are not defined outside of the
> > > process, function or procedure and in many cases do not retain a value
> > > between invocations. *So what would be displayed?

>
> > I'm not an Aldec user, but on a brief perusal of the manual, I can't see how to
> > do it either *How disappointing! *

>
> IIRC, compiling with the debug flag (acom -dbg) will allow variables
> to be traced in the same way as signals.


I use the GUI and in checking the preferences I see the compiler
option "Enable Debug" is checked. Is that what you mean? I'm still
not able to view variable as waveforms.

Rick
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Conditional statement with an assignment expression Asen Bozhilov Javascript 10 01-01-2010 06:26 PM
Assignment to output signal from internal signal not istantaneous dibacco73 VHDL 1 02-12-2009 11:28 PM
Signal Conditional Assignment ? guylewis VHDL 0 11-15-2008 09:50 PM
"Target of signal assignment is not a signal" Nicolas Moreau VHDL 9 07-25-2007 04:21 PM
Comparison of Bit Vectors in a Conditional Signal Assignment Statement Anand P Paralkar VHDL 2 08-04-2003 08:40 PM



Advertisments