( ESNUG 360 Item 8 ) --------------------------------------------- [11/02/00]
Subject: ( ESNUG 359 #5 ) DC/PT Script To Detect Paths Across 2 Clocks
> I have a world with two clock domains:
>
> SysCLK Domain PCI CLK Domain
>
> ------
> | |
> -->| ff |-------->|----------|
> | ------ | |
> | | comb. | Sync FF's
> | ------ | logic | ------ ------
> | | ff | | | | | | |
> |-->| |-------->| |------->| |--->| |----> FSM
> | ------ | | | | | |
> | | | ------ ------
> | ------ | | |__________|________ PCI_CLK
> | | ff |-------->|__________|
> |-->| |
> | ------
> |
> SYSCLK
>
> As you can see from the above diagram, the output of SYSCLK FFs go into
> some combinational logic and feed into FFs clocked by PCI_CK. The outputs
> of the PCI_CLK FFs go into a FSM.
>
> Let's say a glitch were to occur at the posedge of SYSCLK:
>
> 1) This could trigger a false (high) start signal and the output of
> combinational logic would register a high. Because PCI_CLK has no
> way to verify that this is a glitch, not a valid signal, it would
> start the PCI_CLK FSM.
>
> 2) The correct solution is to put another FF after the combinational logic
> clocked to the SYSCK, thereby preventing this glitch.
>
> Are there any DRC tools out there that might catch this type of problem?
> Do your users have any DC scripts that could test for this type of
> problem?
>
> - Subha K. Pindiproli
> Emulex Network Systems Costa Mesa, CA
From: Ken Rose <kenr@cisco.com>
John,
It would be nice if there were scripts to identify this situation, and I
hope someone will post said script.
Barring the provenance of such a script, one alternative is to use a careful
design methodology to preclude the problem situation from occuring.
In the case Subha brings up, hierarchy can be very helpful. If you have a
module that contains both clock domains, introduce another level of
hierarchy in that module and require that only a single clock domain exists
in any sub-module. At that point it becomes easy to inspect the sub-modules
and make sure any signals leaving come from flops.
- Ken Rose
Cisco Systems San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Siegfried Weidelich <SHW0889@mcdata.com>
John,
I have run into the same situation, and what I do in DC is a timing report
something like:
report_timing -from find (clock SYSCLK) -to find (clock PCI_CLK)
This will give you a timing report with all paths from SYSCLK domain to
PCI_CLK... then you can look at the paths to see if they are flop-to-flop
(ie., no unexpected gates in the path). I suppose you could redirect to
a file and parse for gates in the path to automate it, but crossing clock
domains is tricky, so I like to manually investigate every path thoroughly.
Also, if you make it a rule to call the clock domain boundary flops a
special name in your RTL like "rdy_s2p" so that your netlist has
"rdy_s2p_reg", then you can do the same report with the "-path short"
option to check that all the paths crossing the clock domain start and
end with a flop with "_s2p" contained in the name. It can be a much
smaller file to check! Hope this helps.
- Siegfried Weidelich
McData Corporation
---- ---- ---- ---- ---- ---- ----
From: Larrie Carr <Larrie_Carr@pmc-sierra.com>
John,
Sadly, I have seen this structure before... To catch these types of
mistakes, I use PrimeTime to report all interfaces between 2 clock domains.
create_clock <:one domain>
create_clock <other domain>
report_timing -from <one clock> -to <other clock>
If you don't seen flop to flop or flop/buffer/flop, you got a problem. But
of course, this doesn't tell you if you got all your sync flops.
Never got around to automating it.
- Larrie Carr
PMC-Sierra
---- ---- ---- ---- ---- ---- ----
From: Dirk Luckett <dluckett@raytheon.com>
John,
First lets assume the SYSCLK and PCI_CLK are asynchronous. You should never
try and synchronize multiple signals from one domain to the other and into
an FSM. You cannot count on them all arriving at the FSM the same cycle
in the "REAL" world. (they will in the artificial simulation world of course).
The layout of each signal trace will cause the timing of each signal across
that boundary to be different and unique.
Second, to provide some thoughts on your question. I have had a design
with asynchronous clocks. I generally set a false path from SYSCLK to
PCI_CLK to prevent any setup or hold checking on those paths. This also
allows PrimeTime to classify those endpoints as "untested". You can get
a list of all untested endpts (which you should already be reviewing)
by executing the command:
report_analysis_coverage -status_details {untested} -sort_by {check} \
-significant_digits 3 -nosplit > ./untested.rpt
This isn't a real direct approach but it is workable. Other users may have
better suggestions; but I employed this one in the last month.
- Dirk R. Luckett
Raytheon
---- ---- ---- ---- ---- ---- ----
From: Will Leavitt <leavitt@giganet.com>
John,
I got this right out of Solvit:
QUESTION:
How can I find all of the paths in my design with start and
end flip-flops triggered by different clocks?
ANSWER:
For the following example, the assumption is that there are
only two clock domains; however, you can easily modify this
script to include designs with more clocks.
1) create_clock CLK_25 -period 25
create_clock CLK_10 -period 10
2) group_path -default -to all_clocks()
3) set_false_path -from find(clock,CLK_25) -to find(clock,CLK_25)
set_false_path -from find(clock,CLK_10) -to find(clock,CLK_10)
set_false_path -from all_inputs() -to find(clock)
set_false_path -from find(clock) -to all_outputs()
4) report_timing -path only -max_paths 1000
EXPLANATION:
1) Create the clocks that your design will use. You can
optionally use the "-name" option to name your clock something
other than the port name. If you use this option, make sure
to refer to this new name when using set_false_path. For
example
create_clock CLK_10 -period 10 -name phase_1
set_false_path -from find(clock, phase_1)
2) By default, each time you create a clock, a new path group is
also created containing the endpoints relating to this clock.
If you create two clocks named CLK_10 and CLK_25, you will
have three path groups, "default, CLK_10, and CLK_25". You
want all of the paths to be in just one path group, so use the
group_path command to group them all into the "default" group.
3) Now that all of the paths are grouped into one path group,
eliminate all paths triggered by the same clock by
setting a false path on them. Similarly, eliminate all paths
originating or ending at ports.
4) Finally, report all of the remaining paths. These are
all paths that cross clock domains. If you anticipate more
than 1000 paths, change the value of "-max_paths" accordingly.
This command only returns one path per endpoint, so if you
want an exhaustive list of all paths, add the "-nworst 100"
option to the report_timing command.
I never would have thought of this myself... Good luck.
- Will Leavitt
Giganet
---- ---- ---- ---- ---- ---- ----
From: London Jin <jinl@taec.toshiba.com>
Hi John,
This well-known problem has well-known solutions.
1. Synopsys does have a tcl script released with PrimeTime:
set clock_list [all_clocks]
foreach_in_collection from_clk $clock_list {
foreach_in_collection to_clk $clock_list {
if { [get_object_name $from_clk] != [get_object_name $to_clk] } {
set_false_path -from [get_clocks $from_clk] -to [get_clocks $to_clk]
}
}
}
Changing set_false_path to report_timing gives you all possible paths
between clocks.
2. Avanti has a tool called Clock Domain Checker FDRC.
http://www.avanticorp.com/product/1,1172,62,00.html
3. IKOS emulation compiler can also specifically reports them.
Hope this helps.
- London Jin
Toshiba San Jose, CA
|
|
