Running OCEAN XL sweep with a netlist instead of a lib/cel/view

Dear AncisMichele,

AncisMichele said:

I would like to run slight variations of a design, which so far is organized within the Assembler framework.

These variations are best handled by directly modifying the netlist resulting from parasitic extraction.

I may not fully understand your intent AncisMichele, and I apologize if I am not, but I do not think you need to leave the "Assembler framework" if you wish to modify an extracted view based netlist and re-run an Assembler test or tests. This capability exists within Assembler using its "Reference netlist" feature.

Basically, suppose you run a simulation set using your extracted view based netlist and its results are placed in history file Interactive.X. From the gearlike tool at the top right of the Assembler GUI, you can set the reference history to Interactive.X. Then, if you modify the base netlist in the psf directory of Interactive.X, you can run a new simulation that will use your modified netlist from Interactive.X and place the results in a new history file, say, Interactive.(X+1).

I have used this many times to allow any manual modifications to schematic and extracted view based netlists and re-run a test within the Assembler platform.

If I understand your need correctly, this will avoid the need to use an ocean script. Using a reference netlist is detailed in the ADE Assembler User Guide at URL:

https://support.cadence.com/apex/techpubDocViewerPage?xmlName=assembler.xml&title=Virtuoso%20ADE%20Assembler%20User%20Guide%20--%20Running%20Simulations%20-%20Rerunning%20Simulation%20after%20Modifying%20the%20Netlist&hash=pgfId-1064035&c_version=ICADVM20.1&path=assembler/assemblerICADVM20.1/asmSimulating.html#pgfId-1064035

This can also be found in the documentation downloaded with your version of the Cadence tools.

I hope this helps AncisMichele.

Shawn

Dear AncisMichele,

AncisMichele said:

I would like to run slight variations of a design, which so far is organized within the Assembler framework.

These variations are best handled by directly modifying the netlist resulting from parasitic extraction.

I may not fully understand your intent AncisMichele, and I apologize if I am not, but I do not think you need to leave the "Assembler framework" if you wish to modify an extracted view based netlist and re-run an Assembler test or tests. This capability exists within Assembler using its "Reference netlist" feature.

Basically, suppose you run a simulation set using your extracted view based netlist and its results are placed in history file Interactive.X. From the gearlike tool at the top right of the Assembler GUI, you can set the reference history to Interactive.X. Then, if you modify the base netlist in the psf directory of Interactive.X, you can run a new simulation that will use your modified netlist from Interactive.X and place the results in a new history file, say, Interactive.(X+1).

I have used this many times to allow any manual modifications to schematic and extracted view based netlists and re-run a test within the Assembler platform.

If I understand your need correctly, this will avoid the need to use an ocean script. Using a reference netlist is detailed in the ADE Assembler User Guide at URL:

https://support.cadence.com/apex/techpubDocViewerPage?xmlName=assembler.xml&title=Virtuoso%20ADE%20Assembler%20User%20Guide%20--%20Running%20Simulations%20-%20Rerunning%20Simulation%20after%20Modifying%20the%20Netlist&hash=pgfId-1064035&c_version=ICADVM20.1&path=assembler/assemblerICADVM20.1/asmSimulating.html#pgfId-1064035

This can also be found in the documentation downloaded with your version of the Cadence tools.

I hope this helps AncisMichele.

Shawn

Dear Shawn,

thanks for your reply.

First, I would like to point out that your answer offers, most likely, a good workaround but does not address the main issue I've tried to highlight, namely that if you declare your design to be a netlist, it seems like OCEAN XL ignores all statements that follow the design() declaration, resulting in an input.scs file without analyses, model include and so on...

Second, I wasn't explicit in my post but I would like to move away from point-and-click management of my designs, towards a more script-oriented framework. I gravitate towards good old GUI simply because I never managed so far to build a solid alternative framework.

I thought that maybe OCEAN XL, with its distributed jobs capabilities, would be a good candidate.

Third, onto your suggestion. I think it might well work, and is a promising alternative, especially to just get to my goal.

Just for clarification: I tend to use sweeps externally, within the Assembler framework, as opposed to "internal" sweeps, generated within the analyses themselves, because the former can be launched in parallel, while the latter can't.

To exemplify: if I'm running an HB with a certain tone frequency, and I want to see the result for different frequencies, I would favor declaring the tone as a variable and then sweep it in Assembler, as opposed to using the HB-sweep construct. This, as said, is because the latter calculates the solutions sequentially, while with an Assembler sweep, I can just run N in parallel.

