Spectre simulation error

Hi all,

Sometimes I have the following error when trying to create netlist and
start simulation in Affirma Analog Circuit Enviroment:

*Error* fprintf/sprintf: format spec. incompatible with data - nil

After that netlist is not created, Spectre is not starting etc.. I am
using Cadence 4.4.6. The problem is that this error appears more or
less randomly - when you start a new design it can appear or not, but
once Spectre started wveruthing is ok - I can modify things and
simulate further on.. Similarly - once it has appeared, I can't do
anything

Has anyone met with similar things???

 

yes it happens sometimes.
in my case, using the skill debugger, i could find out that the error
was triggered in a skill find of my design kit. was no big deal.

stéphane

 

yes it happens sometimes.

Thank for your reply. I tried to use skill debugger, but since it was
my first time I ever find out about SKILL, I could not found the
error...

I would really apprecialte if you could give me some more information
where (how) you've found this error and how you've fixed it.

Alex

 

I've had this same problem, but mostly in SKILL code that I wrote myself so
it was easier to fix. I sometimes get annoyed at how the printf/sprintf
works in SKILL. If you try to print some empty property or list ('nil'),
then the entire procedure terminates, even if the printf was only for
debugging purposes. I would rather have the printf print 'nil' instead of
failing. The only way I've fixed these problems is to look through all of
the fprintf's, sprintf's, and printf's in the SKILL code and try to find the
one that is borken by commenting them out one at a time until it works.

Frank

 

Hmm. If you want it to handle nil, use %L not %s - that's the best approach for
debugging purposes.

It's reasonable that SKILL should do some type checking - for example, what
would you expect it to do when trying to print an integer, when passed nil, or a
string?

As for locating these problems, in general the SKILL debugger is quite good,
because it will trap the error and then allow you to use where to find out where
you are - and hence locate them more readily. Certainly more efficient than
commenting them out one at a time...

Andrew.

 

Agreed, there is not enough type-checking in SKILL. Not too much.

If someone has utilities that modify SKILL code by finding out
variable types and then prepend them with the proper prefix (s_ t_ ...),
and add type templates to procedure definitions , that would be very
welcome.

 

Have you been defining any graphical stimuli in your design? I know that
Cadence give you this error message if you replace a schematic pin that
has an attached graphical stimuli with a real source. Solution is to go
into the graphical stimuli editor and check what signals have schematic
pins and who has not.

If this doesn't help, I have no further clue.

 

Unfortunately that error message can be from almost anywhere.

It is caused by some code doing something like this:

sprintf(nil "testing 123 %s\n" myvar)

where myvar was nil instead of being the expected string. Since
printf/fprintf/sprintf is rather widely used in both Cadence and customer code,
and there are so many possibilities for this, it's hard to track down.
In an ideal world, error checking in the code would spot the problem
before it resulted in a low level error such as this, and report it
gracefully. However, in the real world, code does not always do all the error
checking that it should...

One approach to track it down is to do:

sstatus(stacktrace 20)

which will force an automatic stacktrace whenever such an error occurs - this
might reveal at which point it is failing, althought it may not help you as an
end user without help from Cadence (it might though...)

Andrew.