Jump to content

Differential PMOD Challenge


zygot

Recommended Posts

@neil,

My kit will look like an Arty connected to a Basys-3 with a double-PMod (12-pin) cable, 'cause it's what I've got.  Or rather ... it's what I will have.  I don't yet have the hardware to run any of these tests, although I'm hoping it will arrive sooner rather than later.

If you read this full thread, you'll find @zygot posted some software/rtl to define the challenge.  While I have looked at his work, I don't have his hardware.  As a result, I can't verify his work or repeat any of his tests or testbenches to create any results.  So ... I don't have any results.  It's not that I'm not sharing them, it's more that I don't have them.  Second, since I'm not getting paid for this work, it's not high on my priority list.  I'll make progress as I have the opportunity.  )

Of the comment I wrote above, I was sharing how I was going to approach this problem if/when I get the chance.

When do novices like you get to try?  Why not start by looking over the Xilinx libraries guide?  It's where I'll be starting, since it defines the ISERDESE2 and OSERDESE2 elements I'll be needing.  After that, the problem is fairly basic--one even worth a novice cutting his teeth on even.  :D

Dan

P.S.  My time right now is being consumed by my efforts to upgrade the ZipCPU processor I've been working on, so that it can handle 8-bit bytes instead of 32-bit bytes only.  This will make the processor more applicable to mainstream users.  I'm getting closer--the updated compiler and assembler are now working, and I can get enough of newilb and a simulator running to run a Hello World application.  I'm hoping to get it far enough along to play 4x4x4 tic-tac-toe, but I'm not there yet.

Link to comment
Share on other sites

Neil,

The Differential PMOD Challenge isn't really a project geared toward  "novices". Anyone following along might glean some good information though. The Nexys 4 DDR board is not suitable for connecting to ADC or DAC devices having differential LVDS data interfaces for a number of reasons. The most important is that the PMODs on your board have single-ended IO.... with 200 ohm series resistors for protection of the FPGA. Digilent does make that Genesys2 board with an HPC FMC connector that could connect to a FMC mezzanine board having ADC and or DAC devices. Analog Devices, Texas Instruments, and other vendors of conversion product often have development boards showcasing their conversion products. Be warned that this is NOT a project for "novices" without a large toy allowance. Analog Devices has excellent FPGA design and software support for embedded developers even though neither of those spheres represent their core business.

Link to comment
Share on other sites

D@n,

Against by better judgement I'll comment on your last post... even though I'm repeating myself.

The Basys 3 is not suitable for differential signalling for the same reasons that afflict the Nexys 4 DDR. For the third time your Arty board has 2  differential PMOD connectors and all you have to do is modify one of the project constraints files to assign the correct pins for your board. Once you have a cable assembly made up you are good to go and replicate any of the provided designs for yourself to get started. If you read even just the stuff that I wrote and understand it you should know this. I'm not sure where your purchased cables are coming from but I seriously doubt that they are suitable for reasons contained in the project information files; unless you are getting one of the project interface boards made. I suggest that anyone wanting to take the challenge replicate one of the provided designs so that they start from a known good starting point. This is always good practice and offers a "sanity check" if the weeds become too high to see where you are. Two Arty boards would certainly work; but if you can't succeed at walking along a straight line jumping on a balance beam and trying to doing back-flips might not be a great idea.

A problem with electrical engineering is that, unlike some pursuits,  knowing half of what details are pertinent to your endeavour and getting some of details fairly well addressed is very unlikely to produce satisfactory results. Of course, in order to know the right answers you have to ask the right questions.... and that often requires quite a bit of expertise. Even seasoned professionals, when faced with a particularly novel and difficult problems fail to ask the correct questions... or are prevented from doing so by a non-technically competent manager with an unrealistic agenda and wholly non-technical agenda and end up face to face with total failure.   

 

Link to comment
Share on other sites

@zygot,

Hmm ... thanks for reminding me.  Some things are best learned by doing, some by reading, I appreciate your looking out for me.

I really dislike the idea of using a board as both source and sink in a communications system.  It feels too much like cheating.  That leaves me with the option of trying to build a single-ended (not differential) PMod challenge.  Wonder how useful that might be ... perhaps if I ran both circuit boards from the same computer then they would share a common ground/reference ...

