( ESNUG 378 Item 6 ) -------------------------------------------- [10/03/01]
Subject: ( ESNUG 377 #20 ) Getting Expanded PrimeTime Clock Path Reports
> When using PrimeTime, is there anyway to get the reports to expand the
> "clock network delay (propagated)" statements to see how PrimeTime is
> actually calculating the clock paths? With circuit clocking getting more
> complex and library modeling issues, I'd like to be able to look at the
> numbers to increase my confidence in what is being reported, instead of
> blindly trusting Primetime. Below is an example.
>
> Point Incr Path
> -----------------------------------------------------------------------
> clock TCK (rise edge) 0.00 0.00
> clock network delay (propagated) 9.02 9.02
> ucore/utestblk/utst_gpio_mux/portb5_sel_reg_0/CK (SDFFX1)
>
> Thanks,
>
> - Russ De Hoedt
> Conexant Systems, Inc.
From: "William Natter" <wnatter@nortelnetworks.com>
Hi John,
PrimeTime gives you access to a lot of its internal objects, and allows you
to create Tcl procedures. If you want, you can create a procedure that
traces its way from the first master clock, through generated clocks, and
all the way to the startpoint of interest using "get_timing_paths".
Remember that this clock network delay includes the latencies of the clocks.
- William Natter
Nortel Networks Nepean, ON, Canada
---- ---- ---- ---- ---- ---- ----
From: Leo Butler <lbutler@brocade.com>
Hello, John.
report_timing has the option "-path_type full_clock" which will expand the
propagated clock delay calculation. I don't know how far back that command
goes in PrimeTime versions, but it's present in at least 2000.11 and above.
- Leo Butler
Brocade Communications
---- ---- ---- ---- ---- ---- ----
From: Lars Bo Graversen <larsg@mips.com>
John,
Russ might want to try '-path_type full_clock' in the report_timing command.
I think that it might get him the information he wants.
- Lars Bo Graversen
MIPS Denmark
---- ---- ---- ---- ---- ---- ----
From: Wayne Miller <Wayne.A.Miller@smsc.com>
Hi John,
I'm sure I'm chiming in late, but I think this is what Russell wants:
report_timing -path full_clock
Hope this helps,
- Wayne Miller
Standard Microsystems Corporation Long Island, NY
---- ---- ---- ---- ---- ---- ----
From: Khris Kofford <kkofford@amis.com>
John,
Saw Russ' post on ESNUG. Not totally sure what he's trying to do, but has
he tried: "pt_shell> report_timing -from FOO1/C -to FOO2/D -input_pins
-path_type full_clock" ? This will split the clocktree into individual
buffers in the report instead of giving you the lumped delay.
- Khris Kofford
AMI Semiconductor
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
John,
I assume by now that a hundred people have suggested to Russ to "-path_type
full_clock". If not, try it. I think it does what he wants.
By the way, you can get some "interesting" results with this if you haven't
controlled your clock MUXes with set_case_analysis. I had a case where
PrimeTime would report DIFFERENT values when I had -path_type full_clock
turned on than it did when it was not! The problem was ultimately traced
to an uncontrolled clock MUX.
- Paul Zimmer
Cisco Systems
|
|
