In applications engineering we are often asked, “Why is my simple FPGA design not routing?” or “Why does my CPLD design have such a large timing score?” Sometimes we’ll also hear “PAR is taking forever, and then it fails!” In many cases, the solution is embarrassingly simple: “Create a timing constraint!”
Any fan of police shows can probably recite the rights that the police read to the suspect (known in America as “Miranda Rights”), which include “You have the right to an attorney. If you cannot afford an attorney, one will be appointed for you.” FPGA designers should be aware of similar advice: “You have the right to use a timing constraint. If you don’t provide one, a timing constraint will be provided for you.” With lawyers, sometimes you get what you pay for. So it is with FPGA Place-and-Route (PAR) software – in most situations it is better to provide your own reasonable constraint.
Users of large CPLDs and small FPGAs will sometimes cram lots of simple logic into the limited space available with no clocking constraint specification. The assumption is that because the clocking requirement is so slow (e.g. 32 kHz,) no timing constraint should be necessary. These users make the presumption that the PAR engine simply will route the clocking network, albeit with a very inefficient and slow structure. As counter-intuitive as this seems, nothing could be further from the truth. Why? Read on….
PAR algorithms require a timing constraint. Without a user-defined timing requirement, the mapping process generates its own timing estimate and passes this to the PAR process. Your simple design suddenly must meet a court-ordered 30 Mhz constraint! To compound the problem, as your FPGA or CPLD resources near their capacity (e.g. 85 to 90% and higher), there are fewer and fewer logic tricks and routing channels available to alleviate the timing pressure. In the end, you’re stuck with a design that doesn’t meet timing or doesn’t complete PAR, simply because you (unwittingly) directed the tool to use a clock definition that was more aggressive than it needed to be.
Constraints (‘Preferences’ in Lattice lingo) are contained in Lattice Preference Files (.lpf). These text files can be edited with any simple text editor. In addition, Lattice Design software (ispLEVER and Diamond) provides GUI editors to simplify preference specification.
Get out of jail free! Add a single timing constraint to your design.
RSS Feed
Comments