Dan

Link to comment
Share on other sites

D@n,

Yeah, Hamster made the same remark. As I pointed out to him, as long as the data source and data sink are clocked by unrelated clocks there's no "cheating". My designs all carefully isolate data source and data sink clock domains. Using two boards will definitely have  more issues to resolve but it does resolve this point beyond debate. Fortunately, the cost of two Arty boards is not extravagant. But I just reminded myself that my designs are for boards with and FMC connector and a mezzanine board with a programmable clock source. So, on Arty work will be a bit more complex than "just assigning pins" after all. (Didn't I already go over this? I guess that I've been away from it too long). You will have to find a second clock source not related to the external clock module. Perhaps you could find an connector pin that connects to an FPGA IO pin with P and MRCC in the label ( such as CKIO33) and connect this to an external clock module so that you can use a global clock input buffer ( N MRCC or N SRCC pins won't work ). The Ethernet PHY has a 25 MHz crystal and might source a 25 MHz clock if set up properly. ETH_RX_CLK is connected to a suitable FPGA pin for use as a clock input. You can then bring this into a PLL to generate a variety of clock rates for the data source. Also, a one Arty implementation will have a more limited range of variable data rates than the programmable clock solution requiring you to do more work in finding the highest one. Lastly, the user interface run by the Python code will have to change. Even with all of that in mind if I were to add an Arty design to the project I'd start with a one board design and once that was working move to a two board implementation before releasing it. That's my advice for what it's worth.

Link to comment
Share on other sites

Dan,

