Sign in to follow this  
Followers 0

Differential PMOD Challenge

82 posts in this topic


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...)

Share this post

Link to post
Share on other sites


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 B))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.)


Share this post

Link to post
Share on other sites

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. 

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites

Posted (edited)

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?


Edited by zygot

Share this post

Link to post
Share on other sites

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.


Share this post

Link to post
Share on other sites

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.

JColvin likes this

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0