Using the High Speed PMODs for Single-Ended Signals on the Cora Z7-10

[RyanW]

Hi, I'm trying to use the PMODs on the Cora Z7-10 to accept high-speed single ended signals from another board I am making.

In the reference manual for this device it says:

Quote

If pins on this port are used as single-ended signals, coupled pairs may exhibit crosstalk. In applications where this is a concern, one of the signals should be grounded (drive it low from the FPGA) and use its pair for the signal-ended signal.

So my question is in regards to proper grounding here. If I have a pair JA1_P and JA1_N and want to use JA1_P as the single-ended input. It says I should drive JA1_N low on in the FPGA fabric, but do I also need to connect the output of that to ground (it kind of seems like I should)? I'm perhaps a little worried about ground spikes, so if I do, should I put a series resistor in with it? Will this affect the single-ended speed potential? My data rate is ~500Mbps on each line.

[zygot]

In general the advice that your refer to is correct... assuming that the _p/_n pairs are routed out on the PCB as true differential pairs. In this case coupling is a desirable feature of differential signalling. I don't have your board but the many Digilent boards that I do have show no evidence of having the signal traces being routed as differential. I've used the differential PMODs on the Nexys Video, Genesys2, Genesys, Zedboard at 50 mbsp for single-ended signalling without noticeable cross-talk data corruption. I have taken advantage of the 10 mil _p/_n length matching in those designs. 500 Mbps is another animal, especially for single-ended signals.

First of all, did you check the ZYNQ datasheet for your device and speed grade to confirm that the FPGA can deal with such data frequencies? Even if the clocking resources can deal with such rates ( 500 MHz is near the top end for low speed devices ) internally that doesn't mean that you are guaranteed to close timing on a real world design... especially using an external signal toggling at 0.5 GHz. But that's only half the battle. You won't likely be able to create a transmission line suitable for such a signal as any terminate will be situated in a less than optimal location and you have no control over signal integrity characteristics over the whole signal path. 500 Mhz is pushing the capabilities of the PMOD headers alone; then add other factors and you are in trouble quickly. Even with connectors designed for high-speed signalling like FMC and having internal termination for supported IOSTANDARD differential signals ( your board doesn't support this ) you are pushing your luck.

Even if you manage to get a usable signal into your FPGA how are you going ot use it? You aren't going to over-sample a 500 Mbps signal for asynchronous operation so this means that you need a clock capable pin in your interface so that your add-on board can implement a source synchronous interface. Digilent doesn't specify maximum length differential between _p/_n pairs for its boards ( but they will provide that information if you ask )

Before rowing your boat off shore it's wise to check for leaks.. that is do you due diligence before making decisions that can't be unmade.

As to connecting FPGA pins that are connected to true differential signals; when you drive the _n pin to ground in your design this happens inside of your FPGA. This prevents cross-talk between single-ended signals on differential pair pins but does nothing to assist with a design that involves connecting an external board. Unfortunately, this technique halves the number of available GPIO on a board that's already been set in stone. Edited June 10, 2022 by zygot

[zygot]

Once your signals  get into the microwave part of the spectrum the analysis for connecting them between devices on a PCB or devices on different PCBs changes into a substantially different beast than for lower frequencies. It is an interesting subject, as you've found out. Back in the days of ECL/PECL there were a lot more players in logic vendor space.. as well as good application notes for implementing good transmission lines. The consolidation in the semiconductor field is not going to work out well for anyone in the long run. I think that having 2 behemoths own 90%  of the programmable market is even worse... especially when those companies also own a bulk of the PC chip market... depressing. As some of us have learned recently JIT is great, for some companies, when everything in the world is normal and threat to social order when there's a global crisis. Going FAB-less may sound great today, when you make the committment.. not so good tomorrow when you can't buy FAB resources anywhere. ARRGH!

