Sometimes I Just Don't Get the Tools

[rickman]

I've learned to use Active HDL some time ago and never had too much
trouble with it. But now it is not letting me use the waveform viewer in
an effective way. I typically add all my signals once and then as I
work on the design and recompile it uses the same signal on each
iteration of the edit/compile/simulate cycle.

Now it is deleting all my signals from the waveform every time I
recompile. Seems it is related to using the "advanced waveform editor".
I found a setting that says, "preserve signals when simulation is
initialized". WTF? I guess if you are doing everything from a
simulation batch file you just add these signals too, but what is the
purpose of automatically deleting them by default or at all? I would
think a batch file could easily delete any existing signals before
creating its display.

Sometimes I just don't get the mindset of the tool developers.

Rick

 

[valtih1978]

Now it is deleting all my signals from the waveform every time I
recompile. Seems it is related to using the "advanced waveform editor".

This option has always infuriated me. Thanks for saying that the problem
is the tool, not me.

 

[Rob Gaddi]

On Sun, 27 Jan 2013 22:46:05 -0500
rickman <gnuarm@gmail.com> wrote:

I've learned to use Active HDL some time ago and never had too much
trouble with it. But now it is not letting me use the waveform viewer in
an effective way. I typically add all my signals once and then as I
work on the design and recompile it uses the same signal on each
iteration of the edit/compile/simulate cycle.

Now it is deleting all my signals from the waveform every time I
recompile. Seems it is related to using the "advanced waveform editor".
I found a setting that says, "preserve signals when simulation is
initialized". WTF? I guess if you are doing everything from a
simulation batch file you just add these signals too, but what is the
purpose of automatically deleting them by default or at all? I would
think a batch file could easily delete any existing signals before
creating its display.

Sometimes I just don't get the mindset of the tool developers.

Rick

In my college transistor circuits course, back shortly before the
discovery of electricity, we were targetting -100dB THD, and verifying
against a distortion analyzer. Look at it on a scope, sine wave. Look
at it on the analyzer, nuthin'. Back and forth, over and over, for
10 minutes we couldn't get any results out of the distortion analyzer.

Turned out to have a tiny button next to the BNC called "Input
Disconnect". Or as we called it, the Broken button. Since then I've
been amazed at how many designers of how many things have felt the need
to include a Broken button.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 1/28/2013 12:16 PM, Rob Gaddi wrote:

On Sun, 27 Jan 2013 22:46:05 -0500
rickman<gnuarm@gmail.com> wrote:

I've learned to use Active HDL some time ago and never had too much
trouble with it. But now it is not letting me use the waveform viewer in
an effective way. I typically add all my signals once and then as I
work on the design and recompile it uses the same signal on each
iteration of the edit/compile/simulate cycle.

Now it is deleting all my signals from the waveform every time I
recompile. Seems it is related to using the "advanced waveform editor".
I found a setting that says, "preserve signals when simulation is
initialized". WTF? I guess if you are doing everything from a
simulation batch file you just add these signals too, but what is the
purpose of automatically deleting them by default or at all? I would
think a batch file could easily delete any existing signals before
creating its display.

Sometimes I just don't get the mindset of the tool developers.

Rick

In my college transistor circuits course, back shortly before the
discovery of electricity, we were targetting -100dB THD, and verifying
against a distortion analyzer. Look at it on a scope, sine wave. Look
at it on the analyzer, nuthin'. Back and forth, over and over, for
10 minutes we couldn't get any results out of the distortion analyzer.

Turned out to have a tiny button next to the BNC called "Input
Disconnect". Or as we called it, the Broken button. Since then I've
been amazed at how many designers of how many things have felt the need
to include a Broken button.

They charge extra for buttons on test gear, don't they... no matter how
banal...

I'm still struggling with this issue, but in a more limited scope. When
I compile bad code in a way that causes the tool to get upset enough to
forget what the top level module is, on fixing the problem and starting
the simulation the waveform display any variables on display can't be
found in the code and are deleted... stupid tools!

I guess my real issue is that I had been using an older version of the
tool and for whatever reason I'm pretty sure I wasn't allowed to use the
"advanced" waveform viewer. Now that I am using the *advanced* viewer,
I am finding that it is only advanced in some ways that I don't actually
perceive. I guess it might be faster. The simulations seem to run a
lot faster than with the old tool, but I'm comparing apples and oranges
in terms of the project. This one is still pretty small and is only
running at a quarter MHz.

