Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
I already had solved the first one by coping link libraries from .synopsys_dc.setup file to .synopsys_pt.setup.
About the second one, I don't want to sepcify one particular timing arc. I need prime time to examin different timing paths and specify the worst delay, but report_timing and report_delay_calculation don't work this way. I'm still working on it.
one thing i can suggest is to create the path groups and then do the timing analysis to get the timing information in the different paths,,,, i mostly work with cadnece tools,,, am not sure how this will be wrking in PT
Correctly define your clocks, constrain input/output delays, define clock relationships ( if some clock domains are async, then declare them as false paths).
Then just do a "report_timing" without any arguments. It would print the top violators in each of the clock domain. It would make sense to group inputs and outputs into separate path groups based on their clock domain, otherwise they would clutter your flop to flop path reports.
I have tried this, but the design is asynchronous. Most of the circuit works in one clock cycle, but there is one component which requires a variable number of clock cycles to complete. There are also some other combinatorial componenets. Therefore, the final output component is not clocked. Maybe this makes the trouble.
Tanks any way.
I have tried this, but the design is asynchronous. Most of the circuit works in one clock cycle, but there is one component which requires a variable number of clock cycles to complete. There are also some other combinatorial componenets. Therefore, the final output component is not clocked. Maybe this makes the trouble.
Tanks any way.
1. If design is asynchronous, then you are picking up wrong tool. I am assuming design is synchronous, and you either had a typo or are getting confused.
2. Primetime be default assumes all paths to be single cycle paths. If you have flop to flop paths which have been designed to work in multiple cycles, then use primetime command to set that constraint. I think the Primetime command is 'set_multicycle_path' or something similar. 'help *multi*' should get you to the right command.
3. What you are saying by output component being not clocked is common. You need to give right set_output_delay for this output pin/port with respect to correct clock.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
