Waveform type must be specified if any waveform parameters are given???

Hi, all,
I got a strange problem lately. While I was trying to do some
simulation on an CMOS opamp with Cadence Spectre, I kept getting such
kind of error message:

V0: Waveform type must be specified if any waveform parameters are
given.

Here, V0 is a voltage pulse source. Actually I had succefully run a
lot of simulations with Spectre for the op amp. But suddently, this
problem came up. The only fix I found right now is to manully put
"type=pusle" in the "input.scs" file. BTW, I can get correct result
with SepctreS without doing anything. If any of you could answer this,
I'd greatly appreciate it.

Jay

 

Try setting the following in your .cshrc/ .cdsinit

setenv CDS_Netlisting_Mode "Analog"

And recreate the netlist again...

Partha

 

Partha, thanks for the reply. But I think it's not due to this setup.
I started the Cadence with icms, which default sets the
CDS_Netlisting_Mode variable to "analog". Any more advice???
thanks again,
Jay

 

Partha, I'd like to try your suggestion. What is the correct syntax to
set CDS_Netlisting_Mode variable in .cdsinit? Looks like setenv
CDS_Netlisting_Mode "Analog" won't work. thanks much!
Jay

 

Try the following,

in your CIW,

getShellEnvVar("CDS_Netlisting_Mode")

set the variable by,
setShellEnvVar("CDS_Netlisting_Mode=Analog")

Or in .cshrc

setenv CDS_Netlisting_Mode "Analog"

 

Tried to set this variable in the .cdsinit but no luck. Guess the
syntax was wrong. Finally got it done by putting this variable in my
..cshrc file.
Thanks for the suggestion - I overlooked it at first, because
according to Cadence's manual, if you run icms, this variable is
supposed to set to Analog automatically.
Jay

 

Jay,

CDS_Netlisting_Mode _is_ set automatically when you run icms. Look at the
icms script - you'll see that it is set there.

If you are going to set it in the .cdsinit then you'll need to do:

setShellEnvVar("CDS_Netlisting_Mode=Analog")
cdsSetNetlistMode()

Partha correctly identified the first line - but the second line is also
necessary to tell it to change mode (you may be OK if it is set early
enough, perhaps, but in general the second line is needed to tell
DFII to re-check the environment variable).

Did setting CDS_Netlisting_Mode solve the original pulse problem? If not,
which component are you using - vpulse? vsource? (from analogLib?)

Regards,

Andrew.

 

Andrew,
I read several of your posts - very insightful. Thanks much for your
contribution to this group!!!

Yes, problem was solved after I put: setenv CDS_Netlisting_Mode
"Analog" into my .cshrc. At the beginning, I overlooked Partha's
suggestion, because I had this problem even if I started Analog
Enviroment from icms. As I remembered (and as you pointed out),
CDS_Netlisting_Mode is default to be "Analog" in icms. The reason I
came back to check this is, I found sometimes after I simulated the
ckt with Spectres, I can get the correct netlisting with Spectre.
While I start SpectreS (from icfb), it pops up a windown asking me to
set CDS_Netlisting_Mode to Analog. Then I realized that might be the
cause....

Yes, I'm using vpulse and vsin from analogLib. Do you suspect any
other cause of this???.

I'll try your suggestion - maybe it's better to set it in .cdsinit.
Thanks!

Respectfully,

Jay

 

Andrew,
Just tried your suggestion. Works fine. But somehow I have the feeling
that, Cadence will automatically take the last parameter value, is
this right?
Best regards,
Jay

p.s.: Another simple question, what is the sequence that Cadence (icfb
or icms) loads the start-up files? It that: 1. Site 2. Current working
directory 3. Home directory ?? Does the later loaded file overwrite
the same variables appeared in the previous initial file?

p.p.s: Besides .cdsenv, .cdsinit, are there any other "start-up"
files? Just curious, why is the CDS_Netlisting_Mode variable not set
within .cdsenv, which makes more sense to me.... Thanks again!

 

Jay,

Ah, can of worms time here. It depends...

The .cdsinit file (which is a SKILL syntax file) is loaded from:

<instdir>/tools/dfII/local
.. (working dir)
~ (home dir)

as soon as one is found, it stops searching. However, commonly people put
code in their .cdsinit file to look for further files - which may or may not be called
..cdsinit (sometimes .cdsuser, .cdslocal - it's entirely site dependent).

Any variables defined later will override those defined before - although sometimes
it depends on whether any functions were called in the .cdsinit file.

..cdsenv has a similar search order - although there is a UNIX environment
variable $CDS_LOAD_ENV which controls where it looks (see documentation
for more detail). This file is a file of Cadence "environment" variables.

In addition there are:

..simrc (simulation/netlisting startup - similar locations to .cdsinit)
cdsLibMgr.il (customisation of library manager - similar locations to .cdsinit, actual filename
may be changed in .cdsenv)
display.drf (display resources file) - found using Cadence Search File mechanism ("setup.loc"),
covered in Cadence Application Infrastructure guide
cds.lib found using Cadence Search File mechanism
cdsinfo.tag found using Cadence Search File mechanism (see CAI guide for more details)
..oceanrc (like .cdsinit, but for "ocean" executable).
hdl.var used by digital simulation tools
ams.env (like .cdsenv - used by AMS Designer)

there will be others - these are just those I could think of off the top of my head.

Just curious, why is the CDS_Netlisting_Mode variable not set

History. CDS_Netlisting_Mode pre-dates the .cdsenv file. Personally I wouldn't
set it in my .cdsinit file - I normally have it set in my login environment, but that's just
a matter of preference, I guess.

We do have some PCRs to load the above files in a uniform way - using the CSF
mechanism - but this has to be done with an eye on compatibility of course, because
we can't change the way that they are loaded when they have been the same
for the last 15 years... so there would almost certainly be a new environment variable
which controls this (I have some proposals in with R&D for one way to implement this).

Regards,

Andrew.

 

[...]

If some migration tools are made to help going from the old setup to the new, you should not find much resistance.

So, now, is the "setup.loc" found first in share/cdssetup or in share/local ? Hum ... wait a second, what was the use of setup.loc again ?

Jokes aside, it would be nice to have a diagram or other material (sonething like the super "skill cellview information model") that improves the overview of the whole startup mechanism. If the mechanism is scrapped, I will not regret a thing. As long as the migration tools are good and the new mechanism readable/sensible.
An review of the netlisting mechanisms could use such documents too.