Sometimes I Just Don't Get the Tools

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

I believe the "preserve" option was not even available after they first int roduced the Advanced waveform viewer. I am going to guess that the reason t hat signals were not preserved was related to a software implementation dif ficulty, and had little to do with the "user experience"...

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

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

(snip, someone wrote)

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

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

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.