cadence simulation dumps

J

Jason Zheng

Guest
Does anyone know if any 3rd-party waveform viewer can view the
simulation dumps generated by cadence ncverilog (via $shm_open, not
$dumpfile)? What's the standard or format used by shm_open?

thanks
 
Hi,
I don't think you'll find one - all these compiled waveform formats
are kept proprietary by individual vendors (CDN - SHM, SNPS - VPD, MTI
-WLF etc.). However one option can be to open their SHM file in
simvision and convert to VCD. But - why do you want to do that? I
thought Simvision is a nice viewer :)
Regards,
Ajeetha
http://www.noveldv.com
 
Jason Zheng wrote:

Our design simulations are relatively large, so VCD dumps can be
multiple hundred megabytes. The free waveform viewer gtkwave, which I
tried, cannot handle huge VCD dumps very well. In fact, it crashes
everytime I tried to add any trace to it.
Click to expand...
Try converting the VCD dump to lxt using tools that come with gtkwave,
and then use gtkwave to display the lxt file instead.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
Stephen Williams wrote:
Jason Zheng wrote:

Our design simulations are relatively large, so VCD dumps can be
multiple hundred megabytes. The free waveform viewer gtkwave, which I
tried, cannot handle huge VCD dumps very well. In fact, it crashes
everytime I tried to add any trace to it.


Try converting the VCD dump to lxt using tools that come with gtkwave,
and then use gtkwave to display the lxt file instead.

Thanks for that suggestion. I gave it a try and found out either vcd2lxt
Click to expand...
or gtkwave is buggy, apparently most of my signals got changed to X's.
It does have a great compression ratio, though. Hopefully this will be
fixed in the future.

-jz
 
Jason Zheng wrote:
Stephen Williams wrote:

Jason Zheng wrote:

Our design simulations are relatively large, so VCD dumps can be
multiple hundred megabytes. The free waveform viewer gtkwave, which I
tried, cannot handle huge VCD dumps very well. In fact, it crashes
everytime I tried to add any trace to it.



Try converting the VCD dump to lxt using tools that come with gtkwave,
and then use gtkwave to display the lxt file instead.

Thanks for that suggestion. I gave it a try and found out either vcd2lxt
or gtkwave is buggy, apparently most of my signals got changed to X's.
It does have a great compression ratio, though. Hopefully this will be
fixed in the future.
Click to expand...
Safe bet that Tony would like to hear about that. What version of
gtkwave are you using?

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
I seem to recall hearing something about a Post-Processing Environment
mode in Simvision, which would allow looking at waveforms without using
up a simulation license. It might have required some other kind of
license,
but that might be no worse than getting a third-party tool.
 
sharp@cadence.com wrote:
I seem to recall hearing something about a Post-Processing Environment
mode in Simvision, which would allow looking at waveforms without using
up a simulation license. It might have required some other kind of
license,
but that might be no worse than getting a third-party tool.

Sharp,
Click to expand...

Would you share more information on the post-processing environment? I
have never heard of that sort of license from cadence.

thanks,

jz
 
But isn't it true that generating VCD takes much longer than say SHM,
as it is a binary format and file size being small, file-IO is expected
to be faster? That's the reason why I recommended using SHM2VCD
conversion.

Anyway I learnt quite some useful stuff via this thread on this
LXT/GTKWave features - thanks!

Ajeetha
 
Hi,
Perhaps Steve is referring to ncsim -ppe option. I thought that holds
up a license too - not sure which one though.

Ajeetha
 
Jason Zheng wrote:
The problem I am facing right now, is that we don't have enough
ncverilog license for everyone in my team to use Simvision at the
same
time, and cadence does not offer seperate licensing for simvision
along.
Hence if we need more simvision, we'd have to pay for the entire
ncverilog license (for each additional simvision). That is the
movitation behind my pursuit for some 3rd-party waveform viewer.
Click to expand...
I'm surprised. A little less than 2 years ago we asked Cadence about
additional Simvision licenses and they gave us a price. We didn't end
up getting them though. But our rep has always been good about letting
us buy extra short-term licenses for whatever.

-cb
 
I went and asked a Simvision person. Apparently there is
a license for Simvision. If you are running a simulation with
Simvision, it uses both a simulation license and a Simvision
license. However, you can run Simvision in this post-
processing environment mode to look at waveforms, and
then it only uses a Simvision license.

