Differential PMOD Challenge

[zygot]

Correction,

My reference to the "rule of thumb" wasn't a reference to a human digit... I meant to say that propagation delay on a trace on top of an FR4 PCB ( without vias or connectors) is about 1 ns/foot. Yes, when I type thumbs rule and a foot is in my mouth.... live with it. ( I have to...)

[D@n]

@zygot,

1ns/foot is a measure I am familiar with.  1ns/inch was surprising me ... but, not having built circuit boards, I was holding my tongue lest there be some magical physical phenomena taking place within a circuit bard that I am not familiar with.

But, looking back on the problem, I just got a multiplicative scrambler up and running.  For those not familiar with scramblers, there's a wonderful wikipedia page on the topic, and I even implemented the V.34 scrambler referenced on the page.

So, thinking on the topic of synchronization, there are a couple basic approaches:

1. Transmit the clock on a line traveling next to the data.  This works as long as you can guarantee the two wires (clock and data) are close to the data bit duration in length.  Incidentally, the page you cited above regarding getting an LVDS receiver to work highlights all of the difficulties with this approach: each individual data line needs to be individually "sycnronized" to the clock, this synchronization can cost added or lost bits, etc.  What a PAIN!
2. Use a "start bit" transition to synchronize the receiver.  This works for short transmit words (UART), and relies upon the receiver being able to generate a clock "close" to the one being transmitted--close enough that no errors will incur until the next start bit resynchronizes the clocks again.
3. Embed the clock within the data.  For example, you could split your bit period up into two periods, one containing a clock and one containing data.  I was first introduced to this approach as it was used in Modified Frequency Modulation within disk drives.
4. Ensure that the data has enough transitions that a clock can be recovered from the data itself.  (This is going to be my approach )This involves encoding the data in such a fashion as to be able to recover the clock from the data later.
   1. One common method of doing this is 8b10b encoding, where 8-bits of data are re-encoded as 10-bits of data with guaranteed clock synchronizations within them.  This approach has been used in gigabit ethernet and I'm sure dozens of other applications.
   2. Another approach uses a scrambler.  The goal with using the scrambler is to guarantee that there are enough transitions within the data itself to recover a clock from the data.  Of these, there are two basic types: additive and multiplicative.  The result of the scrambler is that the bits then crossing the wire can be treated as statistically independent and random '1' or '0' with probability 1/2, and thus have some nice properties associated with them.
      1. Additive scramblers work by "adding" a stream of independent pseudorandom bits (1+1=0, 0+1 = 1, 0+0=0, etc) to the data stream.  The difficult part of an additive randomizer is synchronizing to the random stream in the receiver, but it offers the nice advantage of not artificially increasing the error rate in poor SNR conditions.
      2. Multiplicative scramblers work by feeding the data bits into the generator for the scrambler.  (The wiki page offers a better explanation.)  The difficulty with these is, in the case of the V.34 scrambler, any single bit error becomes 3 bit errors.  The advantage is that you don't need to add data to the stream for synchronization, these scrambler types are completely self-synchronizing.

So, my plan is to use a multiplicative scrambler to place enough transitions within the data stream that a clock can be regenerated from it.   Hence, if you try to calculate that expected value I mentioned earlier, you should be able to assume statistically random and independent bits being communicated.  (They never are, but the assumption works pretty well.)

Dan

[zygot]

I've used scramblers, I've used symbol encoding. I've never though of them as alternatives as I've always used them together. I have to think about what you're doing for a while. The easiest way will be when I can analyse your working submission. 

[zygot]

To anyone interested I figured out how to show the latest project code versions in the first page....

I could post a more recent version but so far haven't had sufficient interest.

[zygot]

It's getting close to the first anniversary of the Differential PMOD Challenge and there's been a fair amount of discussion related to the project. There's been one stakeholder that's been noticeably quiet on the matter so I thought that I'd offer some free advice (it's unsolicited, hopefully not unwelcome, after all) on how a usable differential interface might be implemented for Series 7 FPGA devices.

  - provide 10 general purpose pairs
  - provide 2 pairs on IO pins that can connect to the global clock network, so that one can be an input clock and one an output clock
  - assign all of the IO pins to an IO Bank with Vccio = 2.5V
  - use a connector with good signal characteristics but not with pins that are so closely spaced together that it requires expensive PCB layout software to design a board with a mating connector. Some customers want to create their own interface boards to use with an FPGA board.

The preceding suggestions certainly do not represent the best possible interface if one is restricted to a very limited number of possibilities; but it sure would be nice to work with.

