Stats

  • Locked Locked
  • Replies 17
  • Subscribers 64
  • Views 21754
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Liberate_AMS for .lib generation.

anandmohan

Hi,

I'm having Liberate_AMS for characterization of AMS blocks. Can I use the same for the characterization of a std cell library ? 

The main difficulty involved is in generating the input stimulus files which need to be given in the form of tables in Liberate_AMS whereas it can be included with the attribute -vector inside the template file (in case of Liberate).

Still I managed to manually create those table files for ** number of cells. After that I included those tables using the define_table command in the template file.  I had to give ** define table commands (1 for each cell) . But I'm getting an error regarding "delay_template" not defined.

After all , I wanted to know, if characterising multiple cells (by including multiple input stimulus files) is possible in Liberate_AMS ?  Or is it a futile attempt trying to do that ?

Is there an inherent limitation on the number of cells that can be characterized using Liberate_AMS in a single run ?  (other than the brute force way of characterising 1 cell at a time and merging all of them- as I have huge number of cells - typically the number of cells usually present in a std cell library).

  • in reply to Guangjun Cao

    Thanks Guangjun...

    When using Liberate_AMS, In the Liberate_AMS RAK I came across guidelines on the observation_window values which needs to be given to capture the delay,setup/hold constraints. Is there such a guideline which need to be followed when capturing the mpw(min pulse width) .

    In define_deck command, when i give 'types -timing' i get everything except mpw, I get mpw only when I specify 'types -mpw'.  Isn't mpw also supposed to come under 'timing' category as I have read so in the user manual. 

  • in reply to anandmohan

    In the liberate_ams manual, it says, "Observation window is the clock period divided by 4" in one of the examples for define_deck. For further details, please read the manual.

    Different sub-types of timing arcs are controlled by separate commands/variables in Liberate tools. mpw is not always required for all kinds of blocks. There may be special requirements in the settings that apply to mpw-type only. 

    In case you do not know, we have local support teams around the world. You can submite Cases for various support requests. If you are interested in attending a training course, the local team can also help you on this.

  • in reply to Guangjun Cao

    Hi,

    I'm trying to characterise a D flip flop using Liberate AMS. For the input stimulus, I'm creating tables (.tbl files) manually. I'm able to verify from the deck that my input stimulus is getting generated. I'm able to characterise the delay but I'm not able to characterise the setup & hold times. Given below a snapshot of the .tbl file and also a snapshot of the log...pls help

  • in reply to anandmohan

    Please stop doing this. I already split the post you made yesterday (using the same information as above) in this thread into a separate post - here: Liberate for .lib generation of D flip flop

    As I said there, the forum guidelines ask you not to continually post different issues in the same thread as it makes it very hard for anyone else to benefit from the existing threads if they are searching.

    Andrew.

  • in reply to Andrew Beckett

    Sorry Andrew. I didnt know tht u had split the post into a seperate thread. On seing the post missing i thought it didnt get posted and so did the same thing again

  • in reply to anandmohan

    please use liberate instead of liberate_ams.

  • in reply to Guangjun Cao

    Hi Guangjun...similarly in mpw (min_pulse_width) attribute of a clk signal, we have 2 sections, rise constraint and fall constraint....Whats the significance of the seperately annotated 'rise_constraint' and 'fall_constraint' ?

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.