So, if we imagine that I ran a previous simulation with N points, and I want to reuse the netlist (I know how to do it, I've done it already a few times), which netlist would I then modify? Assembler creates a netlist dir and an input.scs file for every point simulated.

I imagine I should just change one netlist, right? In this case, I would modify the one that's in the /psf/netlist directory -- correct?

Or is it better to just run a single point as "reference", modify the netlist for that point (i.e. in History_Name/1/test_name/netlist/), then use it as a reference?

I''l give your suggestion a try - since you tell me you already did something similar, however I really would like to be able to just declare a netlist as my design and go from there...

Thanks!

Michele

Dear AncisMichele,

Thank you for taking the time to provide your clarifications! They are helpful, for me anyway, in understanding exactly what you would like to accomplish! Let me try to add a few thoughts on each.

AncisMichele said:

First, I would like to point out that your answer offers, most likely, a good workaround but does not address the main issue I've tried to highlight, namely that if you declare your design to be a netlist, it seems like OCEAN XL ignores all statements that follow the design() declaration, resulting in an input.scs file without analyses, model include and so on...

I have a feeling you may be combining standard ocean commands within an oceanXL environment in your script. The motivation for my comment is that I am not aware of an oceanXL design() command, but am very familiar with the ocean design() command. If you choose to include oceanXL commands in an ocean script, the oceanXL commands must be contained in a code segment surrounded by:

ocnSetXLMode()
...
ocnxlEndXLMode()

ocean commands may be used outside of these code segments. Is there any chance this might be the case within your script Michele?

AncisMichele said:

Second, I wasn't explicit in my post but I would like to move away from point-and-click management of my designs, towards a more script-oriented framework. I gravitate towards good old GUI simply because I never managed so far to build a solid alternative framework.

I thought that maybe OCEAN XL, with its distributed jobs capabilities, would be a good candidate.

You are absolutely correct. I have used ocean scripts for years to perform spectre analyses and perform subsequent post-processing outside the former ADEXL and current Explorer/Assembler GUI environments. Prior to ADEXL's availability, I used ocean to perform corner analyses or sweeps. You can also use distributed processing with standard ocean commands - or using UNIX scripting to make use of your distributed environment (such as LSF). I've included a link in the Forum post at:

https://community.cadence.com/cadence_technology_forums/f/custom-ic-skill/52047/how-to-run-spectre-simulation-with-ocean-script-without-initializing-environment-every-time-i-simulate-it/1385706#1385706

that includes a document outlining an ocean script methodology for running a set of corner analyses and a documented example. The link is to a Dropbox file and if I now include such links, my posts are flagged as spam. However the link in image format is:

AncisMichele said:

So, if we imagine that I ran a previous simulation with N points, and I want to reuse the netlist (I know how to do it, I've done it already a few times), which netlist would I then modify? Assembler creates a netlist dir and an input.scs file for every point simulated.

I imagine I should just change one netlist, right? In this case, I would modify the one that's in the /psf/netlist directory -- correct?

Yes. This is correct. Modify the single netlist file within the netlist directory under the psf directory shown explicitly below.

$ tree psf

psf

├── netlist

└── psf

AncisMichele said:

I''l give your suggestion a try - since you tell me you already did something similar, however I really would like to be able to just declare a netlist as my design and go from there...

You should be able to do this with ocean commands. I hope this provides some ideas Michele!

Shawn

Thanks Shawn!

As for the design() command and such, I just did what I wrote in the first post:

1. save an ocean script from the Assembler environment I am using

2. change the design() directive

3. ...

So, the design directive is in the saved OCEAN XL script from Assembler. Actually, the script is quite readable and defines different tests, each with its own design, then design variables, analyes, model paths and so on.

After the section about the different tests, there are sections to define the job policy, general variables (those you would normally sweep), corners, enable/disable specific tests and variables.

Note: the unchanged OCEAN XL script works fine. It only has problems if I change the design() command from

--> design("mylib" "mycell" "myview") to

---> design("/path/to/netlist")

All in all, I'm curious to learn from you how you use OCEAN XL to simulate without using the design() command!

The script that comes from the "save script" in my maestro Assembler view does begin with ocnSetXLMode('assembler) and ends with the corresponding closing command.

A test definition starts like this:

While my "special case" starts like this:

I would know how to set up a framework that just performs the necessary netlist changes to a bunch of files and directories and then reproduces the "sweep' construct. The only thing that has stopped me has been the prospect of using OCEAN XL directly, so being less dependent on other machinery outside the Cadence environment. Also, I would not know how to make a sweep with parallel jobs and still create the main psf directory in such a way that you can plot curves as "families".

If I just create N points myself, with N netlists and so on, the result is N psf files with separate results. If I do it via Assembler, then the result can be accessed via a single psf directory which then links to the single results as if they were part of the same family.

This is quite handy and I don't know how to reproduce it without using assembler for sweeps.

I'll have a look at your script, thanks for sharing!

In Summary, these are my goals:

1. program/manage simulations in a script-oriented as opposed to GUI oriented fashion

2. be able to run sweeps as parallel jobs

3. keep the results of the sweeps in 2. as curve families, as Assembler naturally does

4. Not be limited to netlist existing cellViews, be able to use netlists too!

Regards,

Michele

Dear AncisMichele,

Thank you again for both reading my thoughts and adding your additional information!

AncisMichele said:

Note: the unchanged OCEAN XL script works fine. It only has problems if I change the design() command from

--> design("mylib" "mycell" "myview") to

---> design("/path/to/netlist")

I believe I may know what the problem may be. To allow scripting of the corners and sweeps function in Assembler, the oceanXL  set of commands was added. However, I also believe its use of the design command is limited to the form of the command design (t_cktFile | t_lib t_cell t_view) as it is going to netlist the design to create the corner input.scs files. I believe using the design() command with its only argument the UNIX path to the netlist (i.e., design ("<path_to_netlist>") ) within the oceanXL code segment does not force the use of the core netlist your provide as it is expecting to re-netlist. I think this is why when you use the form of the design command with only the path to netlist, it does not include the design variables and analysis statements. The core netlist does not contain these.

However, I have a thought. I currently do not have access to the Cadence tools and cannot verify it, but pass it along to you if you care to try it. Suppose you set up to use a reference netlist and then save the resulting oceanScript file. Compare the means by i which the reference netlist is included in the script. With the reference netlist option, the netlist is not re-created - which is what you want. Perhaps using this oceanScript as a template might provide a workaround.

AncisMichele said:

If I just create N points myself, with N netlists and so on, the result is N psf files with separate results. If I do it via Assembler, then the result can be accessed via a single psf directory which then links to the single results as if they were part of the same family.

Prior to the availability of ADEXL and then Assembler, I handled the fact there was not a single psf directory referencing individual results by including the post-processing and plotting commands in the ocean script and setting up arrays to hold data. This is still a possibility. Of course, with the database structure of ADEXL/Assembler, I use scripts totraverse that database and plot/post-process data. A simple ocean script can traverse the ADEXL/Assembler data base structure. I've provided a few Forum posters example scripts to do this.

Shawn

Hi Shawn,

Thanks for deepening the discussion!

I actually thought of copying what's written in the OCEAN XL script when one chooses a "reference netlist" myself, but when I tried the first time, the software got stuck (one of the reasons why I'd like to learn to do things in a more controlled way) and I desisted.

But with your new input, that's going to be my next try once I get the chance. Thanks a lot!

ShawnLogan said:

I use scripts totraverse that database and plot/post-process data. A simple ocean script can traverse the ADEXL/Assembler data base structure. I've provided a few Forum posters example scripts to do this.

I have already started looking in the white paper you shared on dropbox - If you have other examples and materials, this would help me immensely!

Regards,

Michele

Dear AncisMichele,

AncisMichele said:

But with your new input, that's going to be my next try once I get the chance.

Sounds good!

AncisMichele said:

I have already started looking in the white paper you shared on dropbox - If you have other examples and materials, this would help me immensely!

There are two other Forum posts that provide some ocean code to traverse an ADEXL/Assembler database and retrieve results from each of the corners of the test. The reference I provided was for a Monte Carlo simulation - whose database structure is slightly different than for a conventional corners/design variaible sweep. The post at URL:

https://community.cadence.com/cadence_technology_forums/f/custom-ic-design/47844/ocean-script-for-printing-parametric-sweep-dcop/1373726#1373726

contains a link to the Cadence document describing the ADEXL/Assembler/Explorer database structure and some details as to what modifications to an example ocean script to traverse a conventional corners or design variable sweep database. The example ocean script to traverse a database, extract results from each case and format them to a file (or plot them)  is at the Forum post:

https://community.cadence.com/cadence_technology_forums/f/custom-ic-design/43159/way-to-use-skill-script-to-save-waveform-into-a-file-in-ade-xl-run

and this post is referenced in the former URL post.

I hope this is helpful Michele! Let me know if anything needs clarification.

Shawn

Michele,

I finally had a chance to look at this, and from what I can see, using design() with a netlist (the file has to be called netlist for long-standing reasons) should work with ADE XL/Assembler. My quick tests seemed to show it getting stuck though - I think it has worked in the past (I found CCRs where fixes were put in place many years ago to support this). I suspect it's not widely used though, which may explain why it's broken and not been noticed.

You'd have to contact customer support to follow up on this.

Andrew