Since you are running everything off of one clock, you should safe there. The timing tool will correct all setup and hold issues for that clock domain.
When you have more than one system clock, when-ever data crosses from one clock to the other clock, timing closure is very difficult for the tool, especially if the two clocks are asynchronous from each other. Let's say you have a 25.000 MHz clock and a 25.100 MHz clock. Any data crossing from one clock to the other can not be guaranteed to always meet setup/hold requirements of the register in the other domain, because the timing between the two registers is also skewed and walking from clock edge to clock edge.
When setup and hold is violated, a you don't really know what happens. Sometimes, you'll capture the data as expected, some times you'll miss the data, and sometimes you'll get into a state called metastability, that is neither a logic one or a logic zero for some period of time.
To avoid this, any data crossing between two clock domains should use special synchronizing logic to insure that the data is capture properly, at least with a high MTBF, so that the system will perform as expected. This is especially important when transferring a bus across a clock domain. You always want to hold the data in the source clock domain, synchronize a single bit of control data across the clock domain then use that signal to capture the bus in the target domain. This is basically what happens when you use the FIFO megawizard functions from Altera, but it can be done without a fifo as well.
But that's really a different discussion.. :)
As far as the speed numbers being a bit misleading, I agree, but since they can not know what your target design is, they use some basic model that gives them a high number. It's probably listed somewhere as a sub-note on the 437.5 MHz number on how they determined that speed.
It may be just a register to register transfer, or the maximum performance for a simple counter or some other minimalistic design.
Pete
Honored Contributor
