You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!
Timing constraint management and verification has historically been the responsibility of the members of the design team who have an implementation focus (synthesis, P&R, STA, etc...). This made sense when implementation could easily be detached from functionality but those days are over. View attachment 1391
Today, low power requirements, IP reuse, and a broader use of timing constraints mean RTL designers need efficient timing constraint management at the RTL level more than ever.
Good timing constraints reflect the characteristics of the design, from the basics of the clock architecture to the complexities of timing exceptions. The only way to avoid the inevitable iterations to reach a complete and correct set of timing constraints is to get the RTL design team involved. In an ideal world, your timing constraints would be finalized before you even started any implementation work.
Constraints complete before implementation is an idealism but the two main hurdles for design teams realizing this are skill set and schedule.
The philosophy makes sense and it allows downstream tools that consume constraints to start sooner. But netlisting (synthesis, P&R, STA…) activities are not always the critical path. Increasing complexity and customer pressure leading to late features keep most engineers focussed on functional correctness beyond base layer tape-out. Subsequently, teams are not always built with an implementation focussed skill set; though my personal philosophy is that all RTL designers should be able to write SDC as part of micro-architecture.
Typically we see fewer (sometimes only 1-2) implementation engineers on a team. They typically work on the clock/DFT/IO RTL designs that are less complex from a logic verification perspective but require complex constraints. It is at this stage of the project that companies engage specialized contractors (e.g. Timing Engineers) to work with RTL designers to developing or clean constraints and drive the netlisting flow to closure. Posted by Don Dattani
To avoid and minimize iterations in layout. To the extent that the RTL false and multi-cycle paths have been identified and constrained to the synthesis tool, the layout timing will close that much sooner. Blue Pearl Software has the solution for this that is extremely RTL designer friendly and easy to use. Posted by Peter Robinson
RTL designers are the ones who are aware of false paths and multi-cycle paths in their design. They not only need to define all the false paths and multi-cycle paths in the design appropriately but also ensure that they indeed are correct. Apart from these, the RTL designers need to bless all the modes in which design is expected to run and review/confirm all the case analysis constructs that will be used in the sign-off timing analysis. Posted by Srinivasa Kakumanu
Fully agree. When the chip design reached over 100Mhz operation speed, this becomes more and more evident. Designers have to consider arch, algorithm, structure and even basic standard cells, hardmacros like SRAM in order to achieve the high performance requirement of modern SOC. In fact, RTL designers are required for more such as power, size, DFT, especially clocks for easier backend implementation. Posted by John Cheng
At present with hierarchical design, bottom-up synthesis, and well defined inter-block interfaces (avoid snake paths) the implementation is automated to a great extent. Now RTL designers just focus on functionality. Physical design team focuses on implementation. Many teams just do not create multicycle paths as defining timing constraints becomes another action item. RTL designers are consulted during constraint definition stage and when timing does not meet the requirement. In the past there used to be netlist hand-off to Physical design team an now RTL is handed off. RTL designers do logic and memory estimation in their blocks and PD team infact generates the vendor memory blocks to be used by the RTL designer. Vendor carries many IPs. Coding style is defined so that Low Power implementation from RTL perspective is automated. Other methods of Low Power are in the Physical domain. Moreover most respins are because of functional bugs. Methodology is progressing towards more detachment and Physical design is handed off to third party consultants. This approach seems to be working especially for synchronous designs. Why a company would change it ?
Wen-Jei Ho July 2006, I relied on timing constrains to run STA. I ran 8 times a day for two weeks. Find critical path modified it, literally squeezed nse by nsec and finally made my PCI core to run my own PCI Core running at 66MHz in two different prototype boards.
August 2006, I received a phone call from Xilinx FAE told me that he got several customers having problem to run Xilinx PCI Core at 66Mhz and wondering if they could use my PCI core.
I know of at least one asic design team that doesn't do multicycle or false paths. They route every path as a single cycle path so that they are sure that it will work. You can do that when your chips are small and not cost sensitive but not on large designs where cost is a factor.
It's like running a mail room where you send everything Fed-ex so that you are sure that it gets there on time. When the volumes increase and you mailing costs goes through the roof then your boss will replace you with someone who knows how to sort mail based on required arrival times and spends the minimal resources to achieve that goal. That is why we go to all the trouble to create timing constraints.
Timing constraints are extremely important. Probably the only time you don't need to care about them is when you have a fully synchronous design without complex IO.
The big problem however, is that the EDA vendors haven't thought about the modularity. In RTL design, you want to reuse as much as possible, and keep a clean separation between modules. This works well enough for the HDL code, but when it comes to constraint files, it's always a cut'n'paste exercise for the top level designer. What I would like to see is name spaces and local constraints. For example, if you have an internal false path, that should just be inherited into the main constraints file. If you have ports in a sub module that should be connected directly to the FPGA pads, you should be able to write your pad constraints in the modules constraint file, and have the tools to resolve the paths. The top level should basically only be concerned about constraints between modules, and things that aren't constrained elsewhere
...because constraints capture the design intent not captured by RTL code!
Some experiences from our chip design projects.
<O</O Our SoC design consisted of IP/Subsystems. Some of these were designed in-house and some were purchased from 3<SUP>rd</SUP> party IP vendors. We also had our IP design teams and SoC integration teams in different geographies and time zones
<O</O We had to deal with many issues of incomplete, incorrect and inconsistent constraints, late in the implementation cycle ( during SoC implementation). We had to iterate with IP design teams multiple times. Ideally it would have been best if correct and complete constraints were captured along with RTL during IP creation stage. Constraints should be “handed-off’ to SoC implementation team with the same rigor that is applied to RTL code hand-off. It is too late to address timing constraints at netlist stage. After all, the design intent is captured not only in RTL code file but also in SDC/Tcl file !
<O</O With complete, coherent and consistent constraints across all IPs, SoC teams can then appropriately manage constraints from block-to-top or from top-to-block. Hence EDA tools should enable constraints generation/checking and propagation , during the RTL design phases of IP and SoC.
