( ESNUG 220 Item 5 ) ---------------------------------------------- [7/7/95]
From: sgolson@trilobyte.com (Steve Golson)
Subject: Design Size Dependant Hierarchical Timing Bug (3.1b & 3.2b)
John,
I have timing report from a design, showing a 44.12ns path. I move up a
level in the hierarchy, so the previous design is now an instance named
"cntl" in this upper design. Now the *same* path now shows 214.02ns delay!
*All* of the incremental delays have increased. This has the same wireloads,
the same operating conditions, report_net shows the same loads & resistances
on the nets... what the heck is going on?
The first incremental delay has some increase due to the loading on the
input port, but why have the *internal* delays changed? Somehow the delay
calculations seem to be affected by the size of the design, but I can't
figure out how. (Kurt Baty has seen this as well, and logged it with
Synopsys.)
This happens in 3.1b and 3.2b. I will try 3.3a real soon now.
It appears that this bug *only* occurs if you have a non-default driver on
your input ports (i.e., if you leave it with the default "infinite" drivers,
everything works). It doesn't matter if the path uses the clock or not. It
doesn't matter if you have defined the clock or not. If you put a drive on
your clock, things start to break. They break in different ways depending
on where in the hierarchy you are looking at the path.
- Steve Golson
Trilobyte Systems
|
|