Ten pairs of general purpose IO may seem extravagant but it allows a user a lot of options. They can have an 8-bit unidirectional data bus with 2 controls, 2 4-bit bi-directional data buses with 2 controls, etc. Not every one wants to go to the bother of designing a full-blown LVDS design so 10 pairs allow for using the less complicated DDR interface. Series 7 devices don't offer many options for IOSTANDARD selection when the IO bank Vccio = 3.3V; it's TMDS_33, unless you want to mess with a complicated termination scheme. With Vccio = 2.5V you can use internal DIFF_TERM and have an ideal hassle-free termination scheme. I figure a good quality 40-pin connector should work fine. If you are forward thinking you may see why more IO might be warranted to attract third parties who want to attach their nifty demo boards to an FPGA board. I frequently use a cheap FPGA board from a vendor of Altera (Intel ) FPGA boards because they have 2 40-pin .1" connectors full of IO. They're great for cobbling up a quick FPGA centric design in a hurry. But they are all single-ended IO.

To see how not to implement a differential interface there's quite a few schematics from a silent FPGA board vendor that can be compared to the guidance in the Xilinx Series 7 Select IO Reference Manual.

Finally, some advice to Digilent as a friend. Not all of your customers are technically naive. Ignoring mistakes does not reflect well on your company, especially when that mistake becomes a "standard feature" for all of your new products.

The idea of a differential interface is a good one. Why not have a usable one.

I'm sure that I'm not the only person with an opinion on this subject... so to anyone who's been following project; what do you think?

 

[JColvin]

Hello @zygot,

I'm not able to offer any guarantee of things happening since I'm not part of the appropriate meetings, but I personally think that having a section of the board dedicated to differentially paired GPIO would be a great idea; I know you certainly aren't the only customer to suggest this on the Forum since there have been requests that have come through other channels as well.

