cadence simulation dumps
Jason Zheng
simulation dumps generated by cadence ncverilog (via $shm_open, not
$dumpfile)? What's the standard or format used by shm_open?
thanks
Ajeetha
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
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
> 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.
--
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."
Jason Zheng
> 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.
>
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
Stephen Williams
Safe bet that Tony would like to hear about that. What version of
gtkwave are you using?
byb...@rocketmail.com
> 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?
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
sh...@cadence.com
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.
Jason Zheng
> 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
>
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
> byb...@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
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
Would you share more information on the post-processing environment? I
have never heard of that sort of license from cadence.
thanks,
jz
byb...@rocketmail.com
> 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!
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.
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
Ajeetha
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
Perhaps Steve is referring to ncsim -ppe option. I thought that holds
up a license too - not sure which one though.
Ajeetha
Chris Briggs
> 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.
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
sh...@cadence.com
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.
sh...@cadence.com
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.
Jason Zheng
> 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)
>
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.
>
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.
>
Neat trick! Thanks again!
-jz
Jason Zheng
Do you know where to get shm2vcd? Is it supposed to come with ncverilog?
-jz
byb...@rocketmail.com
It depends on how computationally expensive it is to write out the
binary file. If there's little more to the file format than dumping
out values similar to VCD (a version of the old MTI .wav file format
comes to mind), the binary will probably be faster. Once you throw in
stuff like clock/counter detection, signal value reordering and
indexing, etc in order to increase the compression ratio, you'll take a
speed hit. Likewise goes with any compression layers (e.g., libz) on
top of the data: you don't achieve a 50-100:1 compression ratio on VCD
without doing a bit of work.
There's also the factor that since VCD is built into the simulator/PLI
and isn't some standalone generic library code, it doesn't really need
to burn memory on storing signal names, their sizes, previous value,
etc so when it dumps there's less page/TLB thrashing on large models.
If it's faster to split a simrun that performs a binary dump into
simulating with writing VCD then converting it offline with a separate
utility, memory access issues are probably the case.
-t
Ajeetha
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
nos...@veritools.com
You can use the Undertow waveform viewer to view data from the
ncverilog simulator. The $shm_open uses a format that is proprietary to
Cadence. With Undertow you can use a a PLI or VPI routine that is
included in the Undertow distribution. This will compress your output
by up to 1300 times over a VCD file, particularly when the VCD file
sizes are getting very large. Typical results with the Veritools'
PLI/VPI are as follows;
15 million gate/RTL gate equivalent design:
On a 650 MHZ Solaris system
VCD file, 39 minutes with file size of 3.1 gigabytes
PLI/VPLI output file 5.1 minutes, file size of 2.5 megabytes
On a 3.2 GHZ Linux System;
PLI/VPLI output file 1 minute, 40 seconds, file size 2.5 megabytes
The waveform file from the Veritools' PLI/VPI has been designed to load
in and display signals in Undertow almost instantly regardless of how
big this file is.
You can down load the software at no cost from www.veritools.com. Send
a request as directed to get username and passwd for downloading the
software and for getting a no cost license.
sakshe...@gmail.com
Does anyone can tell me how we can convert verilog code to VCD in Ncsim cadence.
Thanks