Honored Contributor
Honored ContributorFor the sake of completeness, I wanted to add to this thread to show that achieving your targeted 700Mbp/s across 32 LVDS channels is possible in a CycloneIV and the technique for doing this is actually easier than first thought. One of the main issues is that the method for doing the timing analysis is not clearly spelled out in any Altera documentation.
My test design looked like this: https://www.alteraforum.com/forum/attachment.php?attachmentid=6993 The only MegaFunction you need to instantiate is an ALTLVDS_RX instance. Within this, Quartus will automatically create the PLL and other logic necessary to de-serialize the incoming data stream. I used a de-serialization factor of 8, which results in a 256-bit bus out the backend of the core and a reasonable 87.5MHz core clock. As mentioned by Rysc, the CycloneIV does not have dedicated hard Serializers / Deserializers (SERDES) in silicon – for this family, the SERDES logic is actually built out of the core fabric. This has the effect of changing the way timing analysis and constraints are performed on the design. The correct approach to be used for CycloneIV is actually to use no constraints on the input IO at all! It sounds counter-intuitive, so here’s the explanation. The CycloneIV Datasheet gives you a sampling window requirement for the receiver specifications (table 1-36). For the C6, C7, and C8/A7 speed grades, the sampling window is a fixed 400ps. You then work backward to determine your Receiver SKew Margin (RSKM); there will not be a skew margin spec in the datasheet since it just shows the required data valid window for the data to be captured correctly. RSKM can be calculated by hand using the equations and methodology shown in the Cyclone IV handbook at: http://www.altera.com/literature/hb/cyclone-iv/cyiv-51006.pdf#page=36 The main drawback with this approach is you cannot get an RSKM report from Quartus II when not using dedicated SERDES. Essentially, what Altera is saying, is that as long as you meet the 400pS minimum sampling window, the SERDES are “guaranteed to work by design”. In other words, you have to trust them. :D For your design: (i) The data window is 1.429ns for 700Mbs. The sampling window is 400ps, which means the external device can skew its data in relation to the clock by 1.429ns - 0.4 = 1.029ns, or +/- 514ps. This should be very achievable. (ii) You need to make sure the capture clock is properly selected to capture the data, e.g. if the external device sends its data edge aligned, you need to center-align the clock by shifting it 90 degrees (within the ALTLVDS_RX GUI). If they send it center-aligned, you don’t shift the clock. If it’s something different (unlikely), then you need to manually adjust the clock phase-shifts. (iii) No input timing constraints are entered; the whole analysis is done on paper. Nothing is reported in Quartus for this and TimeQuest will report the inputs as Unconstrained. You can get rid of these warnings by using a set_false_path constraint in TimeQuest. (iv) The only major thing you need from the external device data sheet is the skew between the clock and data together with edge-aligned or center-aligned. (They may spec their device differently, such as describing the Tsu/Th they can provide to the receiver, but you can work that back.) One other thing I should mention. There’s a bug in the MegaWizard for the ALTLVDS_RX core when trying to use input buses greater than 18-bits. The GUI simply won’t allow this to happen, so I went in and manually edited the main Wizard generated file and the associated symbol file to give them a 32-bit input and 256-bit output. Hopefully this all makes sense – not having to constrain the input IO actually makes things far easier, though there is a slight faith element involved. Test design attached
