Question about creating a LIB timing files for a mixed-signal hard macro

[lawfulgm]

I'm trying to manually write a liberty timing file (.LIB) for a mixed-signal hardmacro shown above.

There are four outputs for this mixed-signal hardmacro: deserialized data (DESER_OUT[0~11], CLK_OUT, and RST_OUT). For the following digital RTL to be free from any timing violation, I need to come up with fairly accurate timing models for this hardmacro. While I was working on the LIB file, I've encounted few questions that I could not answer myself, so decided to get some help from this forum.


The tricky part of this setup, in my opinion, is that the pin direction of both CLK_OUT and RST_OUT are set to output. Because of this, I have quite a bit of confusion since most of examples in liberty user manual does not cover this type of scenario.

Q1: For DESER_OUT, shall I have two timing description, one with CLK_OUT being related_pin, and the other with RST_OUT?

Q2-1: One of the important timing information here is the skew between rising edge of data and rising edge of CLK. One method I am about to try is setting the CLK_OUT as related_pin for DESER_OUT bus, and then come up with LUT for cell_rise and cell_fall based on the simulation results. Do you think this is a reasonably good approach?

Q2-2: Do I also need to do the same thing for CLK_OUT and set its related_pin to RST?

Q3: When RST is high, DESER_OUT and CLK_OUT are forced to go to low (0). when RST is low, then DESER_OUT and CLK_OUT are active and starts toggling. In this situation, what is the most appropriate timing_sense value for DESER_OUT when its related_pin is RST? is it supposed to be positive_unate? negative_unate? or non_unate?

Q4: what about timing_types? What would be the most appropriate timing_types for all three signals?

Q5: are cell_rise, cell_fall, rise_transition, fall_transition good enough for timing description in general?

any feedback/comments would be very appreciated!

 

[ThisIsNotSam]

here is a different idea that does not really answer your initial post: have you considered describing the timing behavior of the macro inside the physical synthesis environment? with input delays, output delays, transitions, etc., you can do a relatively good job without worrying with the pedantic syntax of a lib file

 

[lawfulgm]

here is a different idea that does not really answer your initial post: have you considered describing the timing behavior of the macro inside the physical synthesis environment? with input delays, output delays, transitions, etc., you can do a relatively good job without worrying with the pedantic syntax of a lib file

I have not thought about this option. When you say "physical synthesis environment", are you referring to the SDC constraint?

 

[ThisIsNotSam]

No, I am referring to Innovus commands. They do all that SDC does and a bit more

 

[lawfulgm]

No, I am referring to Innovus commands. They do all that SDC does and a bit more

I see. thanks for the suggestion. Then I have a follow-up question: Let's say I have deserializer output from analog hardmacro, outputting CLK and DATA. When I toss timing information of these two signals to the digital P&R, I can either (#1) create a .lib file describing timing relationship or (#2) write a SDC file and describe the timing relationship via set_input_delay command. What would be the preferred method in this scenario?

 

[ThisIsNotSam]

A .lib file is the most correct and thorough option, but requires proper characterization. You would, ideally, rely on a tool like siliconsmart to characterize your macro. The characterization tools are very finicky, if you are feeling like going down that road, be prepared to hate yourself, your pet, your colleagues, and to curse the day you entered the chip business.

Doing the annotations direction on Innovus is much simpler, but the risk is that it might not be thorough enough. The burden is on you.

 

[lawfulgm]

A .lib file is the most correct and thorough option, but requires proper characterization. You would, ideally, rely on a tool like siliconsmart to characterize your macro. The characterization tools are very finicky, if you are feeling like going down that road, be prepared to hate yourself, your pet, your colleagues, and to curse the day you entered the chip business.

Doing the annotations direction on Innovus is much simpler, but the risk is that it might not be thorough enough. The burden is on you.

haha I like this expression... Thanks "NotSam". I will think once more about taking LIB route for this hassle.