Arty z7 Trace Delays

[Chris RF]

I'm planning to use nearly all of the Z7's pins to provide balanced outputs in a timing critical application.

Is there a report available for the trace lengths, delays and impedances for each FPGA trace to each associated header pin?

[zygot]

On 6/19/2023 at 6:17 AM, Chris RF said:

I'm planning to use nearly all of the Z7's pins to provide balanced outputs in a timing critical application.

Can you provide a bit more information to help understand what you are trying to accomplish?

How are you intending to compensate for PCB trace length mismatch for outputs?

I can't say for sure, but I suspect that all of the standard PMOD signals end up being auto-routed after all of the other nets have been placed; so there is likely a very wide variance in trace length. Also you need to address the series current limiting resistors in the standard PMOD IO traces.

Digilent has provided limited trace length reports for FMC and the -nonstandard  PMODs.

A platform more suited to your project requirements might be the best way forward, but it's not possible to provide any useful guidance with the information provided. "Timing critical application" suggests to me a way of connecting external things to your FPGA through well designed transmission lines, which would include the a consideration of the connectors as well as termination.

Edited June 20, 2023 by zygot

[Chris RF]

Hi Zygot,

If I can get the Z7's trace lengths then I will compensate for differences between P and N outputs of each pair via traces on the PCB that plugs onto the Z7. I don't care about time differences from pair to pair, as they will be compensated in the FPGA. Each pair will be turned into a single ended 50 ohm signal via a transformer, so I need the P and N to be well matched for clean transitions.

I need 16 balanced outputs (so 32 balanced output pins) and 2 balanced inputs (so four more balanced input pins).

I notice the series resistors put into some of the Z7 traces so they would need to be linked out which is admittedly painful.

One alternative is to lay out my own board similar to the Z7, but that is a big investment for what is likely to be around 5 that I need for now.

 

 

 

[zygot]

39 minutes ago, Chris RF said:

I don't care about time differences from pair to pair, as they will be compensated in the FPGA

I'm curious. You can get fine resolution delay for inputs using IDELAY. How do you propose doing compensation for your outputs?

In general, trying to simulate balanced (differential ) signalling with single-ended output buffers is a bad idea. All of your IO aren't even on the same IO bank. Do you have a good sense of how much delay variance internal routing can be for 32 pins? Have you worked out a rough timing budget for this? This discussion assumes that you don't care about pair-pair skew for your application.

Differential signalling is great when implemented properly and sent through high quality transmission lines. My sense is that you are being a bit overly optimistic. The problem with differential signalling is that there is a whole new way to achieve illegal logic states with 2 complementary signals. You can't fix bad data.

Personally, I'd find a platform more suited to such an application. If 16 true differential pin pairs with differential PCB routing and a suitable connector weren't available I'd consider using external single-ended to LVDS drivers. Maxim, I believe that they are now part of ADI, has some nice driver/receiver ICs for conversion between single-ended and differential signalling.

The Mimas-A7 has the kind of length matched IO that you want. The IO banks are all 3.3V Vccio, but you can change that to 2.5V or 1.8V by changing one resistor in the power supply design. I'm not recommending anything, but just trying to point out that looking around for hardware that suits the needs of a particular project is worth the effort. You can do a lot of work and end up with a less than desirable working platform. How much is your time worth?

Digilent sells a limited set of (really old) PMODs and FPGA boards that are designed to sell those products. Not all vendors in this market use that business model.

I really can't imagine what your application is, but transformer coupled logic is a whole other kettle of fish to chase around... But don't let me interfere. I'm just trying to flesh out ideas that I believe you need to consider.

Edited June 21, 2023 by zygot

[Chris RF]

Just on the IDELAY, it took me a while to figure out, but they can actually be inserted between fabric to fabric connections. Vivado seems to do a bad job with them though so I've had to lock their posititions to avoid routing failures. I'm not using them to simulate differential matching as you suggest, just to control delays from one pair to the next. It looks like Digilent won't supply trace length information for their boards and also no gerbers so my plan to compensate through extra trace lengths on my board will only be possible if I measure trace delays which seems like a bad idea.

I'll consider a single ended to LVDS converter because that would certainly make the problem go away. Initially I'm worried about the jittter performance of that route.

I have used the Z7 for another project so that's what I feel comfortable with. The CMODA7-35T looks like it might work, but I'll need another Arm dev board with ethernet and a command connection to the CMOD for that to work for me. I'll look at the Mimas-A7 as well.

Thanks for your thoughts! I appreciate it.

[zygot]

3 hours ago, Chris RF said:

Just on the IDELAY, it took me a while to figure out, but they can actually be inserted between fabric to fabric connections. Vivado seems to do a bad job with them though

IDELAY works fine. They are often required for even small bus widths at moderate clock rates, like 125 MHz DDR Ethernet PHY RGMII interfaces. You need to instantiate one IDELAYCTRL primitive clocked at (typically) 200 MHz plus one IDELAY2 primitive for each pin in your bus. If you had issues with Vivado then you were doing something wrong. IDELAY is good for fine delay control, up to about 1 ns or so. Trying to do this with logic is going to be tough. Even at 500 MHz you only get 2 ns granularity. Perhaps you know something that I don't know about FPGA design. Again, for 32 signals, from more than one IO bank you are going to have a hard time with place and route to give good control, even if you are willing to provide location constraints for your logic.

The single ground pin on the CMODs are going to be a problem driving 32 outputs much less 32 simultaneous outputs ( if that's your plan ).

I forgot to mention that the Mimas-A7 uses proprietary software for configuration, which was the first thing that I resolved. You can't use an ILA or VIO, or Vivado Hardware Manager with it. Fortunately, the board has a JTAG connector. Unfortunately, you have to make an adapter to make it work with the Digilent Hx JTAG cables ( I think that they still sell one version of these ). Their header is wired for a much more expensive Xilinx configuration cable.

The alternate way to do this is to make an adapter board that connect your FPGA platform to whatever you are working with. That way you can compensate length mismatches in copper. Sounds like a lot of work. If you are going to do you own adapter SYZYGY or FMC might be worth consideration. Digilent has provided length reports for those.

I'm not understanding your "_p/_n balanced pair" distinction from differential, in terms of connecting to external hardware. I don't see 16 n/p pairs of pins going to headers on your board.

A few more tips.

• read about recommendations for driving simultaneous outputs from the same IO bank in the Series 7 SelectIO user manual
• FPGA outputs are not really well suited for driving lots of high currents on lots of pins. Board design may limit this as well.
• FPGA outputs are not designed to drive reactive loads, particularly those with significant inductive kick-back. There are protection diodes but they are not there as a design resource.

I'm sure that there's a way to get your project implemented. There just aren't many (inexpensive) boards in the AMD/Xilinx sphere geared toward prototyping these kinds of projects. 

 

Edited June 22, 2023 by zygot