A while back I did a board-board interface using the MAX9122/MAX9123 using CAT7 cable for use with the "high-speed" PMODs. At least the receivers have integrated termination and the footprints are easy to work with. I didn't try anything like 500 Mbps/channel. Now there are very few logic component vendors ( ADI has gobbled up most of the old ones ) and fewer design options. It's one way to overcome the stupid mistakes ( or perhaps purposeful since Digilent has never corrected them ) of those *** "high-speed PMODs though... if your PMODs have at least one clock-capable pin. 

You might find that the limited PL resources in the XC7Z010-1CL coupled with a limited DDR performance isn't really the platform that you want to struggle with for your project. Unfortunately, this is a really bad time to buy cheap FPGA boards, or devices, or well... anything. If you can find it the price is double or quadruple what it should be and that's from nor so reputable sources making the investment extra dubious. Well, we gotta do with what we got when we need to get things done...

The Mimas A7 might be a better platform. It comes with 3.3V supplied to the IO Banks connected to the headers but you can turn that into 2.5V with just one resistor change. I've done that and it works. Don't know if you can buy any at any price currently. FMC mezzanine card PCBs are not trivial to do but might be a better option. Paired with a Nexys Video or better yet Genesys2 your interface would be a lot cleaner and straight-forward as you can use LVDS_25 or lower and internal termination. Working in your favor is the IDELAY feature that will allow you to compensate for mismatched pairs of differential signals in wider busses. Do understand the material in the Series7 clocking reference manual and any relevant information in the SelectIO reference manual as you plan out such a board... if that's an option.  Perhaps you can trade in your dinghy for a more sea-worthy vessel.

The Intel/Altera ( shouldn't these marriages end up with hyphenated names? ) space is kinder to the kind of projects that you want but alas the low end parts that the free versin of the tools support are hard to come by, as are the development boards sporting them. A year ago you could have purchased some decent sized MAX10 devices at a reasonable cost and created your own FPGA board with an interface to your image sensor. I have a couple of MAX10 project on hold because distributors claim no knowledge of such a device now.

Hey, I've spent the last 30 years trying to make programmable logic development boards, purposefully designed to have limited capability and having unnecessary design errors, that I can afford ( a few that I couldn't ) perform feats that they were designed not to do but that I needed to get done. Rube Goldberging isn't pretty..  but if it gets the job done, pretty isn't terribly important. Almost always starting off with a platform that allow you to express your design intentions ends up saving time and money, even when the initial cost iis above your budget.

Thanks for the story... been there... many times.

Edited June 11, 2022 by zygot

[zygot]

I wasn't trying to 'upsell' you. I've rowed many a dingy into hostile waters and have come to the conclusion that if a project is worth doing wasting time trying to overcome design limitations on the wrong platform just isn't worth the hassle.

I don't think that you'll have trouble figuring out your plan B.

I do encourage you to take advantage of one thing that Vivado does offer; that is you can create a design for any board that exists and see how the resource match up to your project requirements. You can't generate a bitstream for the Genesys2 without a device license or the full-fat ( high-priced ) tool version but you don't have to in order to prototype an idea and see hwo it might work out on a platform that you might consider splurging on. If you do the HDL design flow you can simulate everything. Creating good simulation models for external hardware is generally a iterative process but you can still learn a lot by simulating even a crude approximation of your external hardware. All it takes is time. If you know what you are doing most of the work will be an investment in the final project effort. Seem to me that you know what you are doing; even better know what to do to get to where you know how to do something that you've never done before.

[RyanW]

Thank you for the response Zygot, and yes I have a bit of pickle here. I understand that there are tons of problems to be solved in this design. I may be hitting this problem with the wrong hammer.
 

The overall goal is to deserialize data from the image sensor I have and collect the data into the onboard DDR memory. I have 4 LVDS channels of data running at 462Mbps each and a LVDS pixel clock that runs at 66MHz. Its a 1:7 deserialization. The initial plan was to use the ISERDES module on the inputs with the LVDS lines, but due to the bank voltage being 3.3V, I would need to terminate it with a 100 Ohm resistor across the lines, which I can't do with the dev board.

