Stats

  • Locked Locked
  • Replies 2
  • Subscribers 63
  • Views 14214
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

schematic that uses spectre M_TWO_PI unhappy in ams

drdanmc

I have a cellview whose schematic is a L-C ladder filter that is parameterized.  I pass down the bandwidth via pPar() and the L-C values are set to expressions like:

2/(M_TWO_PI*pPar("BW"))  or  1.80194/(M_TWO_PI*pPar("BW")) 

M_TWO_PI is a builtin constant in spectre.

Now when I happen to use this cell in an AMS simulation, it ends up getting netlisted as verilog with a netlist like:

module my_lpf (OUT, IN);

parameter BW=1M;

output OUT;

input IN;

// buffer removed

capacitor #(.c(1.80194/(M_TWO_PI*BW))) C4 (net9, cds_globals.\gnd! );
inductor #(.l(2/(M_TWO_PI*BW))) L3 (net8, net9);

// other L and C removed


endmodule

The problem now is that "constants.vams" would be able to give me `M_TWO_PI (with the leading backtick) but plain old M_TWO_PI is not defined.  Is there some setting somewhere that would tell the netlister to convert spectre built in constants over to macros?  Even if the macro didn't exist in constants.vams, I do see where I can specify other includes.

Currently I'm using the OSS netlister with irun as the UNL gave some issues with missing pc.db in a cell library (working on that in parallel).

Thanks

-Dan

Parents

  • I noted a rather strange thing.  If I switch to UNL (in the same session) and try to netlist, then M_TWO_PI is now identified as an undefined design variable and I can set it to "`M_TWO_PI" (note the back tick) and then switch back to the OSS netlister (in the same session) and when I netlist, I see the following changed instantiation of those L-C elements:

    capacitor #(.c(1.80194/(cds_globals.M_TWO_PI*BW))) C4 (net9, cds_globals.\gnd! );

    note that instead of M_TWO_PI, I have cds_globals.M_TWO_PI which then pulls from the design variables.  However, if I save my ADE-L state exit, and start a new session, load that state, and go then I'm back to the initial problem.

Reply

  • I noted a rather strange thing.  If I switch to UNL (in the same session) and try to netlist, then M_TWO_PI is now identified as an undefined design variable and I can set it to "`M_TWO_PI" (note the back tick) and then switch back to the OSS netlister (in the same session) and when I netlist, I see the following changed instantiation of those L-C elements:

    capacitor #(.c(1.80194/(cds_globals.M_TWO_PI*BW))) C4 (net9, cds_globals.\gnd! );

    note that instead of M_TWO_PI, I have cds_globals.M_TWO_PI which then pulls from the design variables.  However, if I save my ADE-L state exit, and start a new session, load that state, and go then I'm back to the initial problem.

Children
  • in reply to drdanmc

    Hi Dan,

    I checked if this is a known issue (using spectre constants in AMS), but couldn't find a direct equivalent. It wouldn't surprise me that this hadn't come up before - M_TWO_PI is simulator specific and so I wouldn't necessary expect it to translate. Similarly I would also expect M_TWO_PI to be recognised as a design variable (it probably ought to translate it as a reserved word) in spectre - so the handling is not really correct there.

    So I looked in the AEL manual, and there’s a set of AEL constants including “twoPi”. If I use twoPi in an expression on a component, and then use Full evaluation when using View->Annotations (annotation setup, enable the Display Type column and set to “Full”, it then understands it. However, for both spectre and AMS (UNL) it creates a design variable rather than dealing with it in the netlister.

    Think this needs an enhancement CCR to handle AEL constants - then they can be translated to something appropriate in each netlister (or to a netlister-generated constant otherwise). You should contact customer support.

    Regards,

    Andrew.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.