Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

FPP Configuration Timing: Data stability requirement when DCLK-to-DATA[] ratio > 1

VC-52007 2016.06.10 Figure 7-3 shows the FPP Configuration timing for a Cyclone V when DCLK-to-DATA[] Ratio (r) is > 1.

Question: Is it really a requirement that the data pins remain remain absolutely stable for the tDH period indicated (datasheet specifies tDH(min) = (N-1)/fDCLK)? It is conceivable that the data really is clocked into the device on DCLK period 1 and that the additional r-1 padded clocks are only required for internal decompression / decrypting stages, irrespective of the data. would it be allowable to implement r>1 using the r=1 timing shown in figure 7-2 but (indentically) repeating data[] r times? Assuming that DATA[] is only clocked into the device on the rising edge of DCLK, this should be OK, even if the FPGA inspects the data on any rising DCLK edge between 1..r.

Any opinions would be appreciated.

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    I'm not sure I understand your description...

    --- Quote Start ---

    Would it be allowable to implement r>1 using the r=1 timing shown in Figure 7-2 but (indentically) repeating DATA[] r times?

    --- Quote End ---

    Isn't the net result the same as holding the data for the required r>1 tDH duration? If you're repeating the same data r times isn't the data static?

    If you're concerned about glitches occurring on the data then providing the glitches are "away from" (a loose phrase, I know) the rising edge of DCLK and stable again prior to the next rising edge (considering tDSU) I'd expect all to be well.

    --- Quote Start ---

    Assuming that DATA[] is only clocked into the device on the rising edge of DCLK

    --- Quote End ---

    I'm sure this will be the case. However, by requiring the data to be 'static' for the period specified, the device is clearly 'reserving the right' to sample or re-sample the pins on any rising edge of DCLK.

    Cheers,

    Alex
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hello Alex,

    Correct - we are concerned about data glitches between rising edges of DCLK: Each rising edge of DCLK would sample idential DATA[] for each DCLK 1..r (with setup and hold times conforming to Figure 7-2), however, the falling edges would not necessarily sample identical DATA[].

    Your suspicion that this should work agrees with ours - we were just hoping that this could be confirmed in a more 'official' way in order for us to finalise our H/W design (which currently uses this method as the primary configuration mechanism) with more confidence.

    Thanks,

    Bernhard