At least I am learning to not "upset* the tools. Otherwise they try to
get revenge... spiteful tools!

Rick

 

[glen herrmannsfeldt]

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:

(snip, someone wrote)

Turned out to have a tiny button next to the BNC called "Input
Disconnect". Or as we called it, the Broken button. Since then I've
been amazed at how many designers of how many things have felt the need
to include a Broken button.

They charge extra for buttons on test gear, don't they... no matter how
banal...

I suppose, but more buttons means that marketing can advertize
them as additional features.

Reminds me of the hardest to find button on most oscilloscopes,
the on/off button (or knob or ...).

-- glen

 

[valtih1978]

On 28.01.2013 23:51, rickman wrote:

I'm still struggling with this issue, but in a more limited scope. When
I compile bad code in a way that causes the tool to get upset enough to
forget what the top level module is, on fixing the problem and starting
the simulation the waveform display any variables on display can't be
found in the code and are deleted... stupid tools!

I remember it was loosing everything when (re)compiled a package.

 

[rickman]

On 1/29/2013 7:14 AM, valtih1978 wrote:

On 28.01.2013 23:51, rickman wrote:
I'm still struggling with this issue, but in a more limited scope. When
I compile bad code in a way that causes the tool to get upset enough to
forget what the top level module is, on fixing the problem and starting
the simulation the waveform display any variables on display can't be
found in the code and are deleted... stupid tools!

I remember it was loosing everything when (re)compiled a package.

When I used the Active simulator before it would not delete signals from
the waveform display no matter what. I would eventually notice that a
signal was not showing a waveform, most likely because I had deleted the
signal from the code, and remove it from the display.

I can't say much about variables in the waveform viewer. I don't recall
having any problems with them, but I've not typically used them a lot,
at least I didn't have a lot of need to show their waveforms. I seem to
be using them more now and for more "important" signals. My test
benches are full of them and now I'm having these problems.

I would consider using a macro to add everything to the waveform
display, I think there is even a menu command to save the current
waveform setup as a .do file. But only the variables seem to be lost
now and only after starting the simulation. The .do file would have to
start the simulation, stop it immediately, delete all signals from the
waveform display, add them all back and then restart the simulation...
really?

There has to be a better way.

Rick

 

[rickman]

On 1/29/2013 8:07 PM, rickman wrote:

On 1/29/2013 7:14 AM, valtih1978 wrote:
On 28.01.2013 23:51, rickman wrote:
I'm still struggling with this issue, but in a more limited scope. When
I compile bad code in a way that causes the tool to get upset enough to
forget what the top level module is, on fixing the problem and starting
the simulation the waveform display any variables on display can't be
found in the code and are deleted... stupid tools!

I remember it was loosing everything when (re)compiled a package.

When I used the Active simulator before it would not delete signals from
the waveform display no matter what. I would eventually notice that a
signal was not showing a waveform, most likely because I had deleted the
signal from the code, and remove it from the display.

I can't say much about variables in the waveform viewer. I don't recall
having any problems with them, but I've not typically used them a lot,
at least I didn't have a lot of need to show their waveforms. I seem to
be using them more now and for more "important" signals. My test benches
are full of them and now I'm having these problems.

I would consider using a macro to add everything to the waveform
display, I think there is even a menu command to save the current
waveform setup as a .do file. But only the variables seem to be lost now
and only after starting the simulation. The .do file would have to start
the simulation, stop it immediately, delete all signals from the
waveform display, add them all back and then restart the simulation...
really?

There has to be a better way.

Ok, some of the mystery has been lifted. I found a way to automatically
create a macro to add all your signals to the display, but it still
didn't solve the problem. But while I was looking at the text in the
macro file, I noticed that the path for the variables that were being
lost contained a line number reference! When a variable is declared in
a process, it is given a path name to that process. If you don't assign
a label, it just uses a line number. When that line number changes, the
path is no longer valid and the variables disappear!

I often start off without labels on most objects in my code and add them
later when I am tidying up. Now I see I need to add them up front.
Heck, VHDL lets you label every concurrent statement in the code since
they are all processes really. Not that there is a lot of need for
that. I didn't see much of this before because I wasn't using variables
so much. Actually, a number of variables just got the axe. Sometimes
they need to be accessed outside of the process and sometimes I prefer
to make them concurrent assignments when that works just as well.

--

Rick