Forum Discussion

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

Stratix IV Device Feature Question - Transcievers

Application Hi Speed Data Acq Subsystem. Incoming data consists of twenty-five independent acq assemblies streaming data via one high speed serial channel each to one Stratix IV device (one differential pair). That interface is flexible, but would probably use a canned protocol such as Serial RapidIO as the acq assemblies will need a FPGA also.

Data out ot the Stratix IV part via one 4 lane PCIe V2 to CPU. The twenty-five devices would be periodically bursting data at roughly 3 Gbps to the Stratix IV device. My question is regarding device selection and my confusion on the table of device features. Looks like a minimum transciever requirement could be handled by a EP4SGX290 F1932?

Thanks

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Application Hi Speed Data Acq Subsystem. Incoming data consists of twenty-five independent acq assemblies streaming data via one high speed serial channel each to one Stratix IV device (one differential pair). That interface is flexible, but would probably use a canned protocol such as Serial RapidIO as the acq assemblies will need a FPGA also.

    --- Quote End ---

    Will these separate systems use a common transceiver reference clock? If so, then the transceiver lane synchronization would be eased (there would be no need for idle code insertion/deletion for clock rate matching over the links).

    --- Quote Start ---

    Data out ot the Stratix IV part via one 4 lane PCIe V2 to CPU. The twenty-five devices would be periodically bursting data at roughly 3 Gbps to the Stratix IV device. My question is regarding device selection and my confusion on the table of device features. Looks like a minimum transciever requirement could be handled by a EP4SGX290 F1932?

    --- Quote End ---

    So you need 25 transceiver lanes for the data acquisition, and a x4 PCIe link.

    The transceiver banks on the Stratix IV come in blocks of four + two CMU units. The CMU units can also be configured as transceivers, but they don't have the full compliment of features. If they do work ok for you, then you need 25/6 ~ 5 transceiver blocks for the DAQ interface. In that case, you could use 5 x 4 = 20 true transceivers plus 5 CMU blocks configured as transceivers, and you'd have REFCLK pins left over for the reference clock inputs (you can also use global clock inputs for the reference clocks, but the jitter spec is supposedly lower).

    A Stratix IV device with 6 transceiver blocks, with one of those having a hard-IP PCIe block should be sufficient.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    "Will these separate systems use a common transceiver reference clock?"

    They would be common frequency, but not a single source.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    "Will these separate systems use a common transceiver reference clock?"

    They would be common frequency, but not a single source.

    --- Quote End ---

    Ok.

    I'm not sure if you have used transceivers before, so I'll add a word of caution. The receiver PLLs will need to lock to a local reference clock (lock-to-reference, or LTR mode), and then when the received data has enough transitions, it can lock-to-data (LTD). The reference oscillators used at each end of the link need to be 'the same' frequency, within some specified frequency tolerance (specified in the Stratix IV handbook somewhere). You'll want to make sure your oscillators meet that requirement. In the link tests I've been doing, I've been using a common reference, so I can't comment on what you need for your mode of operation.

    You mentioned that your data will be 'bursty', so there should be no issue with the receiver-end of the link being overrun by a transmitter-end sending too much data.

    Cheers,

    Dave