I do have a couple of implementation questions though; how would you imagine these pins are available to the end user? I think in the past (I don't have any sort of confirmation on this) that this was done through an FMC or a FX2 connector, but those sort of connectors inherently limit the general accessibility to those differential pairs in terms of actually connecting to those pins. Do you feel that having those sort of connectors (or a different connector that is classically dedicated towards those sort of presumably high speed signals) is a detriment to end users? The reason I ask is because (as you have inevitably noticed) we try to make our boards accessible to a broad range of users which does impose some constraints on the end board. 

The other question(s) which ties in to the above one is who is the target audience for this board and what other sort of components would you want to see on the board? Would there be a bunch of embedded user I/O on the board (switches, LEDs, and the like)? IIRC, a number of the Artix 7 chips have PCIe capabilities; would these be available on the board?

Naturally, if the board is chock full of differential IO and other high speed IO (what is high speed in this case) it will be a different sort of product than what Digilent currently offers at this point in time. Personally I'm not opposed to it; I think there is market out there (as you have shown) for a low-cost/reasonably priced board that is focused on differentially paired IO and other high speed lines to offer a different sort of development environment that what is currently offered. Certainly it won't be for everybody, but at the same time I'm pretty sure that FPGA development boards of any kind are in-as-of-themselves a niche market. The interesting bit that I imagine would come from the Digilent side of things is being able to properly support such a platform since in a sense it would be closer to the all-in-one product solution much like our instrumentation line (like the Analog Discovery 2) side of the spectrum as opposed to a more open development platform where a far wider variety of applications can be achieved. 

But, those are just thoughts (and some questions) from a guy who writes documentation for all of the non-FPGA platforms; take it as you will.

Thanks,
JColvin

[zygot]

Hi @JColvin ,

For a guy who "writes documentation" your reply is just fine. Actually, what I mean to say is that if you have good insights you needn't qualify your comments with a self-deprecating lead-in.

For a long time now I've been pointing out that what your company refers to as a differential PMOD has been badly flawed on every board that it's appeared on ( and worse yet keeps getting put on every new board ). I've done this subtly, directly, quietly, and loudly; but always with working demonstrations to prove my point. Yours is the first response from a Digilent employee and appreciated. Let me summarize the problem, ignoring the obvious one that they've all been badly implemented:

- taking a bunch of unused IO pins from a random IO Bank and routing them differentially to a low speed connector does NOT a differential interface make, even if you choose the correct pins.

- your customers would be much better off having the regular PMODs with routing appropriate for low speed single-ended signals than almost useless "differential" PMODs.

- the PMOD has a purpose but it's time to expand on the idea. Useful IO connectors could be low speed and wider; say 16 or 20; They could be faster and wider ( along the lines of my last post )

- Digilent not only has customers who want to connect stuff to their FPGA boards but also major vendors of analog and digital products who want your customers to connect their product demo boards your customers' FPGA boards. Why would Digital want to interfere with this rather than encourage it?

- a useful connector with differential signals would be great for everyone, including Digilent.

- I'm not suggesting that Digilent make major changes; just stop littering their boards with connectors having a badly implemented interface. A couple of the regular 12-pin PMODs plus one high speed connector with a mix of differential and single-ended signals would be so nice! Actually, 1 12-pin PMOD and a wider connector with 20 single-ended IO and a good high-speed connector would be even nicer!!!.

So, in a nutshell that's my point. As to the particulars I'm not getting paid to engineer a great high-speed connector design ( though I've already given some good guidance ). In fact I'm not in a position to tell Digilent how to implement anything because that's a business decision requiring careful thought that only its management can make. But I certainly can suggest that they care about what they do and try and make products that customers will want. I certainly know how I'd start if I was given the task to design one.

- find out from companies, like Ti, ADI, Linear, Maxim-IC etc. wanting to connect a demo board to your FPGA board products what they'd like to see in a high-speed connector.

- find out from customers the same thing

From there it's all a matter of will and execution. I could design some nice interfaces though I assume that you have competent engineers who could do that as well. I certainly can help suggest what kins of connector footprints a typical user can deal with easily and what kinds they can't.

What I hope to never see again is another FPGA board from Digilent with one of those horrible "differential PMOD" implementations.

[zygot]

The views of this project seems to keep rising even though there's been no recent posts of source code. I'm just interested in why this is. So, if you take the time to view the (extensive) posts on this project pleas take the time to add a post. Did you download the source to view it? What were you looking for? I ask because I'll post a current archive of code if it would help anyone contribute.

Be aware that a few of the source files have been updated in other projects and that I haven't bothered to post updated source since I have no idea if there is a real interest in contributing or there is something else going on.

[zygot]

@D@n

So how's all this coming along? Gosh I'd be nice if anyone would submit a design. You're the only one who has a plan worked out so far and been willing to post it.

 

 

On 4/19/2017 at 7:58 PM, D@n said:

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. 

 

On 4/19/2017 at 2:31 PM, D@n said:

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.

 

[D@n]

Oh it's coming along quite nicely.  The design is written.  Simulation testing has completed several times.  I have Octave code which will create a nice and pretty spectrogram output.  The differences are pretty stark.

I'm now implementing the example design on a Nexys Video board.  It doesn't need to be a Nexys Video, but that's the one that's on my desk right now.  If you don't want to run the simulation, that will at least allow you "listen" to the difference and decide for yourself which you like better.

I did make one change to the output list: I'm going to mirror the switch input to an LED, just to give you some confidence that you've selected the result you think you've selected--so that you know which of the two you are listening to.

Dan

[D@n]

As an example of what I'm looking at, here's what I'm currently getting for a PWM spectrogram output.  The "correct" answer is a single line coming from the top left corner diagonally down to the bottom right.  The multitude of lines indicates a distortion being produced by the traditional PWM output.  The first (top) of these is the correct one.  Towards the far right of the screen, this correct line crosses with an alias line which you would expect given that I'm sampling a tone at 32kHz with no anti-aliasing filter to protect it.  (The simulator has such a filter with a cutoff at about 22kHz, supporting a 44.1kHz resampling effect).  I'm a little concerned that I might have a bug in this demo output--since I wasn't expecting any harmonics at low frequencies, so I'm still working hard to dot my I's and cross my T's before posting "official" results.

Dan

[D@n]

Sorry ... didn't pay attention to the forum title.  The above comments should've gone into the PWM forum.

Dan

[zygot]

@D@n,

And your last 2 posts had what to do with the differential pmod challenge? I think that you got your threads crossed....

[D@n]

(Yes, I got my forum threads crossed ...)

As for the differential PMOD challenge, I think I bit off more than is necessary to accomplish the problem, so I might need to scale back the requirements of my design.  I had designed an entire packet framing scheme (8*256 bits per frame), feed through scrambler, synchronization pattern, forward error correction (247,255), CRC checking, and more and ... all the extra stuff is creating more work than I perhaps need to do.

Of course, this is all taking place slowly, as I have opportunity between other projects.

Dan

[zygot]

It's been awhile since anyone has posted to this project.

So time for a pop quiz:

Who can provide the best answer as to why no one has posted an LVDS IOSERDES2 implementation and probably never will? (Ignore the fact that despite a few suggestions for beating my rather low effort implementations I'm the only one to have posted any solutions)