Input Capacitance Characterization in Cadence Liberate

Hi,

This is not a normal standard cell, and you may have different issues if you want to characterize it. Can you find specifications for cells of such a nature, ie. a transmission/pass gate, in the Liberty documentation?

For the specific question you raised here, please read the liberate manual on harness. It might or might not work. basically, you may put any external components into a harness. 

Regards,

Guangjun 

Thanks alot for your reply. My question should be, rather, how to characterize such a cell.

From the manual, following seem to be related to this type of behavior : 

However, it's bit unclear how these switches should be used in the script and whether they satisfy my requirement. I'll look for the "Harness" in manual.....

Anuradha

Hi Again,

These settings are for CCSN noise model.

Regards,

guangjun

Hi Guang, one of the harness example codes in the manual is shown below:

https://pastebin.com/QZrD6Xb6

1. What do "Xdriver0_1" and  "I0_altos_tmp" represent ? altos_in, altos_out and altos_stim were explained in the manual.

2. In this example, the input stimulus to the target cell seems to be an inverter. But what does the "order" mentioned in number 3. imply ? Are vdd, vss and INV_1 assigned to other 3 terms respectively ?

1. * driver for pin I1,
2. * I1_altos_stim -> I1_altos_tmp -> I1_altos_in
3. Xdriver1_1 I1_altos_tmp I1_altos_stim vdd vss INV_1

3. Although the cell behavior is similar to my case (un-buffered), I cannot find a diffinition of input capacitance in the cell or any .subckts. So in this case, is the input capacitance of target cell neglected or considered to be driving inverter input capacitance (Both not accurate) ? 

4. Under "harness parameters", <subckt_pin> _cap definition is there for output loads. There is no way to define the input cap though !

Anuradha

1. Xdriver* are instance names in the actual external driver in this example. 

2. The example is just to show you how to define a harness to bias/load a cell with external circuit. Actual content will depend on your case.

3. I do not see any similarity here. generally speaking, a transimisson/pass gate does not have a liberty model, as this is not documented in Liberty specification. 

4. I was hoping you can use a harness to include the elements, so that the actual capacitance will be simulated during your Liberate run.

Guangjun

1. Xdriver* are instance names in the actual external driver in this example. 

2. The example is just to show you how to define a harness to bias/load a cell with external circuit. Actual content will depend on your case.

3. I do not see any similarity here. generally speaking, a transimisson/pass gate does not have a liberty model, as this is not documented in Liberty specification. 

4. I was hoping you can use a harness to include the elements, so that the actual capacitance will be simulated during your Liberate run.

Guangjun

Guangjun Cao said:

4. I was hoping you can use a harness to include the elements, so that the actual capacitance will be simulated during your Liberate run.

If this cell is used for a well defined design, I can define the right output capacitance to the cell using a harness (As I know the exact capacitive load that connects to the cells output). But during the synthesis, the capacitive load to any cell bound to change, so that assigning a fixed load during a characterization does not help. Instead the "input capacitance" should be decided from kind of a look up table or something depending on the attached load. 

If there is a harness parameter for input cap i.e. <subckt_pin_in> _cap, I can directly assign out_cap to be in_cap  in harness subckt block (instead of letting it to be a fixed value).  May be this is not doable.

Anuradha

From what I understand, the input capacitor come from contribution of other active devices. That's why I suggested you to try harness. with this approach, the devices in the harness will be included/simulated during the charatcerisation. 

If the input cap has fixed values depending on external port condition, you can also create a wrapper cell with the same name as the cell to be characterized. inside the wrapper, you can use spice commands to assign a different value based on external port condition. you will have to make sure the simulation can run successfully.

Guangjun

Apart from introducing harness blocks, is there a way we can interfere into the "capacitance measurements" of a pin in liberate ? Instead of a fixed single value, to define a range of capacitances depending on i.e. an external condition ? So that in generated .lib file (shown below) :  

pin (A) {
   direction : input;
   related_ground_pin : VSS;
   related_power_pin : VDD;
   max_transition : 0.56;
   capacitance : 0.0289202;
   rise_capacitance : 0.0289202;
   rise_capacitance_range (0.000516565, 0.0289202);
   fall_capacitance : 0.0287069;
   fall_capacitance_range (0.000516728, 0.0287069);

I want to say that pin A capacitance value (0.0289 - in this case quite higher since no input buffering), should be depending on output load. In other words, use the right input capacitance for input A (from rise_capacitance_range) depending on the output load. To the best of my knowledge, rise/fall capacitance range of this type of cell highly depends on output conditions.

Anuradha

I am not sure that I understand your question(s) now.

If you can characterise the arcs successfully, a harness will be the best way to account for non-linear capacitance contributed by external component---This has never be clarified by you.

It is not clear to me what you meant or wanted with the last example. The default syntax with liberate-generated library is like the example. 

If you want to post-processing some attributes/values, you can use the user_data flow (please refer to write_userdata_library and search for other user_data, if needed). Or, you may try set_attribute command. 

Guangjun

Hi Guang,

I used the "harness" in cell and defined a custom output loads. The characterization log file is shown below:

https://pastebin.com/u5z3YD4d

For some reason, it first states "passing all cells" and at the end of the run prints "bad ccs data found...". I tried convert the .lib file to a .db and then conversion too also complains that some timing arcs were missing in .lib. Well I started with assigning a reasonable cap load to the output terminals. Any idea what went wrong in this ?

Thanks

Anuradha

are we still talking about the same cell? if so, you will not be able to get a valid ccs mode for such a cell. CCS model creation relies on the related PG pins, which does not exit in your case.

Guangjun

Yes Guang, it's about the same cell. But without the "harness", characterization works just fine. The only issue is the capacitance and power numbers generated by the tool were wrong. 

I was wondering whether we cannot use one of "input pins" as a PG pin to the output since output capacitance is truly excited by the input signal in this type of a cell. So end of the day, does this mean that we have no way to characterize this type of cell at all ? 

Thanks alot for all the inputs so far Guang....

Anuradha

The cell is not a standard cell. Nor is it supported by Liberty format. 

Since there is no PG pin, power does not make any sense to a downstream STA tool.

Guangjun

Hi Again,

I saw a similar post regarding a transmission gate type (non-standard) cell characterization issue : 
https://community.cadence.com/cadence_technology_forums/f/custom-ic-design/41066/characterization-of-a-transmission-gate-liberate

So would Liberate AMS do a better job in characterizing such non-standard cells ? 

Anuradha

It is about Liberty specification/support, not how this should be characterized. we have discussed this before. If you can find a specification for this cell in Liberty documentation, and how this cell should be characterized, please let me know.

Guangjun