[hpsdr] Angelia_v3.0 (FULLY CONSTRAINED)

[Joe Martin K5SO]

Hi Michael, 

While the Altera links that Ken posted for you certainly cover the formal meaning of “constraints”, and I suppose I could leave it at that, when I was trying to learn to use the TimeQuest utility in the Quartus II program none of the official Altera documents proved very helpful to me in trying to understand what was really going on.  Therefore, perhaps my layman’s explanation might be somewhat more helpful to you to gain a better feel for the concept of “constraints".  

To understand constraints it is first necessary to realize that creating a firmware design for an FPGA actually consists of two very important and distinctly different tasks, namely:  

1) writing the Verilog code to logically perform the functions you wish to perform in the FPGA, from which the Quartus II compiler will try to convert your high-level ogic descriptions into low-level gates/registers/etc that reside in the FPGA to do the intended functions and the compiler/fitter will attempt to figure out where to “place and fit” the design into the FPGA device anld it automatically will figure out the required internal routing for the necessary interconnections to achieve optimum performance of your logic design, and 

2) ensure that the actual timing for all of the data transfer and clock transitions (literally thousands of them!) will work given the external and internal signal path delays that exist for the physical configuration that the fitter has come up with to put into the FPGA.  

In order for the compiler to do its job properly you, as the firmware designer, must tell the compiler what clocks (internal and external to the FPGA) exist and what IO ports and IO paths you are planning to use with the FPGA.  This information takes the form of “constraints”, which are simply one-line descriptions of each clock, IO port, or IO path in a “constraint” file, the .sdc file, for a firmware design.  The compiler and TimeQuest utility both use the .sdc constraint file to analyze and optimize the overall design.  If some clocks or IO paths are not described in the constraint file the TimeQuest wizard simply ignores them and you never obtain any feedback from the wizard as to whether those clocks/ports/paths actually meet the required timing required for your intended tasks or not.  

“Fully constraining” a firmware design properly is trickier than you might at first think because if you make a mistake in describing any clock, port, or path in the constraint file the compiler and TimeQuest analyzer will be working on the constraints that you actually provide as opposed to constraints that accurately describe your hardware.  Futher, there are literally several dozen “clocks” in in given firmeare design and literally hundreds of IO ports and IO paths that are involved, each of which in principle needs a “constraint” description, particularly in the case of “failing” paths.  If paths don’t fail (and many don’t even though they are unconstrained) then there is no adverse effect to not having a constraint for them.  

Our earlier firmware designs constrained only the clocks, signals internal to those clock domains and signals between clock domains, with no constraints on the IO ports or IO paths.  This worked okay for most things but as our firmware designs became more and more complex we began to experience problems that, I think, were associated with (unconstrained) IO ports/paths that were simply not being considered by the compiler nor the TimeQuest analyzer.  Only recently have I learned enough about constraints and the TimeQuest utility to be able to properly and fully constrain things, evaluate whether any paths are failing to meet the required timing conditions those data transfers, and, if necessary, determine how much delay is required on both the “launching” edge of a data transfer and the “latching” edge of a receiving transfer to achieve acceptable timing for the transfer, and how to actually use the constraint file to force those particular delays to be used by the compiler and the TimeQuest analyzer in the final design.  

That’s the short of it.  Hope I didn’t confuse the issue for you or others and that my description is sufficiently accurate to be of help in your understanding.  

73, Joe K5SO


On Mar 7, 2014, at 8:43 AM, Owen, Michael wrote:

> Dear Joe -
> 
> Could you briefly describe what "fully constrained" means?
> 
> Thanks-
> W9IP


 1394213100.0