being a novice the Xilinx libraries guide is a bit confusing for me, but i'll stick with it - thanks for the link. All i've got at the moment is a coaxial output (ie single ended output) with a bandwidth 10s to 100's of MHz and i'd like to get this into a clocked comparator to act as a high-speed single bit-ADC (i'm only interested in zero crossings), clocking at as fast as it could go, then putting the single bit data stream to a differential output, and then into the FPGA. I really need differential to minimise pick-up. I know the spec on the Nexys 4 DDR board is not for high speed, but the idea would be to build, then test, just to see how fast this could go before errors rate becomes unacceptable. When i know the data rate speed limit, i can back off a bit on this, insert an anti-aliasing filter in analogue coax section and be comfortable this its running as fast as it can with no aliasing.

 

Zygot,

I've almost no budget, but do have this Nexys 4 DDR board. I was hoping to use two PMOD inputs to build a single differential input. I'd need to take care the cable input was differential and screened, but even though this board is not designed for differential PMOD, could it be kind of forced into differential operation? At the end of the day it is the bit error rate which will determine if it's acceptable. You suggest using the Arty board, as it has differential PMOD inputs, but can this take inputs at data rates of >= 100 Mbps? Perhaps another higher spec board?

Grateful of your help and suggestions.

neil

Link to comment
Share on other sites

Neil,

Oh boy... where to start.

I'll save you from the long version of the response that I feel obligated to provide.... so this is either your lucky or not so lucky day... depending on how you choose to view it.

Some Xilinx Series 7 IO bank pins can be used as differential IO pairs. They have reference names containing *_p and *_n. Only specific pins pairs can be used differentially; so pin *114_p and *100_n can't be used as a differential pair. For the purposes of this discussion "used differentially" means that you can assign a differential input buffer, differential output buffer or differential inout buffer to a particular pin pair. The important thing to remember about differential signalling is that for a differential input buffer the _n and _p signals at buffer have to switch SIMULTANEOUSLY and NOT have the same logic state. You can never achieve that for all instants of time but you better be close. How close you can get to driving a differential input buffer correctly depends on things like PCB traces between the FPGA source pins and FPGA destination pins ( assuming an obut drives an ibuf ), vias used in the PCB routing, connector pin signal characteristics, etc. etc. The main idea behind differential signalling is that by sending a + and - version of a signal on two wires that are close enough to be electro-magnetically coupled then, if those wires are victims of a noise source, the same noise on the + and - signal pairs will tend to cancel out improving the intended signal characteristics. Of course this only works if the wire pairs are actually routed that way. Digilent differential PMODS are to a certain accuracy; regular PMODs are not and are highly unlikely to use differential capable pin pairs. To avoid skew between the _p and _n versions of the signal it is imperative that the wires (traces) for both be precisely the same length. You can often spot differential signal traces on PCBs by a meandering pattern used to make wire pairs and sets of wire pairs close to the same length.  Now, in terms of FPGA devices there is no differential or single-ended IO.. there are only specific signalling standards that are differential or single-ended that any particular pin MIGHT be capable of supporting. You need or read and understand the Xilinx Series 7 IO reference manual before trying to connect stuff to your FPGA IO pins as ignoring or being ignorant of the these IO standard requirements are can lead not only to bad performance but destroyed FPGA devices. There are no analog "comparators" in FPGA devices; just pins connected to IO banks capable of being used with a limited range of IO standards depending on the bank supply voltage.

Now, if all you want to do is play around can you pretend to have differential signalling by making an arbitrary pin "signal" and another arbitrary pin the logical 'not' of "signal" ? Sure! Is it a differential signal? NO! Not even at really low toggle rates.

The single-bit modulator was a wonderful "invention" involving a lot of DSP insight. I once heard a talk by the guy who patented it. I applaud you for wanting to re-invent that wheel but you've been cautioned! If you are reasonably well versed in DSP theory and practice ( EMPHASIS on the practice part...)  this could be a really nice learning project that can be as complex as you want it to be. Is it possible to design an interface board to receive the signal at the end of your coaxial cable and turn it into, say an LVDS_33 IO standard compliant signal? Sure! Is it worth the effort if the board that your interface board connects to has single-ended PMODs ? I think not. How about one with differential PMODs ? Well, that depends on whether your goal is to get hardware that lets you use that signal from the other end of your coax cable or is to experiment with an idea that you have. If you've read this thread and project material carefully you will know that I NOT a fan of the Digilent differential PMOD... hence the project dedicated to it.

 

   

Link to comment
Share on other sites

Neil,

My reference to "The single-bit modulator" should have been single-bit modulator ADC. And, I forgot to mention that Xilinx has a wealth of application notes on may subjects including, if my poor old memory server be correctly, one on a single-bit modulator ADC.

Link to comment
Share on other sites

@zygot,

That was your "short" version?  :P

@neil,

A single bit communications system is known as an "On-Off Keyed" (OOK) system.  It's a common enough system for the mathematicians, although not nearly as common in practice.  At least, not from my perspective--mostly because t's hard to modulate it to any carrier frequency in order to send it across some distance via radio frequencies, and because OOK has some nasty artifacts to it were you to even do so, but that doesn't take away from the fact that it is a valid means of communication.  Indeed, across a PMod cable, single ended though it be, it comes across as quite the capable means of communications.  It the transmitter can be made to produce suitably random data, a simple multiplication (think (!(a^b))) can often be used to recover the clock signal within it and thence to recover the sample timing you would need to get your data back off.

Dan

Link to comment
Share on other sites

D@n,

'Fraid so... that was the short version.... as to the marvellous prose like  "poor old memory server be correctly" , English really is my native tongue. I blame poor eyesight and the fact that regardless of what my mind has to say it's the fingers that I type with that get the last word in.... and those darn fingers have developed a seriously bad sense of humour. I do know a few things about communications though never enough thank you... but I was trying to reference a novel ADC topology when those darn digits got silly.

Link to comment
Share on other sites

@zygot,

Hmm ... I wonder which would transmit more information faster: two single-ended lines running at half the speed, or one differential pair running at twice the speed?  Fascinating question.

As for your advice to @neil that he would need to be well versed in DSP theory and practice in order to build an OOK system, I would disagree.  I learned OOK systems as a newbie before becoming "well versed" in DSP theory and practice.  Indeed, learning the basics of OOK was a part of my path towards becoming "well versed".  I do agree that such a project could be "as complex as you want it to be."  Sure!  Add a clock recovery circuit, forward error correction, randomization, yeah ... "as complex as you want it to be" is most definitely true.

Dan

Link to comment
Share on other sites

  • 2 weeks later...
On 12/6/2016 at 9:24 AM, hamster said:

However, PMOD connectors are not very good for very high frequency signals - I once managed to get 500Mb/s through 0.1" connector and 200mm jumper wires, but it wasn't really a properly engineered solution. You would be very, really lucky to get 50MB/s through each pair.

I was wondering that myself for the Arty "high speed" PMODs, so I got a rather inexpensive HDMI Transmitter Expansion Module from numato (since digilent doesn't offer any HDMI PMOD modules). It has two 2x6 pin headers but the pin order is not really compatible with the Arty differential pairs nor is the distance between the two headers the same, so I had to use jumper wires (run-of-the-mill, 200mm).

I used your Arty 1080p code. With the naive approach (connect and pray) max resolution all I could get was 720x480p (27MHz pixel clock). Anything with a higher pixel clock would simply fail.

After giving each pair of wires a few twists though, I was able to get 1280x720p @60Hz (75 MHz). That's 750Mbps per pair, which is quite impressive. I even jiggled the wires and left my phone next to them (called a couple of times too :) ) but it didn't go out of sync. There could bit bit errors, but there was no obvious picture degradation (not that my eyes are any serious BER test). Couldn't get 1080p though. Maybe if I snip the wires shorter, but it's out of spec anyway and 720p is more than enough to play with.

https://goo.gl/photos/7ZNUidDiTGhKtqH29

https://goo.gl/photos/gBiMt3zSNaRVzL4Y6

Zygot's challenge is very interesting by the way (as is the discussion in this thread), unfortunately I only own this Arty at the moment. It would be nice if the people at digilent could do the test with various boards and tell us what the max achievable rate is (pmod documentation is rather lacking in this area). It's still nice to see this kind of performance

Link to comment
Share on other sites

3 hours ago, zygot said:

Lvoudour,

Thank you for your comments though they are a bit out of context application-wise.

Indeed, but for what is worth I wouldn't even bother with any such pmod application if I hadn't read through this discussion. Anyway, sorry for hijacking the thread

Link to comment
Share on other sites

  • 2 months later...

So ... now that I have a Nexys Video, here were my starting thoughts:

  1. My plan is to sample the receiver at 950Msps ... the maximum bit rate that can come in.  To use an ISERDESE2 receiver, that'd require a 475 MHz DDR sample clock ... doable enough.
  2. Next, I plan on clocking the transmitter at 950/3 Msps.  This will keep my design below the Nyquist sample rate (950/2), and guarantee that I at least get one sample mid-symbol.
  3. Four separate signals, not necessarily synchronized, each transmitting at 950/3 Msps, should yield a total throughput rate of roughly 158 MBytes/sec.
  4. A simple matched filter should help to pull this received signal out of the noise.  I can also average outputs of this matched filter to get values "between" samples.  This will "up" the sample rate internally from 950 Msps to 2x 950Msps, or 1.9 Gsps.
  5. The next step will be to multiply pairs of samples separated by three samples (1/2 a bit).  This should generate a square wave at the clock rate--provided there are enough clock transitions.  (A randomizer prior to the transmitter should help to ensure this.)
  6. I expect to use some form of forward error correction and frame synchronization, but ... my design ideas haven't gotten that far yet.  Both of these would lower the ultimate bit rate, but also create a more reliable channel.

My initial thought was that I might sample 10 bits per clock, and use a 95 MHz clock derived at the same time as the sample clock.  To keep things simple, I'd then expand this to a 3-bit word, such as 12-bits, and gate which samples had output bits and which did not.  This, though, is going to take more work to set up properly.

As with most signal processing tasks, I intend to use a "ce" signal traveling together with the data to record which clocks hold valid data or not.

So ... I'm moving forward.  :)

Dan

Link to comment
Share on other sites

Hey D@n,

I so do appreciate the interest.     

Item 1: I agree with your math. I'm not so sure about relying on the ISERDES to do your sampling but I have no experience that makes me inclined to discourage you either. I suspect that your data sink logic is going to get complicated... just a gut reaction.

Item 2: I assume that you mean that you will be using a 3:1 IOSERDES. That is the data source parallel data is clocked into the OSERDES at 158.333 MHz (DDR) and clocked out at 950 MHz. No problem here but somehow you need to work out how to manage 32-bit numbers. There shouldn't be much of a problem routing your data source at 316 MHz to meet timing as long as it doesn't get too complicated.

Items 3-5:   I understand my BiPhase PCM coding for self-clocking communications but not the details of what you intend to do. I've got no issue with the concept. If you succeed this will be a very interesting design. As to getting your IO pin pairs to toggle at 317 MHz through 12" of homemade cable assembly... this I doubt that you will do. Really awful things happen to signals driven by FPGA output buffers, especially with a significant capacitive load. Plus there's the issue of getting all of the pair signal lengths matched... I could go on but please DO surprise me.

What I suspect is that the overall data sink design is going to get quite complicated and become hard to route. Again, just a gut reaction. FEC is necessary for robust high-speed asynchronous communications but will hinder your quest for highest overall data rate, as does all serial communications overhead.

thanks for the post. 

 

Link to comment
Share on other sites

@zygot,

Not quite cetain where the IOSERDES comes from.  It would seem to me to be cheating if I used the same output I/O port as I used for the input port (and hence clock).  No, I meant I wish to use an OSERDESE2 on the transmit board operating at 950MHz/3, into an ISERDESE2 operating at 950MHz on the receiving board.  I do not expect to share clocks between the two boards at all--leaving them totally independent.  (GPS tests on the various boards I have suggest that the on-board clocks are within about one part in a thousand, and every one I've tested has been biased slow ... so that should be good enough to lock.)  Further, I expect to use a roughly 4:1 rate on the OSERDESE2, and a 10:1 rate on the ISERDESE2.  Generating the clocks will be a challenge, but the PLL allows a 100MHz clock to be divided by 2 and then multiplied 19 (475MHz), and then divided as I see fit--so I should be good to go there.

As for 32-bit numbers, I just wrote a packing algorithm this morning that'll take words of N bits in at one rate and produce words of M bits out at another.  If all my problems were that simple, life would be good.  Oh, and this was without any transferring across clocks.  That's another module, but I've got that one designed too.

Of course, I haven't tried to route *anything* yet, so ... it remains to be seen how easy or hard that will be to do.

As for matching cable pair lengths--that's not part of my plan.  My plan was to synchronize to each of them independently.  By the time you get to the 32-bit word rate, the words should be showing up at (about) the same time--plus or minus a clock or two--I'll figure that part out.  It's certainly not the hardest part of the design.

Oh, and I should ask ... did you catch this post@Andrew Zonenberg posted an amazing digitized picture of what an eye-diagram looks like coming out of a high speed PMod port.  Absolutely fascinating.  Instructive too.

Dan

Link to comment
Share on other sites

D@n,

I forgot to mention that the Anti-Differential PMOD challenge has a newer version of Testbed.vhd that fixes issues of really high bit rates ( above 200 MHz or so...) The APD is simply the Genesys2 DDR design from the Differential PMOD Challenge that takes advantage of having a real clock to work with.

I recommend that you read Xilinx XAPP585 and work through the source code before trying to dive into IOSERDES. Xilinx has a number of application notes on oversampling serialized data that should give you a feel for what's involved. Using the SERDES in the IOLOGIC is NOT a trivial undertaking.    

Link to comment
Share on other sites

D@n,

We got (cross-linked) mail!

What I mean by IOSERDES is that I'm too lazy to write ISERDES and OSERDES multiple times. (Actually, I'm too lazy to correct what my fingers are typing....) There is no IOSERDES.

As to matching data signal pairs. I was referring to matching the _N and _P signals of each pair... to reduce jitter. As to matching the pairs of data pairs... you can certainly take care of that in your logic. In fact, even without SERDES in your IO since we don't have the Gerbers for the Nexys Video board layout we don't know which of the pair-pairs are longest or shortest. But it's what's between the data source PMOD and the data sink PMOD that will really cause you problems... unless you have amazing prototyping skills.

I'll check out Andrew Zonenberg's post.

Link to comment
Share on other sites

D@n,

I looked at Andrew's post. As interesting as it is ( Andrew's project is VERY interesting ), unless I'm missing something, it's a picture of his prototype sampling scope PMOD measuring the eye pattern from his prototype on one pin of a differential PMOD ( I only see one cable so I'm assuming one pin is under test.. I've never seen coax cables with differential pairs though I suppose that such a thing could exist ). I don't think that the resulting eye diagram is of much use for our purposes. It certainly doesn't say much about what your differential input data will look like after going through your test cable assembly... even if you are using a custom board with 8 impedance controlled connectors and 8 expensive coax cables.

Link to comment
Share on other sites

@zygot,

How far apart do you expect the data pair wires to be on a cable?  We're talking about a signal that propagates at the speed of light.  Thus, even a 1GHz signal, would need a 15 cm cable length (c/1e9/2) difference before it becomes relevant (1/2 a bit length off).  In the example I gave, I'm only depending upon the two wires to be within about 1.5ns of each other (18 inches propagation).  Hence, I'm not expecting significant cable length difference problems.

Dan

Link to comment
Share on other sites

If we're talking about perfect square waves in a vacuum your analysis make sense. As I recall the rule of thumb for propagation delay on a trace on top of an FR4 PCB ( without vias or connectors) is about 1 ns/inch. Still doesn't sound like much. But we're talking about signals with very finite rise and fall times, warped by reflections, impedance loading that is not well contained, cross-talk ( yes the differential approach should moderate this to the extent that we maintain our signal quality throughout the full path ), heavy capacitive loading, etc, etc. It all adds up to make for a very small eye that will not resemble the display on Andrew Zonenburg's post.

Perhaps 35 years of engineering has made me a pessimist... but I haven't found optimism to be anything other than an impediment most of the time. Even when you have great lab tools, simulating tools and understand all of the gremlins it's been my experience that very often a careful analysis leads to another one after you get to play with the hardware.

There's no harm in finding out for yourself.  Don't let me throw water on your fire... just keep my caution in the back out your mind when you try out your design on your hardware. All that Digilent says about the routing of their differential PMODs is that they maintains inter-pair matching of +/- 20 mm which is more than I've done for critical routing of high-speed signals on a PCB.

 

Link to comment
Share on other sites

@zygot,

See ... that's why I wasn't going to use the traditional digital signaling and sampling approach. 

My plan was to instead treat this as a noise dominated radio signal which can be reconstructed with well known signals reconstruction approaches. These date back to Nyquist's "Certain Topics in Telegraph Transmission Theory", but I would also reference "An Introduction to Matched Filters" by George Turin,  "Structure of Optimum Receiving Filters in Data Transmission Systems" by Thomas Ericson. and "Optimal Pulse Amplitude Modulation Part I" and part 2 by Toby Berger and Don Tufts.  I'm not looking for a perfect eye diagram with sharp edges.  A cruddy eye that at least opens in the center will do.

Here's how I figure things: I'll create three sample periods per bit, each about a ns apart.  I expect the first and last of these bit periods to be digitally unreliable, perhaps having as much as a 50% bit error rate--I don't care.  This error rate should be lower in the case of repeated bits, and we can use that later.  Instead, I will only require the middle bit to be reliable.  That bit is going to be less reliant on the various line lengths.  I'll then solve for which bit constitutes this middle one, and use that as my digital bit.  If this isn't good enough, then I can still uses Shannon's principles and trade transmission rate for a lower bit error rate via a forward error correction scheme--rather than requiring a carefully variable clock rate.

If you aren't quite following, consider this question: What is the autocorrelation between data samples?  Specifically, what will be the expected value between x[n-1] and x[n+1], where x[n] is a sampled bit, and Ts is 3.  Oh, and one more thing--for anyone familiar with the text book approach to generating such statistics, don't assume stationarity or average across all values of n.  Digitally generated signals are not stationary;)

Dan

Link to comment
Share on other sites

D@n,

Hey I'm all for non-traditional approaches based on proven theory. My only concern would be implementing it and getting the design to route within the timing constraints. But as that's your problem, all I can say is go D@n go! While you're working the design I guess that I have some reading to do.. I have some experience with the concepts you mention in your list of topics but I can't say that I understand how it's all going to work. A DFE that could adapt to your cable assembly is the only thing that's close to my experience. This wouldn't be trivial. Don't bet your life savings on an eye pattern with any kind of opening over the 10 ms or so that you'll be transmitting.... though there's a chance.

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...