I had looked into XAPP585 (LVDS Source Synchronous 7:1 Serialization and Deserialization Using Clock Multiplication Application Note) a while back and for Artix-7 SDR designs, it would seems as if I'd be able to drive it 464Mbps, which I believe is due to the global clock buffer only being able to handle 464Mhz. It also seemed like it could potentially go higher if I didn't drive it through a global clock buffer to around 600Mbps.

The PMODS are supposedly differentially routed with 100 Ohm impedance (+/- 10%) as stated in the reference manual Digilent gave. I kind of assumed they were all trace matched to each other, but it could be they're only trace matched for the individual pair.I was hoping they could potentially get high enough speeds to accommodate what I need. They also have a single MRCC pair that I was planning on driving the clock line into. I would have preferred to use it for the direct LVDS implementation to help mitigate some of the signal integrity issues single-ended would face on the board. But yeah, I would need a termination resistor for this bank voltage. For LVDS inputs, this FPGA should be able to handle LVDS on a 3.3V, but it does require external termination. I found this in a chart Xilinx put out on their forums here (https://support.xilinx.com/s/article/43989?language=en_US).
 

So the next factor I wanted to try, and I liked this option the best, was using a TI LVDS to LVTTL IC like the DS90CR288A, but they are all out of stock until 5/2023. Otherwise it would have let me deserialize right on the chip for 4channel with a common pixel clock into 28 single-ended bits + a 66MHz single ended clock. And I felt that would be way more manageable. There was some other chips that I could get like the DS90CR218A, which actually has plenty of stock. But it only has 3 LVDS input channels + a clock, and I wasn't sure splitting the clock signal between two chips for a data stream like this was a good idea. I recently found some literature talking about bifurcated termination where once it splits, the impedance goes to 2Z and then terminate 2Z at both chips. But I am not sure if that's such a good idea anyhow, especially considering all the data needs to be aligned with each other.
 

So this is how I got here. The current plan is to use something like a SN65LVDT352PW which just shifts the level from LVDS to single ended LVTTL with a max switching of somewhere around 500Mbps. I was making an interim board that plugs directly into the sensors outputs and the plugs directly into the pmods with just the level shifter chips on board, so I could keep the lines short enough from sensor to chips and from chips to FPGA. I've been having fun learning about making controlled impedance lines for what its worth. This was not my favorite option, but its the option I have right now.

I suppose getting a different FPGA dev board might be what I really need to do, but this is hand I'm playing currently. I've checked for a lot leaks, but I'm still fearful my boat is going to sink anyways. This is all pretty new territory for me. The fastest signals I've ever dealt with before were definitely less than 10MHz, so I've just multiplied that by 50.

Writing this is at least a good recap to justify things to myself at least. I still think it might be possible, but what scares me the most is I will have no way to verify what the signals even look like, like I;ve always been able to do in the past. My oscilloscope is a measly 1G Sa/s 200MHz bandwidth scope, so It's even hard to even see the pixel clock on it.


edit: I thought I would include the board I was making to kind of show the idea. LVDS goes in the left and LVTTL goes out the right. It just plugs right into both boards without the need for cables. It's a bit whack right now and nowhere near done, but that's the concept anyways. The impedance is supposedly right for a JLCPCB 4 layer stackup. If I went with the LVDS to 28 bits out, I would make a shield-like implementation for the Cora Z7-10 that also plugs directly into the sensor board.

Edited June 10, 2022 by RyanW

[RyanW]

Zygot, I've been thinking about this response this week. And I think the best option here is like you said

On 6/10/2022 at 7:52 PM, zygot said:

Perhaps you can trade in your dinghy for a more sea-worthy vessel.

So I'll be trying out a couple different solutions. I still like direct LVDS input the best out of the options so I will be getting a board which can more cleanly do this.