Cannot select signals to be saved in ADE Explorer/Assembler; net listing is incorrect etc.

Which IC sub-version are you using? I just tried with IC6.1.8 ISR22 and I don't see that behaviour. That said, current signals are shown as signal (I) now and have been for some time, so I'm guessing you're using some older version.

Andrew

Hi Andrew,

Thanks for your reply and happy new year!

I am using IC6.1.7-64b.500.18.

I tried using creating a new schematic and maestro state but still get the same trouble. Netlist looks like:

save I6:TSB<1> 

but it should be (escaped)

save I6:TSB\<1\> 

What happens exactly at net listing? What is run with which parameter?

Maybe this gives more clues what's going wrong?

Thanks!

EDIT: Could the issue be somewhere else? Maybe how I6 is defined (CDS parameters)?

PS: As a dirty workaround, I created "save_currents.scs" manually and include it but this is not really a solution because I'd like to change which currents are saved on the fly.

Dear SteveVrk,

SteveVrk said:

I am struggling with a very basic bug(?): ADE Explorer/Assembler just won't let me properly save current signals of a bus of an instance:

I am wondering if the issue is related to the syntax for save a current of a terminal that is part of a bus structure. The ":"  character shown in the netlist is correct since it is a terminal you are probing, however, the remainder of the save statement is not due to lack of escape characters. However, suppose the netlister is NOT correctly handling the terminal save statement for a single wire of the bus structure you have defined.

In your test case, if you have time, might you add a non-bussed terminal, say "test_output", select its current to save and examine the resulting nelist to see if the save statement is syntactically consistent with Cadence netlisting syntax?

Shawn

Hi Shawn,

Thanks for this pointer.

Yes, I think this is correct:

save I6:test_output

One other thing: This cell is actually code from an sp file. So to add the test above, I had to add "test_output" to the .SUBCKT statement (and make a dummy connection via a resistor), then add "test_output" to auCdl, auLvs, hspiceD, spectre fields of "termOrder" property in CDS, then add it to the symbol.

Could it be related to the fact that the cell comes from there? Interestingly if I create a new, normal cell (with schematic and symbol view) things seem to work. 

Thanks!

Dear SteveVrk,

SteveVrk said:

Yes, I think this is correct:

save I6:test_output

Interesting! Thank you for both taking your valuable time to try it and letting us know!

SteveVrk said:

One other thing: This cell is actually code from an sp file. So to add the test above, I had to add "test_output" to the .SUBCKT statement (and make a dummy connection via a resistor), then add "test_output" to auCdl, auLvs, hspiceD, spectre fields of "termOrder" property in CDS, then add it to the symbol.

Could it be related to the fact that the cell comes from there? Interestingly if I create a new, normal cell (with schematic and symbol view) things seem to work. 

If I am interpreting your question and comment correctly, I don't  think it is related to the fact that it is a symbol representing a subcircuit that contains an S-parameter file. Why do I say this? Normally, when I create a symbol for any textual netlist (SPICE syntax or S-parameter), I must edit the CDF for the cell - i.e., I manually add the inputs and outputs. However, when I create what you call a "new normal cell (with schematic and symbol view)", the CDF is defined  using the terminals I define in the symbol or schematic view of the cell. In essence, in your S-parameter file, adding an input to the file will not automatically update its symbol's CDF. This is my understanding any - subject to any corrections by Forum monitors!!

So, I think the real issue is the syntax for a terminal that is part of a bus structure. My initial conclusion anyway! As a potential workaround (there may be others may suggest that are more efficient), I might suggest you add current probes or resistors to those wires in the bus for which you would like to save their currents and add save statements to the iprobe terminals or resistor terminals...a bit more work...but may allow you to both save the specific currents and netlist correctly.

Once again, subject to your available time and "energy" to address your problem!!

Shawn

Hi Shawn,

Thanks, the resistor is a good suggestion.

Unfortunately it still does not fix the first problems: Once I add an expression and edit it, I cannot select "Save" any more.

I can add a new signal and select one current signal of the bus and get the following expression in the "Output Setup" window:

/Rsns_ts<1>/MINUS

After that, I can select the "Save" checkbox.

If I then manually change to something else, e.g. /Rsns_ts<2>/MINUS, the checkmark for "Save" automatically disappears (the signal  /Rsns_ts<2>/MINUS is valid and exists!). I cannot click the "Save" checkbox any more. Even if I immediately change back to /Rsns_ts<1>/MINUS, I cannot select "Save" checkbox any longer, and as such, the signal does not appear in the "save" expression in the netlist!

Only option is to completely delete the expression and add it new from scratch. Super frustrating.

Why is this such a problem for me? Because It is a bus and I want to save the whole bus! So I want to change it to something like

/Rsns_ts<1:64>/MINUS

Thanks again!

Dear SteveVrk,

SteveVrk said:

Thanks, the resistor is a good suggestion.

Great - I do hope it helps a little anyway toward your ultimate desire!

SteveVrk said:

Why is this such a problem for me? Because It is a bus and I want to save the whole bus! So I want to change it to something like

/Rsns_ts<1:64>/MINUS

Unfortunately, I do not have access to the IC-sub version of Cadence you are using! I only have access to the versions our tool team provides us - and they are all more recent versions. Hence, I can't assure any experiments I perform are of any help to you...my apologies! Others who monitor this forum likely do have access to other versions and, their time permitting, might be able to try to duplicate your problem and help resolve it. Sorry!!

Shawn

Signal outputs are not expressions, and historically they couldn't be edited. Now I did try in the old version you're using (from nearly 4 years ago, and it's an unsupported version), and I found that if I tried to edit the signal name, it ended up saving it as a voltage rather than a current. I certainly did not see the name mapping issue you are describing. There was no support for saving/plotting whole buses of currents in that version. You could save buses of voltages, but not currents. Also, it wasn't clear whether a signal was a voltage or a current, and so editing the signal name could change the nature of the signal without there being any visibility.

In a fairly recent IC6.1.8 version, IC6.1.8 ISR18 (so IC6.1.8-64b.500.18), you can now click on the pin of an iterated instance or the pin of a bus on an instance and use the "include as bundle" when adding terminal currents as well as voltages. Also since an early IC6.1.8 version there is a distinction between signal and signal(I) in the outputs. At some point (I did check in my experiments just now but didn't note exactly which version it changed in, and I'm not going to repeat my experiments since you really want to be using ISR18 or later anyway) editing the text of signal(I) signals stopped converting them into voltages.

So to summarise, I suggest you move to IC6.1.8 ISR18 or later to do what you want - this should make your life much easier and you'll be able to do what you want.

Note that I didn't at any point get the rather strange save statements you did with the non-escaped names. It's possible that some local customisation is breaking things - if you still see the problem after moving to the newer, supported, version which supports buses of terminal currents, then you should contact customer support so that we can do a deeper investigation.

Regards,

Andrew

Dear Andrew,

Thank you VERY much for taking the time to both research this as well as include your additional insight! As usual, you were aware of the "history" and very detailed signal naming conventions that I was not able to provide to SteveVrk. Speaking for myself anyway, thank you!!

Shawn