Using the Waveform Access Library (WAL)

Hi all,

I need to use the WAL to extract data from a simulation run.

However, I fail to even get started with the "hello world" example from
chapter 11 of the OSS reference: I installed all of IC5141 but still
haven't got a
voCompiler.h or virtuos.a (BTW that name is spelled both virtous.a and
virtuos.a in the OSS ref).
I managed to get away without voCompiler.h, but now linking fails with
an
"undefined reference to `voCopyString'".

Do I need to install any other component for these files?

Nadine

 

Hm... looks like there are packaging and/or documentation bugs here.

voCompiler.h is a trivial header which just defines CDS_BEGIN_FUNCS and
CDS_END_FUNCS as (I'm doing this from memory):

#ifdef __cplusplus
#define CDS_BEGIN_FUNCS extern "C" {
#define CDS_END_FUNCS }
#else
#define CDS_BEGIN_FUNCS
#define CDS_END_FUNCS
#endif


I don't see a virtuos.a in the IC5.1.41 install, either; however, you
should be able to use libvirtuos_sh.so in tools/lib. When linking your
executable, add:
-L$CDS_INST_DIR/tools/lib -lvirtuos_sh
to the end and it should (hopefully) work.

You will need to have $CDS_INST_DIR/tools/lib in your LD_LIBRARY_PATH
(on Linux or Sun) or SHLIB_PATH (on HP-UX or AIX) when running the
executable. (You can also add it to the rpath when linking, but there
are caveats...)

(The name should be virtuos, which stands for VirtualOS.)

 

What is WAL? Which tools uses it? Does Cadence recommend using it?

 

It's an API for accessing waveforms in WSF format - look in the OSS reference
manual for more details.

I'd say WSF is pretty much obsolete, and would not recommend anyone starting
any new developments based on it. Note, this is a personal opinion - I've not
checked internally for an official viewpoint on this.

Regards,

Andrew.

 

Hi David,

[...]

Thank you for this information. I was able to compile the example this
way.
I had to link the wal.a into a dynamic library and use dlopen to access
it
on a non-RH7.2 box due to references to errno and __ctype_b, but that
was
expected and not a big deal. It works just fine now.

Thanks
Nadine

 

That's a pity to hear. To my knowledge (from searching the web) it is
only
WSF and the nutmeg format that are both accessible from C and supported
by spectre. I really would hate having to go through Ocean (including
all the overhead of spawning the process, feeding it the right
commands, converting the
data to ASCII and back, propably leading to a loss of precision) just
to read the simulation data.

A few years ago you mentioned that a package "SRR" would one day be
available to read PSF:
http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&selm=
Any news on this? (BTW: Where can I search for a PCR number on the new
sourcelink home?)

Nadine

 

I'm not really sure how universally supported WSF is with spectre. For a
start, it's not been the primary output format for many, many years, and so I
personally wouldn't want to trust my life on it! Again, this is a personal
view (as is everything I post here).

I mentioned the PCR number in that posting. The documentation and libraries
will be available to customers as a "special" product I believe (I don't know
the details). I think you need to speak to your account manager, and they'll
need to contact spectre product engineering for more details.

Regards,

Andrew.

 

Nadine> Date: 16 May 2005 02:52:19 -0700

[...]
Nadine> Thank you for this information. I was able to compile the
Nadine> example this way. I had to link the wal.a into a dynamic
Nadine> library and use dlopen to access it on a non-RH7.2 box due
Nadine> to references to errno and __ctype_b, but that was
Nadine> expected and not a big deal. It works just fine now.

Nadine

Watch out for the AC data. I was trying to use WAL a year ago, and
could not get it to read AC (complex) data due to a bug in WAL. I
talked to the Cadence AE. No use.

Then recently I found that Aptivia has some libraries for reading PSF
files using MATLAB. There might be a library to read PSF in C embedded
in there.

Satya

 

Nah... beyond 16 decimal places, printf() is just making stuff up.

An IEEE 754 double precision floating-point number (which is what SKILL
uses) has 52 mantissa (fraction) bits plus one implicit character
(integer) bit. log10(2^53) is roughly 15.95, which rounds up to 16.

The reason why printf() thinks it can go beyond 16 decimal places is
because it keeps multiplying an imprecise floating-point fraction by 10.

I have attached a C program which illustrates this. It prints out the
floating-point number 1.0000000000000002 (== 1 + 2*10^-16), the next
representable floating-point number after 1.0, in both hexadecimal
(base-16) form along with the standard printf %lf, %.16lf, and %.22lf forms.

It also implements its own version of printf's %lf formatter so you can
play with what's going on under the hood.

The output you will see is:

hexform: +0x1.0000000000001e+000
%lf form: 1.000000
%.16lf form: 1.0000000000000002
%.22lf form: 1.0000000000000002220446
print_double: 1.0000000000000002220446

You can see that it's making up numbers at the end.

What's going on? To your machine, 1 + 2*10^-16 and 1 + 2^-52 have the
same representation. Of course, it doesn't maintain a decimal
representation under the hood, so 1 + 2^-52 is used. 2^-52 is roughly
2.2204460492503131*10^-16... look familiar?

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820

#include <assert.h>
#include <stdio.h>
#include <inttypes.h>

#define GET_SIGN(x) ((uint64_t)(((x) & 0x8000000000000000ULL) != 0))
#define GET_EXPONENT(x) ((uint64_t)(((x) & 0x7ff0000000000000ULL) >> 52))
#define GET_MANTISSA(x) ((uint64_t)((x) & 0x000fffffffffffffULL))

void print_double(double d, int nplaces)
{
int i, integral_portion;

integral_portion = (int) d;
printf("%d.", integral_portion);
d -= (double) integral_portion;

for (i = 0; i < nplaces; ++i) {
d *= 10.0;
integral_portion = (int) d;
printf("%d", integral_portion);
d -= (double) integral_portion;
}

printf("\n");
return;
}

int main()
{
double d;
uint64_t *b = (uint64_t *) &d;

d = 1.0000000000000002;
printf("hexform: %s0x1.%013llxe+%03llx\n"
"%%lf form: %lf\n"
"%%.16lf form: %.16lf\n"
"%%.22lf form: %.22lf\n"
"print_double: ",
(GET_SIGN(*b) ? "-" : "+"),
GET_MANTISSA(*b),
GET_EXPONENT(*b) - 1023,
d,
d,
d);

print_double(d, 22);

return 0;
}

 

Also transcendental functions accuracy after 35 bits is also somewhat
open to debate. (re http://www.fourmilab.ch/babbage/library.html )

Anyone who needs >10 digits of accurracy without understanding precision
always has me a bit worried!

-- Gerry

 

Thanks for the clear answer, Dave.