--- Quote Start ---
About timing constraints: Why do I have to set constraints? I thought that Quartus knows the constraints of the choosen device by itself as they are from Altera and they have all the constraints data for their devices?
--- Quote End ---
Quartus knows the actual timing of your design in the device (for example, it can run at up to 49.5 MHz). If you don't tell Quartus with timing constraints, though, it has no idea what the required timing is (it must be able to run at least as fast as 50.0 MHz). The difference between the actual timing and required timing is the margin, and you might have negative margin without knowing it if you don't have timing constraints. Even at a slow frequency like 50 MHz, you might have a path with many levels of logic that won't consistently run that fast if you don't tell Quartus to optimize for that requirement.
Without constraints you could look at the reported actual timing and manually compare that to the requirements, but you'd have to do that after every compile. With constraints, you get obvious red highlight in the GUI when something violates the timing requirements.
Rysc is completely correct that a design should have its timing fully constrained. It is proper design practice regardless of frequency. Even if the reported actual timing happens to meet your requirements and you don't mind manually verifying that, having the requirements in the Quartus project documents what those requirements are for someone maintaining the design later. Some of the timing requirements are independent of frequency. As Rysc mentioned, even a slow design with easy-to-meet setup requirements might have challenges with hold (this includes clock hold internal to the device, not just th at the input pins).
--- Quote Start ---
... why does it work (sends the constant data byte via the serial line) if compiled with Quartus 7.1 and why does it not work (but compiles correctly) under 4.2?!? As you can see, I do not demand much of the device with my design, but it does not work . . . . .
--- Quote End ---
Even with the synchronous part fully constrained with no timing violations, there could be something asynchronous in the design (perhaps unintentionally asynchronous) that will have different timing from compile to compile and potentially even more different timing from one Quartus version to another. For something asynchronous, the timing might happen to work sometimes but not other times.
Rysc mentioned recovery and removal. Doing that analysis will catch some asynchronous problems with resets and asynchronous loads. It might also have lots of timing violations for things where the design is set up such that the reported failing paths don't really matter (like a register for which it doesn't matter whether it comes out of reset at the same clock cycle that another register does).
The Design Assistant can find some problems with asynchronous design as well as other potential causes of your hardware failures. If you run that, do it in version 7.1 in case it has been improved since 4.2. You just want to run the best design rule checker you can. The design itself is independent of Quartus version, so you don't have to run Design Assistant with the same Quartus version that has hardware failures.
Honored Contributor
