JTAG configuration over fiber link

[Altera_Forum]

We are deploying a Cyclone III FPGA in a remote location, connected to the infrastructure by a 30m long duplex optical fiber pair. TDI, TCK, TMS are sent to the remote FPGA, TDO comes back on the return leg. 

 The round trip transit time is ˜300ns. I would like to configure at 20 MHz, but various steps in the programming scenario require TDO information (verify, for example). The distributed software (jrunner, JAM player) seems not to have any awareness of significant delays in the return path.  The distribution manages to figure out how many devices are on the chain, but not how much external delay there is...  Has anyone made a modified version of the software which calculates the required delay and uses it in handling the incoming TDO bitstream?

[Altera_Forum]

--- Quote Start ---  The distribution manages to figure out how many devices are on the chain, but not how much external delay there is..  --- Quote End ---   Yes. JTAG is designed to work up to 0.5 clock cycle delay. Could be possibly extended to 1 cycle by adding a register that's clocked on the other edge, but not more.  To compensate for a multiple clock cycle delay, a synchronous design with a fixed clock frequency is needed, but it's sensitive to delay skew. A clear solution would be to send a Rx clock back with TDO.

[Altera_Forum]

--- Quote Start ---  Yes. JTAG is designed to work up to 0.5 clock cycle delay. Could be possibly extended to 1 cycle by adding a register that's clocked on the other edge, but not more.  To compensate for a multiple clock cycle delay, a synchronous design with a fixed clock frequency is needed, but it's sensitive to delay skew. A clear solution would be to send a Rx clock back with TDO.  --- Quote End ---    Unfortunately, there are no free bits in the return direction on the (serialized) payload. I know what needs to be done: a recognizable TDI pattern has to be sent [once] which allows the software to calculate the number of clocks before the pattern appears on the return line.  Once that is known, this delay can be inserted before any attempt to deal with the returning TDO bitstream following any TDI input.  I had hoped that someone might have already done this ...

[Altera_Forum]

Basically, the initially chain identification just does this: sending a recognizable pattern. But as you already stated, it's unaware of logic delays, only counting a register length. To compensate for a register delay, two prerequisites have to be met: 

- the JTAG TCK timing must be fully under your control, which is possible with e.g. an embedded JAM player but would be a problem with Quartus JTAG tools - the JTAG SERDES must use an synchronous clock and oversample the input data. Practically, a CPLD with a byte parallel interface to your embedded JTAG software could perform this task.

[Altera_Forum]

--- Quote Start ---  Basically, the initially chain identification just does this: sending a recognizable pattern. But as you already stated, it's unaware of logic delays, only counting a register length. To compensate for a register delay, two prerequisites have to be met: - the JTAG TCK timing must be fully under your control, which is possible with e.g. an embedded JAM player but would be a problem with Quartus JTAG tools - the JTAG SERDES must use an synchronous clock and oversample the input data. Practically, a CPLD with a byte parallel interface to your embedded JTAG software could perform this task.  --- Quote End ---    Thanks for the reply. We will be using an embedded JAM player -- probably implemented in an FPGA, so the TCK timing is under control. The SERDES clock is synchronous with the TCK, and on the return, the SERDES uses the clock recovered from the downlink deserializer.  The only thing that is missing is the revised code to support it -- I had hoped not to have to reinvent the wheel if it had already been done. :rolleyes:

[Altera_Forum]

--- Quote Start ---   I had hoped not to have to reinvent the wheel if it had already been done.  --- Quote End ---  I fear, the problem is somewhat special. JTAG speed of FPGA is basically limited. You rarely have interfaces with multicycle delay.