M
Mike Field
Guest
Hi,
My DisplayPort project has hit a speed bump - so close yet so far! Is there anybody who knows DP and can can help me review things and bet me back on track?
The AUX channel is up and running, EDID read, channel config works fine - at the moment I'm only bringing up one channel.
Clock recovery, swing negotiation, pre-emphasis negotiation, symbol alignment and lane alignment is all fine (verified though reading status registers at 0x0020?).
Once link is established, the idle pattern is sent for at least 64k cycles, and then a clean switch over to the test 800x600 @ 60Hz stream. Monitor reports "No signal", but the high link stays up until monitor powers itself down (I'm polling the status registers every 500ms)..
* As per spec 512 BS symbols is being replaced by a SR symbol.
* Main stream attributes are being sent during vertical blanking period.
* Tried with both scrambler enabled and disabled (with the corresponding register setting on sink)- just in case there is an error in the scrambler too.
* Verified 8b/10b coding using decoder from OpenCores, and by monitoring running disparity in simulation.
* VB-ID, Mvid and Maud are being sent four times per BS symbol (as needed for a single lane).
* BS (with bit 0 set in the VB-ID) are being sent during the vertical blanking interval, and on the last line of data. No BE symbols are being sent during the vertical blank.
I encode and send two symbols at a time (design is clocked at 135 MHz), and suspect that the ordering over the physical layer could be an issue. I have verified that the bits are going out in the order expected (if I swap the LSB/MSB order the training pattern it fails). I have also tried swapping the order of symbols within the pairs, but with no success.
So it seems to me that the sink is not able to reconstruct the pixel clock and is giving up.
I'm using an 800x600@60 Hz, 24 bpp test pattern as the 40MHz pixel clock (120M symbols per second) works in well with a 54-symbol TU, and each TU holding 8 pixels worth of data.
* M value is 8
* N value is 54
* Pixel clock is 8 / 54 * 270M Hz = 40 MHz
* MISC0 is set to indicate a a synchronous clock.
* The Hstart and Vstart are the sums of the H & V sync width and back porch..
Because it all divides nicely I can build a test stream from a handful of TU-sized blocks, and believe I am able to set Mvid[7:0] to be a constant 0x04 following every BS symbol, just so it is different from Mvid during the idle pattern.
I've looked at my simulations against random byte-level traces found on the interweb (e.g. http://www.futureplus.com/download/presentation/dp_anal_at_la.pdf) and have nothing unexplained, except why in the pdf the sync width is showing as 16390, where the raw data (0x8006) indicate 6, with a active low pulse, which is correct for 1024x768.
What would be really helpful would be a short trace of a few known bytes (maybe the MSA attributes?), so I can check that my bits on the wire matches in coding and ordering.
What would also be helpful would be if somebody was able to look at a simulation of the test source (https://github.com/hamsternz/FPGA_DisplayPort/blob/master/src/test_source.vhd) and see if it makes sense as the main stream.
I've got no access to high speed test gear, so everything is being checked in simulation, and the Aux channel and status information (e.g. a blank signal reconstructed by looking for BS, SR and BE codewords going into the transceiver) is begin monitored by a Saleae,
Any advice or an extra pair of eyes would be much appreciated!
Mike
My DisplayPort project has hit a speed bump - so close yet so far! Is there anybody who knows DP and can can help me review things and bet me back on track?
The AUX channel is up and running, EDID read, channel config works fine - at the moment I'm only bringing up one channel.
Clock recovery, swing negotiation, pre-emphasis negotiation, symbol alignment and lane alignment is all fine (verified though reading status registers at 0x0020?).
Once link is established, the idle pattern is sent for at least 64k cycles, and then a clean switch over to the test 800x600 @ 60Hz stream. Monitor reports "No signal", but the high link stays up until monitor powers itself down (I'm polling the status registers every 500ms)..
* As per spec 512 BS symbols is being replaced by a SR symbol.
* Main stream attributes are being sent during vertical blanking period.
* Tried with both scrambler enabled and disabled (with the corresponding register setting on sink)- just in case there is an error in the scrambler too.
* Verified 8b/10b coding using decoder from OpenCores, and by monitoring running disparity in simulation.
* VB-ID, Mvid and Maud are being sent four times per BS symbol (as needed for a single lane).
* BS (with bit 0 set in the VB-ID) are being sent during the vertical blanking interval, and on the last line of data. No BE symbols are being sent during the vertical blank.
I encode and send two symbols at a time (design is clocked at 135 MHz), and suspect that the ordering over the physical layer could be an issue. I have verified that the bits are going out in the order expected (if I swap the LSB/MSB order the training pattern it fails). I have also tried swapping the order of symbols within the pairs, but with no success.
So it seems to me that the sink is not able to reconstruct the pixel clock and is giving up.
I'm using an 800x600@60 Hz, 24 bpp test pattern as the 40MHz pixel clock (120M symbols per second) works in well with a 54-symbol TU, and each TU holding 8 pixels worth of data.
* M value is 8
* N value is 54
* Pixel clock is 8 / 54 * 270M Hz = 40 MHz
* MISC0 is set to indicate a a synchronous clock.
* The Hstart and Vstart are the sums of the H & V sync width and back porch..
Because it all divides nicely I can build a test stream from a handful of TU-sized blocks, and believe I am able to set Mvid[7:0] to be a constant 0x04 following every BS symbol, just so it is different from Mvid during the idle pattern.
I've looked at my simulations against random byte-level traces found on the interweb (e.g. http://www.futureplus.com/download/presentation/dp_anal_at_la.pdf) and have nothing unexplained, except why in the pdf the sync width is showing as 16390, where the raw data (0x8006) indicate 6, with a active low pulse, which is correct for 1024x768.
What would be really helpful would be a short trace of a few known bytes (maybe the MSA attributes?), so I can check that my bits on the wire matches in coding and ordering.
What would also be helpful would be if somebody was able to look at a simulation of the test source (https://github.com/hamsternz/FPGA_DisplayPort/blob/master/src/test_source.vhd) and see if it makes sense as the main stream.
I've got no access to high speed test gear, so everything is being checked in simulation, and the Aux channel and status information (e.g. a blank signal reconstructed by looking for BS, SR and BE codewords going into the transceiver) is begin monitored by a Saleae,
Any advice or an extra pair of eyes would be much appreciated!
Mike