From the Cyclone IV device handbook:
> When you use the VREF pin as a regular input or output, you can expect
> a reduced performance of toggle rate and tCO because of higher pin
> capacitance.
Previously, we had set all HDMI_TX pins to fast output, but doing so
produces some worrying timing violations which were masked over by
relaxation of the SDC constraints. With fast output enabled, actually
fixing the timing constraints would require substantial RTL
optimization.
Instead, by only setting fast output on the VREF pins, I'm able to avoid
the glitching that would occur without any fast output pins when
displaying high clock rate line3x output, while also allowing fitter
enough flexibility to avoid timing violations.
In addition, this commit restores the previously relaxed HDMI_TX timing
constraints to those documented in the IT6613 datasheet.
Quartus calculates fmax (the theoretical maximum clock rate) based on
the entirety of the logic between registers. In the case of the pclk_*
lines, this includes some invalid paths which cross between the
3x <-> 2x and 5x <-> 4x clock domains. This is because these clocks
share output pins from the PLL, but the PLL is configured to output only
one of these clocks at a time, and the correct output from the logic is
selected via a multiplexer. Therefore these paths cannot co-occur.
This has the effect of increasing the calculated fmax of these paths to:
pclk_3x: 107.98 MHz -> 132.52 MHz
pclk_5x: 162.23 MHz -> 170.33 MHz
* replace all clock muxes with a single cycloneive_clkctrl to minimize skew
* use a single dynamically configured PLL to comply with cycloneive_clkctrl
Russell Harmon
Russell Harmon
marqs
paulb-nl