Any way to get around "Transmitter ... exceeds the maximum allowed data rate ..."?
I have a board which has a 208 pin QFP Cyclone II (EPC2C5). There are 4 differentail pairs connected to a HDMI connector and 4 more pairs to a DVI-D connector. This is for experimentation with video generation.
I have ported some code which works on a competitors FPGA, and adjusted it to work with the available Megafunctions given by Altera/Intel. Specifically the competitors FPGA has a built in SERDES block, which I have re-implemented using the DDIO_OUT Megafunction. Now I realise that the megafunction is implemented using regular fabric rather than using a dedicated hardware block so is unlikely to be as fast as a dedicated piece of hardware and it's timing is compile/layout critical.
After figuring out that the data to the DDIO_OUT needed to be reversed I finally got video on my Dell monitor. This is running at 480p60, and both HDMI and DVI-D connectors are operational (good to know that I wired them up correctly!). I use a PLL to generate 25MHz and 125MHz for the DDIO_OUT which gives a data rate of 250Mbps.
For fun and experimentation I would like to try other video resolutions. The one I was particularly interested in is 720p60. I re-generated the PLL to generate 75MHz and 375MHz for a data rate of 750Mbps. During compilation I get the following message...
"Error (176058): The Transmitter driving I/O pin DVID_CH0P at data rate 750 Mbps exceeds the maximum allowed data rate of 550 Mbps"
It's an ERROR not a warning, so I can't even try it. Yes I understand it is there for good reason as the circuit may fail to operate at the higher speed, but I want to try it anyway. BTW, the competitors FPGA actually can be overclocked (above it's Mbps rating) to work at 1080p60. So yes it's a risk, but shouldn't blow the chip up!
Is there a way to workaround?
I have a 50MHz XTAL which goes to the PLL, whose two outputs (c1 and c2) connect directly to the DDIO_OUT block. I sort of remember when I generate the DDIO_OUT that I told it about the expected data rate.
So I tried to fool the compiler. I told it that the input clock (XTAL) was only 25MHz in the SDC file, however I was forced to re-implement the PLL (the original one was generated having been told it was getting a 50MHz input). When I downloaded and ran the "code" I got a picture which the Dell informed me was 720p40(!). Checking the slower PLL output (on a test pin) it was only 66MHz and not 75MHz. So a PLL designed for a 25MHz clock did not work correctly with a 50MHz clock. You might say that this is no surprise, but a PLL is actually just an input clock "multiplier", and this trick can work for some more flexible PLLs.
I don't know how the compiler figures out the data rate. I really want to try to lie about the clock frequencies going into the DDIO_OUT. I tried to add some internal clock definitions to the SDC but failed miserably. I just can't get my head around the syntax. Clearly the compiler is very clever(!) in that I tell it about the PLL input clock (from the SDC), and it then figures out the PLL output frequencies, it knows that the DDIO_OUT is driven from the PLL directly, and then from that calculates the data rate.
I've thought about having two PLLs which a mux on the output, controlled by an external pin, to try to fool the compiler, so it can't deduce the clock frequencies to the DDIO_OUT, but it seems horribly contrived. There must be a better way.
NOTE: I accept all responsibility for anything bad that happens when I overclock the DDIO_OUT by 20%! It's my own hardware design.
regards...
--migry