You can get additional Simvision licenses at lower cost
than a full simulation license. Apparently a single user
can also use a single Simvision license to open multiple
Simvision windows and look at the results of multiple
simulations at the same time.
This sounds like it may be what you are looking for.
 
It certainly sounds reasonable that generating a smaller
binary file format should be faster than generating VCD.
I have heard that argument made before, and it always
sounds reasonable. However, I know that in the past,
actual measurements have shown that it is faster to dump
VCD than some binary formats. I don't know what the
reasons were, and perhaps things have changed.
 
Ajeetha wrote:
But isn't it true that generating VCD takes much longer than say SHM,
as it is a binary format and file size being small, file-IO is expected
to be faster? That's the reason why I recommended using SHM2VCD
conversion.

Anyway I learnt quite some useful stuff via this thread on this
LXT/GTKWave features - thanks!

Ajeetha

Ajeetha,
Click to expand...

Do you know where to get shm2vcd? Is it supposed to come with ncverilog?

-jz
 
I am not sure if they have such an executable sent out with NCSIM, but
you can do that via Simvision GUI. IIRC, You can actually do lot more
there - choose a time range, select few signals etc. I don't have NC
license currently to check.

Ajeetha
http://www.noveldv.com
 
Ajeetha wrote:
Hi,
I don't think you'll find one - all these compiled waveform formats
are kept proprietary by individual vendors (CDN - SHM, SNPS - VPD, MTI
-WLF etc.). However one option can be to open their SHM file in
simvision and convert to VCD. But - why do you want to do that? I
thought Simvision is a nice viewer :)
Regards,
Ajeetha
http://www.noveldv.com

Thanks for the suggestion. You actually don't have to convert it to VCD,
Click to expand...
though. All the simulators can take the standard $dumpfile and $dumpvars
tasks to generate VCD directly.

The problem I am facing right now, is that we don't have enough
ncverilog license for everyone in my team to use Simvision at the same
time, and cadence does not offer seperate licensing for simvision along.
Hence if we need more simvision, we'd have to pay for the entire
ncverilog license (for each additional simvision). That is the
movitation behind my pursuit for some 3rd-party waveform viewer.

Our design simulations are relatively large, so VCD dumps can be
multiple hundred megabytes. The free waveform viewer gtkwave, which I
tried, cannot handle huge VCD dumps very well. In fact, it crashes
everytime I tried to add any trace to it.

-jz
 
Stephen Williams wrote:
Jason Zheng wrote:

Thanks for that suggestion. I gave it a try and found out either
vcd2lxt
or gtkwave is buggy, apparently most of my signals got changed to
X's.
It does have a great compression ratio, though. Hopefully this will
be
fixed in the future.

Safe bet that Tony would like to hear about that. What version of
gtkwave are you using?
Click to expand...
Yeah, I'm curious as I've never seen X corruption like that. Anyway,
considering the number of people I've seen have problems with enormous
VCD files, I'm half-tempted to have the viewer prompt the user if it's
OK to convert the file over to a database format instead like
signalscan does.

Note that if you're using gtkwave-2.x I have no idea if lxt works for
it as there were problems with lxt in that branch when the internal
value change representation was restructured by APT--don't know if the
lxt bugs there still exist as I only maintain/bugfix the 1.3 series.

wget ftp://metalab.unc.edu/pub/linux/apps/circuits/gtkwave-1.3.53.tgz

I regularly generate lxt traces with about 300k signals so if you have
a real problem Jason, I'm curious.

-Tony
 
bybell@rocketmail.com wrote:
Stephen Williams wrote:


Safe bet that Tony would like to hear about that. What version of
gtkwave are you using?


Yeah, I'm curious as I've never seen X corruption like that. Anyway,
considering the number of people I've seen have problems with enormous
VCD files, I'm half-tempted to have the viewer prompt the user if it's
OK to convert the file over to a database format instead like
signalscan does.

Note that if you're using gtkwave-2.x I have no idea if lxt works for
it as there were problems with lxt in that branch when the internal
value change representation was restructured by APT--don't know if the
lxt bugs there still exist as I only maintain/bugfix the 1.3 series.

wget ftp://metalab.unc.edu/pub/linux/apps/circuits/gtkwave-1.3.53.tgz

