Cyclone V ALTLVDS_TX: MSB inversion and timing constraints

[Altera_Forum]

Hello everyone, 

 I'm designing a board with a Cyclone V driving a DAC running at 420MS/s using a parallel DDR interface. To achieve this datarate (840Mb/s per stream), there is an ALTLVDS_TX component with a serialization factor of 4, so that I can work with SDR signals at 210MHz internally. Achieving timing closure is still annoying enough, but should be possible. When checking the TimeQuest output, I found some automatically generated constraints which I don't really understand. In the document UG-MF9504 (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/ug_altlvds.pdf#65), there is a timing diagram (fig. 15 on p. 65) showing the three clock signals driving the SERDES. My serialization factor is 4 and not 10, but the relationships are the same: c0 is running at 840MHz, c1 at 210MHz with (in my case) 45° advanced phase, 25% duty cycle and c2 is 210Mhz with 50% duty cycle. Now, as far as I can tell, c1 is the enable signal to latch the input data into the internal registers. This happens every four cycles of the fast clock c0, so in my opinion, the constraint should be something like set_multicycle_path -setup -end 4 -to set_multicycle_path -hold -end 4 -to  But when checking the automatically generated constraints, I see a 3 there. This is also visible in the timing diagram of TimeQuest, the data is required to be stable after 3 cycles of c0. Why is that? I couldn't achieve timing closure this way, so I've overridden the constraint and, well, it works. But this obviously doesn't mean that it is also actually correct.  The other strange thing with this serializer is that I have to invert the MSB (the first serial bit per word) of each stream. This is not a problem to do as soon as one knows it, but what is the reason for this behaviour? I also wasn't able to find any statement about that in the documentation at least, but maybe I've just overlooked it. Is this an anomaly of my design, or is this usual and designers are just expected to know it?  Thanks!  Best regards, Philipp

[Altera_Forum]

your figures of sample rate, stream rate are not clear to me but anyway if you are sure of multicycle of 4 then setup mcp would be 4 and hold mcp would be 3. 

 Your timing case is that of DDR io output constraints. You need to check your DAC requirements and translate that to set_output_delay for Timequest. see examples in timequest resource centre at altera.com  Regarding msb inversion. Who asked to do that??? if just DAC behaves ok by experimenting on this bit then the possibility is your DAC supports offset binary. Conversion between 2's complement and offset binary is by inverting msb.

[Altera_Forum]

Hi kaz, 

 thanks for your response. The original constraint assigned by the MegaWizard for the SERDES was setup 3 and hold 3, is the hold multicycle supposed to be always one less than setup (for usual register-register transfers)? set_output_delay should not be necessary as far as I know, since I'm using dedicated hardware which reports a TCCS of 250ps, which is fine for my board and DAC.  Nobody asked me to invert the MSB, I figured it out when looking at the signals with a scope. I guess I wasn't clear about that: The inversion is for the first bit in every serial word, not the MSB of the DAC. So if my parallel input for one stream looks like 0101, the serial bits transmitted are actually 1101. This holds for every transmit LVDS pair. Strange enough, the receiver (ALTLVDS_RX) does not show this behaviour.  Regards, Philipp

[Altera_Forum]

--- Quote Start ---  Hi kaz, thanks for your response. The original constraint assigned by the MegaWizard for the SERDES was setup 3 and hold 3, is the hold multicycle supposed to be always one less than setup (for usual register-register transfers)?  --- Quote End ---    For a path where both registers are clocked by same clock, yes. This is purely an sdc definition.    --- Quote Start ---   set_output_delay should not be necessary as far as I know, since I'm using dedicated hardware which reports a TCCS of 250ps, which is fine for my board and DAC.   --- Quote End ---    I don't get it. Either fpga or DAC or both should be responsible for io timing. You wouldn't need sdc constraint for fpga only if DAC is taking responsibility of io timing. Some devices do have automated data/clk alignment but you need to check that.    --- Quote Start ---   Nobody asked me to invert the MSB, I figured it out when looking at the signals with a scope. I guess I wasn't clear about that: The inversion is for the first bit in every serial word, not the MSB of the DAC. So if my parallel input for one stream looks like 0101, the serial bits transmitted are actually 1101. This holds for every transmit LVDS pair. Strange enough, the receiver (ALTLVDS_RX) does not show this behaviour.   --- Quote End ---    This doesn't make any sense to me.

[Altera_Forum]

--- Quote Start ---    --- Quote Start ---  Hi kaz, thanks for your response. The original constraint assigned by the MegaWizard for the SERDES was setup 3 and hold 3, is the hold multicycle supposed to be always one less than setup (for usual register-register transfers)?  --- Quote End ---  For a path where both registers are clocked by same clock, yes. This is purely an sdc definition.  --- Quote End ---   Ah, thanks. Looks sensible.    --- Quote Start ---    --- Quote Start ---  set_output_delay should not be necessary as far as I know, since I'm using dedicated hardware which reports a TCCS of 250ps, which is fine for my board and DAC.  --- Quote End ---  I don't get it. Either fpga or DAC or both should be responsible for io timing. You wouldn't need sdc constraint for fpga only if DAC is taking responsibility of io timing. Some devices do have automated data/clk alignment but you need to check that.  --- Quote End ---   All data lines come from the same dedicated SERDES hardware. The clock is generated by another of those channels with a fixed pattern of 0101. TimeQuest reports a maximum skew (TCCS) between all those lines of 250ps, so the delay between any data line and the clock line is at most 250ps, which is fine for the DAC's setup/hold requirements (the clock is delayed in the DAC to get a positive hold time). Maybe I could add explicit constraints to compensate for some trace lengths, but at least at the moment this is not necessary.    --- Quote Start ---    --- Quote Start ---  Nobody asked me to invert the MSB, I figured it out when looking at the signals with a scope. I guess I wasn't clear about that: The inversion is for the first bit in every serial word, not the MSB of the DAC. So if my parallel input for one stream looks like 0101, the serial bits transmitted are actually 1101. This holds for every transmit LVDS pair. Strange enough, the receiver (ALTLVDS_RX) does not show this behaviour.  --- Quote End ---  This doesn't make any sense to me.  --- Quote End ---   Do you mean my answer or the described behaviour? The latter doesn't make any sense to me either, that's why I'm looking for an explanation.  Bye, Philipp

[Altera_Forum]

--- Quote Start ---   All data lines come from the same dedicated SERDES hardware. The clock is generated by another of those channels with a fixed pattern of 0101. TimeQuest reports a maximum skew (TCCS) between all those lines of 250ps, so the delay between any data line and the clock line is at most 250ps, which is fine for the DAC's setup/hold requirements (the clock is delayed in the DAC to get a positive hold time). Maybe I could add explicit constraints to compensate for some trace lengths, but at least at the moment this is not necessary.   --- Quote End ---    If DAC only has skew requirement then you still need to control that (from build to build) using set_output_delay with the required skew.    --- Quote Start ---   Do you mean my answer or the described behaviour? The latter doesn't make any sense to me either, that's why I'm looking for an explanation.   --- Quote End ---    The inversion. You are supposed to pass data as it is. Inverting first bit introduces error naturally. Inverting msb converts to offset binary. You haven't explained clearly why you think you need to invert it.

[Altera_Forum]

--- Quote Start ---  The inversion. You are supposed to pass data as it is. Inverting first bit introduces error naturally. Inverting msb converts to offset binary. You haven't explained clearly why you think you need to invert it.  --- Quote End ---    Sending 0101 and measuring (in hardware, with a scope) 1101 should be a fairly clear indication that something is wrong. That the design works fine when I manually invert the first bit of each stream in the parallel data also seems to be a reasonable indication that I'm not just dreaming that something is strange. That said, a simplified design does not show this behaviour in an RTL simulation. My attempt to also perform a timing simulation failed with "Warning (10905): Generated the EDA functional simulation files although EDA timing simulation option is chosen.", which probably means that this is not supported with my Quartus II license. I might download this simple design to some hardware and measure the signals when I get my hands on a fast scope again.  It's good anyway to know that this is not the supposed behaviour. Thanks for that.  Regards, Philipp

[Altera_Forum]

Ok, I compiled the simplified design and run it on some test hardware and there is no such strange effect, a bit pattern of 1100 generates a signal with 50% duty cycle as expected. I had to use other pins and a lower frequency than on the real design though, so it may not be completely representative. No idea what's wrong there. At least I know that I must look out for this in future designs, as it could save some debugging. 

 Bye, Philipp