spf in cadence

If using a recent version, rather than doing this - make sure you have a schematic for the block in question (even if it only has pins and  no content), and then use Setup->Simulation Files->Parasitic Files (DSPF). WHat it can then do is use the port order from the schematic netlist and include the contents from the DSPF (matching the pin names in the DSPF to the pin names in the schematic subckt).

You should be able to attach files using the "Insert Media" icon in the Rich Text editor. That said, it's a bit fussy - I think it tends to work better with Internet Explorer than other browsers.

Regards,

Andrew.

Thank you,

I am using Cadence ADV12.1,

I created a new cell, inv_pex, with empty schematic , and made the symbol pins exactly like the spf file ports, and then I included the inv_pex.spf file in ADE through setup --> simulation files --> Definition files ( there is no option for  Parasitic Files DSPF), but it gives error in the simulation (inv3_pex is being redefined), I checked pin definitions in the termorder ( in CDF edit) is the same as the spf ports ( as I created the cell with the same pins as the spf file), 

Did you mean another procedure  to use the port order from the schematic netlist and include the contents from the DSPF ?

I am attaching the files here :

There is a key difference between the DSPF entry line in simulation files (you probably need a newer hotfix of ICADV12.1 to see this) than (say) definition files. Definition files just uses "include", whereas the DSPF entry uses "dspf_include" in spectre, which has some additional capability - particularly to avoid the double definition problem, and to allow the port mapping to be done.

If you don't have that form field, you can create an include file called (say) dspfinc.scs (and include this as a definition file or model file) and then in that file put:

dspf_include "yourfile.spf" port_order=sch

If you search in cdnshelp from MMSIM for "dspf_include" you'll find some details on this (assuming you're using a recent enough MMSIM version, although it's been in the simulator longer than in the environment).

The idea with the above is that it uses the port ordering from the netlist of the schematic, but the body comes from the DSPF.

I wasn't able to look at your files due to a problem with the forum software, but I've got my IT colleagues looking into that.

Regards,

Andrew.

The command <dspf_include "yourfile.spf" port_order=sch> works fine,

Now the spf file works and pex simulation is ok,

Thank you very much Andrew, you are quite helpful,
Hussein

Hi Andrew, an issue I am dealing with right now with dspf_include concerns the bus delimiter characters.

The SPF file produced by STAR uses the format <X>.  The Spectre netlist produced by the netlister in ADE-L converts <X> in the schematic to _X.

If I use dspf_include to pull in the STAR netlist, each bus strand causes an error because (I believe) it can't find <X> in the schematic netlist instantiation. 

Unfortunately I believe the bus_delimiter option in dspf_include is set up to handle the converse situation only.

At the moment our solution is to use a sed script to post-process the STAR netlist to change <X> to _X, but that's prone to oversight and error. 

Another limiting factor is that the LVS tool uses a CDL netlister and those pins also have the <X> format, and, as a result, so do the individual pins in the layout.  So I can't do much to change the schematic.

Can you suggest other solutions?

Tony

Tony,

It's not entirely clear to me what your problem is. I'm guessing that you have a mismatch between the bus delimiter used in the pins of the subckt definition netlisted by ADE and the bus delimiter in the .SUBCKT in the DSPF? An example of each would help.

I think you might need to specify bus_delim="_ <>" (a space between the two) - this allows you to specify the bus delimiter on the spectre side versus on the DSPF side.

I'd say taking this up with customer support would be best, as really we need to see your data. It's possible that something might need fixing too.

Regards,

Andrew.

Hi Andrew, thanks for your reply.

Good suggestion to take this up with support, I will do that.  :-)

Also an interesting suggestion to code bus_delim="_ <>" ... I'll give it a try.  Did not see that in the documentation ...

Tony

Andrew, thanks again.

I have only run a single simulation as a test case.  Indications from this are that your suggested syntax for dspf_include worked.

The interim conclusion is that the first argument to bus_delim is the schematic bus delimiter while the second is the SPF bus delimiter.

Or perhaps dspf_include looks at the first argument, applies it to the schematic, ignores the second argument and picks up the SPF bus delimiter from the SPF itself?  The latter is implied in the documentation, but the ability to use an arbitrary character for the first argument is not. 

We will continue to evaluate this as the functionality would be quite useful to us.  I will take up the matter with our formal support channels.

Tony

Tony,

The way this works is that the first part of bus_delim is the "schematic" delimiter (i.e. what's in the spectre netlist), and the other part is the DSPF delimiter.

This needs to be better documented though - so please take that up through your normal support channel.

Glad it worked though! It was a bit of a wild guess ;-)

Regards,

Andrew.