I regularly generate lxt traces with about 300k signals so if you have
a real problem Jason, I'm curious.

-Tony
Click to expand...
Yes, I'm running gtkwave 2.0.0pre3-20030319. I noticed the warning about
lxt format on APT's website. However, their warning came after pre4
release, didn't it?
I'll give the version 1.3 a try as suggested by Tony.

Thanks to both of you.

-jz
 
Jason Zheng wrote:
bybell@rocketmail.com wrote:

Yeah, I'm curious as I've never seen X corruption like that. Anyway,
considering the number of people I've seen have problems with enormous
VCD files, I'm half-tempted to have the viewer prompt the user if it's
OK to convert the file over to a database format instead like
signalscan does.

Note that if you're using gtkwave-2.x I have no idea if lxt works for
it as there were problems with lxt in that branch when the internal
value change representation was restructured by APT--don't know if the
lxt bugs there still exist as I only maintain/bugfix the 1.3 series.

wget ftp://metalab.unc.edu/pub/linux/apps/circuits/gtkwave-1.3.53.tgz

I regularly generate lxt traces with about 300k signals so if you have
a real problem Jason, I'm curious.

-Tony


Yes, I'm running gtkwave 2.0.0pre3-20030319. I noticed the warning about
lxt format on APT's website. However, their warning came after pre4
release, didn't it?
I'll give the version 1.3 a try as suggested by Tony.

Thanks to both of you.

-jz
I just tried version 1.3.53, and it works like a charm with all the lxt
Click to expand...
conversion and large vcd dumps. Thanks for all the help!

-jz

p.s. Does gtkwave have rising/falling edge finders like
signalscan/simvision? I looked and couldn't find any.
 
Jason Zheng wrote:

I just tried version 1.3.53, and it works like a charm with all the
lxt
conversion and large vcd dumps. Thanks for all the help!
Click to expand...
No problem. Glad to be of help.


-jz

p.s. Does gtkwave have rising/falling edge finders like
signalscan/simvision? I looked and couldn't find any.
Click to expand...
Yes. Highlight the signal in question then click on Search->Pattern
Search in the menu.

Then a popup will appear. Click the button on the left to, say,
"rising edge" then press "Mark" to lay down alternate gridlines or
"Fwd" or "Bkwd" to move the marker to the next edge/string/whatever.

Note that you can do this with multiple signals at once like an address
bus equals a value and valid is high on a rising clock edge, etc. Also
note that for strings you will have to press enter on the value. The
finder also works with timeshifted signals which is how you can do
searches that don't happen in zero time. (e.g., if you're watching
something move through pipe stages)

If you haven't already, copy .gtkwaverc to your home directory and the
viewer will look nicer than the black and white screens I've seen on
some people's screen grabs.

BTW, something not really documented that works nicely is to zoom full
then click the RMB, drag it left or right, and release. The area
between the two cursors defines the new left and right margins. A
couple of iterations of this is a quick way to zero in to a specific
part of a trace.

Regards,
-Tony
 
bybell@rocketmail.com wrote:
Jason Zheng wrote:
p.s. Does gtkwave have rising/falling edge finders like
signalscan/simvision? I looked and couldn't find any.


Yes. Highlight the signal in question then click on Search->Pattern
Search in the menu.

Then a popup will appear. Click the button on the left to, say,
"rising edge" then press "Mark" to lay down alternate gridlines or
"Fwd" or "Bkwd" to move the marker to the next edge/string/whatever.

Note that you can do this with multiple signals at once like an address
bus equals a value and valid is high on a rising clock edge, etc. Also
note that for strings you will have to press enter on the value. The
finder also works with timeshifted signals which is how you can do
searches that don't happen in zero time. (e.g., if you're watching
something move through pipe stages)
Click to expand...
This is great! Much better than the single-signal edge finder on other
software.

If you haven't already, copy .gtkwaverc to your home directory and the
viewer will look nicer than the black and white screens I've seen on
some people's screen grabs.
Click to expand...
Under the root directory of the tarball. Maybe in the future put in /etc
by default?

BTW, something not really documented that works nicely is to zoom full
then click the RMB, drag it left or right, and release. The area
between the two cursors defines the new left and right margins. A
couple of iterations of this is a quick way to zero in to a specific
part of a trace.
Click to expand...
Neat trick! Thanks again!

-jz
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top