Jump to content

Differential PMOD Challenge


zygot

Recommended Posts

Hamster,

I've been wondering when the furry little rodent from NZ would get out of his exercise cage to comment. ( Really, I write that with admiration and a bit of a chuckle)

Doesn't anyone notice that there are 2 project zip file releases embedded in this thread? Has anyone actually downloaded the project and read though any of the documentation and source?

What you say is not incorrect. What I have provided so far has gotten the project to about 20 MB/s per data pair. The challenge constraints were made to induce some creativity not directly produce a viable interface.... though anyone working through the exercise might come up with a useful design. There's plenty of room for improvement to go if one considers the design of the PMOD interface as well as the approach to design data sources and sinks.

Remember this challenge is about transmitting/receiving 4 MB of data error free though 12" of cable using only differential PMOD connectors and passive components.

 

 

Link to comment
Share on other sites

So far, there's only been 2 people who've posted comments on what they think they might do if they wanted to spend the time to do it and 1 (me) who has posted results of what he has actually done. So here's a bit of incentive. I have 8 more interface PCBs like the one that I've been using. I'll mail one to the first 4 people who post their own data source and data sink that bests my published work.

Rules:

You have to post code for the toplevel, data sink, data source, and the testbench that you think works here on this thread.

If I can recreate your design in the Vivado simulator I will build a configuration file and run it on one of my boards and log a test result. If it's a worthy effort I'll mail you a free interface board that you can use for this or any other project.

Link to comment
Share on other sites

D@n,

Well, I admire your goofy optimism. No, I'm referencing the connector2 pcb mentioned in the project. I had 3 panels, each with 3 boards, produced. I'm not adding any components as recipients may want to use them for other projects. I'm using one (obviously) that I populated with components and 12" of CAT6 cable and have been using for development and testing.

BTW, if tens of MB/s doesn't float your boat I will be posting a new data interface project with transfer rates in the GB/s range soon.  I've not hesitated to criticize Digilent over their mistakes ( and recently they've been work really, really hard to earn lot's of criticism...) but have some very positive reinforcement coming their way.

To borrow from a familiar quote from a certain  president-elect: "Digilent you're great.. you're awesome! It's gonna be great, really, it's gonna be awesome!"

 

Link to comment
Share on other sites

I've been thinking, and I'm going to try this coding....

Bit 0 - Invert / non-invert

Bit 1 - Data bit 0

Bit 2 - Data bit 1

Bit 3 - Data bit 2

Bit 4 - Data bit 3

Symbols are inverted to preserve DC balance & minimize running disparity. This coding will also still work if the + and - signals get swapped.So the next issue is how to synchronize the symbols.

We have a problem though ...00000111110000011111... is ambiguous

0 0 0 0 0 - 1 1 1 1 1 - 0 0 0 0 0 - 1 1 1 1 1  is a stream of zeros.

0 0 0 0 1 - 1 1 1 1 0 - 0 0 0 0 1 - 1 1 1 1 0  is a stream of ones.

0 0 0 1 1 - 1 1 1 0 0 - 0 0 0 1 1  - 1 1 1 0 0 is a stream of threes.

0 0 1 1 1 - 1 1 0 0 0 - 0 0 1 1 1 - 1 1 0 0 0  is a stream of seven.

0 1 1 1 1 - 1 0 0 0 0 - 0 1 1 1 1 - 1 0 0 0 0 is a stream of hexadecimal Fs.

It needs some way to recover the synchronization.  Within a data sequences "00000000001111111111" or  "11111111110000000000" should never be seen within a data sequence as it takes the running disparity to far out of wack. I can then use the center transition to recover the framing. This has a crufty feel to it, but should work.

Good points:

- Coding overhead is 25% vs 100% for something like Differential Manchester encoding or Biphase Mark Code.

- DC neutral.

- run length limited to 15 bits, 

Bad points:

- Framing isn't too efficient or effective

- No effective way to detect errors (e.g all codes are valid), other than running disparity goes out of wack

- RF/EMI is most likely very poor - sending repeating patterns is very easy to do - could be improved by scrambling data before sending.

The need for the RX to oversample the input to recover the clock can be removed if one pair sends the clock, leaving three pairs to take data.

At 100MB/s over the remaining three pairs the clock rate needs to be 33.3 MHz, and a bit rate of 333Mb/s per pair.

Using only DDR registers the RX and TX can run at 166 MHz, which is pretty achievable.Using SERDES at 5:1 it only needs to run at 66MHz.

How does that sound as a plan? Sounds reasonably workable...

Link to comment
Share on other sites

Nice! Someone out there admits to doing some thinking. Of course thinking and doing aren't quire the same thing.

So far all that I've done is present templates for instantiating routine Series7 IO resources ( though the self-clocking design example is a bit unique ). There's plenty of tools left in the Series7 IO toolbox to explore. Our biggest hurdle is that amongst the Genesys2 and Nexys Video board's 16 differential pairs connected to PMODs there's nary a connection to a legitimate clock input.. and PMOD connectors aren't quite high performance To see what we can do with a well-crafted IO interface see my new Transceiver Boot Camp post for some inspiration. This challenge has no cable equalization hardware, no PHY drivers and receivers,  and physical layout issues that makes it a more interesting exercise, if you like a good challenge.

Anyway, run little fella run!

If you come up with data source, data sink and a toplevel that simulates properly please do create a bit file that has routing without serious timing issues. This is a more important hurdle. There is a way to test out your pmod challenge ideas without purchasing a Xilinx FMC Debug Board; you will just have to find an independent clock source to replace it. You can run tests without a programmable clock and the provided software though it's going to be a bit more tedious. You will have to craft a cable assembly regardless. 

Thanks for the reply!

Link to comment
Share on other sites

@zygot, you have a strange turn of phrase... passively aggressive and paternal at the same time, and with all the taste and nutrition of a fine Belgian chocolate. :)

Thinking/design is important than code, as the HDL is the expression of your thoughts and ideas - without good ideas you end up with hollow and unimaginative code.

Not having a clock input isn't a grand problem, you can always hook things though a BUFG and onto the clocking networks, and deskew in a PLL by creeping the phase if you really have to because you can't get it to lock. I have to get a grips on how to do this for my HDMI input project, because the current way I do it by looking for symbol errors sucks big-time.

For my testing I was going to do it for real - between two different 7-series boards (e.g. from an Arty to a Basys3 or similar). Looping back to the same chip (sharing references and so on) is a bit of a cheat. Also place and route times are much quicker on the smaller chips.

You can hold your breath if you like, but it might take me a while - most likely after Christmas. Work is busy before a the change freeze, I have an existing software project I'm working on and then I'm away camping for two weeks holiday. But you can be assured that I will be doing some more thinking.

Link to comment
Share on other sites

Hamster,

I like your observation about thinking as a precursor to coding. Thinking and creativity anchored to a good base of knowledge is really what the PMOD challenge is all about. I really appreciate any contribution to the discussion.

As to having both data source and sink on the same board being "a bit of a cheat" I have to disagree as long as the source and sink use unrelated clocks; at least for this project. It's true that for a real interface between two boards there are additional issues to deal with and the problem is a bit more complex. But, I have no issue with anyone jumping ahead and doing that. I could certainly do that using the Genesys2 and Nexys Video boards... hmmm sounds like a follow-on project.

There's no rush to come up with a solution. After all this is an exercise meant to inspire questions and ideas not an avocation. Merry Christmas and holiday. Meanwhile I better get my next iteration ready soon in the spirit of competition and in anticipation of a bump in data rate.

Here's some things to think about. So far I've presented designs based on using 3.3V compatible IO standards. This isn't a requirement. If fact using LVDS_25 might be better. But anyone doing that had better understand Series7 IO, the limitations imposed by IO Bank and pin assignments and how to do it correctly. Using TMDS_33 with the PMODS requires sub-optimal placement of the terminators far away from the receiver pins. There's no clock IO or routing dedicated to a clock, Digilent tells us ( for Genesys2 ) that the pairs have a characteristic impedance of 100 ohms ( to ground or each other? We don't know ) and pair-pair length mismatch can be as much as 20 mm or about 8 tenth of and inch. Using the rule of thumb of 1ns per inch of trace length this is a significant amount of skew. Especially when we don't know which pair is the shortest or longest. This complicates clock to data timing a bit; and this doesn't include our cable. I won't argue that you can put a signal from a regular IO pin onto a global clock line but you better understand what the implications of doing so are for your design and Xilinx's place and route tools. And then we need to consider the impedance changes along the pcb, connector, cable source drivers, etc. Unlike, say hooking up external memory to FPGA pins where we have a chance to preserve somewhat pristine trace characteristics and termination, our clock and data signals are going to get pretty deformed at high toggle rates. I see the problem as a bit more complex than recovering a source clock. But then all of this is what makes the designer's life interesting.

And thanks for your kind understanding of my odd ( yeah I see that ) writing style. Writing or talking might be considered an analogue of a data source and communication the analogue of a data sink. What's being received (communicated to recipient's mind ) isn't exactly what's been transmitted.   

 

Link to comment
Share on other sites

So, I'm looking at the ISERDES capabilities in the data sheet, and it looks like the ISERDES maxes out when reading somewhere near 950MHz (depending on the chip, etc.).  Doesn't that plus Nyquist create a practical limit in any design of this type of 475Mb/s?  I would think that 456Mb/s on any single wire (that's what you were getting earlier, right @zygot?) is pretty close to that limit.  Have I missed anything?

Dan

Link to comment
Share on other sites

D@n,

Reading the data sheet for your device is a highly recommended; so I like your observation. If we were doing true sampling on the the data sink side ( which happens to be true for all of my interface presentations so far... ) then Dr. Nyquist's observations are not to be ignored. In my experience, unless you are really clever, knowledgeable, and taking care of all the details a 2X oversampling doesn't cut it for doing practical things that the poor engineer is tasked to do. Also, your question hints at the usual practice of employing an anti-aliasing filter limiting the frequencies of the sampled data ( or more accurately the frequencies of the data band of interest )  to less than half the sample rate. This should be part of the analysis. Don't forget that we are operating in the digital domain ( though you have to stretch the definition of digital for high speed signals travelling through physical media... ) Oh, in my previous remarks to Hamster I didn't think to mention that before one can do coding, or the prerequisite thinking, one has to understand the problem and do a bit of analysis before choosing an approach to its solution.

The 456 Mbps data rate that you quote me on is for the aggregate of 3 DDR data data pairs; each pair is toggling at just over 150 MHz. I think that we have room for improvement. Bear in mind that just because 150 Mhz has 6.667 ns period this doesn't mean that have just shy of 7 ns to work with. We have to account for rise and fall times as well as overshoot and undershoot.

Just to be a bit subversive let me say that, if I owned Digilent I'd require anyone working for me and having the word engineer in their title submit a solution to the PMOD challenge... couldn't hurt.

   

Link to comment
Share on other sites

@zygot,

Reading over the last page, you discussed compression.  Is compression "legal" by the rules? 

I'm going to suggest that data compression should not be a viable option, and perhaps the sending RTL should encrypt the data to be sent just to prevent anyone from so "cheating" ... but I'm not writing the rules.

Further, if I knew you were using an LFSR (without encryption), then I could then guarantee an absolutely perfect, error free, result on any channel ... the task would be just too easy: solve for the initial fill, and then regenerate the data on the receiving end.  Just a thought,

Dan

Link to comment
Share on other sites

D@n,

??? What I wrote was that the pseudo-random data from the LFSR was frustrating my attempts at playing with adding compression. The old ECP parallel port interface supported a simple run length encoding compression in hardware to replace a long block of duplicate bytes with a number representing how many byte the receiver should replicate instead of sending all of them. If we were doing a real interface using arbitrary data something similar could be useful. My thinking is that if anyone has the time and gumption of creating hardware that can do this with the LFSR data then I'm willing to call this "good" cheating. Of course it would have to actually be capable of working with any incoming data... not a priori data. I don't recommend this because it would require memory, and latency to fill a buffer and given the random nature of the test data just not help achieve the fastest data rate. But I do appreciate creating thinking and hard work for its own merits even if it doesn't accomplish the task at hand. Depending on how a particular interface works it might be that long runs of constant data is bad for robust synchronization and we'd need to randomize arbitrary data to avoid it. This would be true for a typical communications modem.

Yes, you could submit a solution that has no data source or sink and just feeds the testbed Rx FIFO the same LFSR data that it's expecting. But then you wouldn't actually be transferring data through the cable.... or demonstrating any skill or knowledge or doing anything useful. If you did that I'd say that you are having difficulty understanding what the differential PMOD challenge is about. Why would anyone waste everyone's time doing such a thing?  Hey, but at least I've got you reading now...

Link to comment
Share on other sites

@zygot... I got a little bit of code working last night...

- Test pattern generator, which counts 0 to 2^n-1, and then sends a few sync patterns

- 4-bit to 5-bit symbol conversion, that also looks up a symbol's parity count. This only generates symbols with positive disparity

- Disparity balancing - if the running disparity is negative it inverts the symbol and subtracts the current symbol's disparity, otherwise it it just added the current symbol's disparity to the running total

- A 5:1 serializer to output the bits towards the PMOD connector

I've also got a plan together for the RX side of the link... especially about recovering framing and how to detect the sync pattern.

It is coming together quite nicely!

Using three data pairs and sending 20-bit values is just awkward. If not, I might send 21-bit values (about 5% less efficient) but I can then send one number using 7 data bits on each of three pairs... is that still valid for the challenge?

Mike

 

Link to comment
Share on other sites

Mike,

Oh good. From now on I'll call you Mike and can think of you without a picture of a little pet from my distant past popping up in my head.

Well only two people have shown any interest in this little exercise and apparently no one who owns a Genesys2 or Nexys Video board is interested in spending any money to make use of that wonderful FMC connector. This by far the best general purpose interface Digilent has offered on its FPGA board offerings and almost by itself justifies the cost of either board; as long as you use it. From projects that you've published in the past I've been assuming that you have both boards.The Xilinx 105 Debug board is really not, to my mind, a waste of $160. Certainly, there are other FMC mezzanine boards out there that drive one of the differential FMC M2C clock inputs. Regardless, the only real requirement pertaining to clocks in this challenge is that the data source and data sink have unrelated clocks. The Genesys2 does have that GTXREFCLK. Both boards have a FT2232H for the DPTI interface. The problem there is that the FT2232H only puts out a 60 MHz clock when in FT245 Synchronous FIFO mode, As far as I know you have to reprogram the part to do that. Digilent highly discourages anyone from doing this. The demo in the Adept SDK suggests that, contrary to FTDI's datasheets and other documentation, the device can operate in this mode without reprogramming the eeprom. I've written my own interfaces for the FT2232H and reprogrammed my Nexys Video to use this mode so I know that I have a 60 MHz clock but doubt that it is of sufficient quality to use for anything other than with the FT2232H data.

So, you're putting me in a bind here. I've already told D@n, who doesn't have any hardware, that I'd test out a solution of his it he provides source code for a toplevel, data source, data sink and testbench compatible with the framework I've supplied. This seems fair to me. I've already mentioned to you that the independent clock source doesn't have to be programmable. Still, I don't have the time to rework anything provided by everyone into something compatible with the challenge framework.

Having said all of that, the main interest is in challenging people to understand the problem, create solutions, and prove the validity of their solution. So, if you want to submit a "proof of concept" design that has a data source on one board and data sink on another and provide a way to demonstrate that it works in real hardware, even though it's incompatible with the framework, then please do that. Your ideas will be useful to everyone following the project.

It's been my experience that counters are not a great way to test out communications or data interfaces so I'd prefer seeing random data created by any means you like as the 4 MB ( 1 MW 32-bit word ) test stream. The LFSR is the simplest way that I know of to do that. I realise that the 32-bit word part of the challenge is a bit of a hassle... which is one of the reasons that it's there. I've already provided a number of solutions for dealing with odd "symbol" lengths in my source code so this shouldn't be a big barrier. 

Link to comment
Share on other sites

@zygot,

I actually like @hamster's idea of using an Arty connected to a Basys3.  If the hardware could be limited to the two of those, together with a cable from PMod to PMod, I might have a chance to participate.  We could use the Basys3 as the transmitter, and the Arty as the receiver--that way the results could be recorded ... provided the "memory" on the Arty could keep up!

Dan

Link to comment
Share on other sites

D@n,

Mutiny! Revolt!

Whateeeeverrr. (Can you picture my face as I write this? Hint... it's even less attractive than usual.).

From looking at the schematics I see that the Basys3 and Arty boards you mention have 1differential PMOD connector. So you could implement a simplex data interface between the two. Since you REALLY don't want to use the challenge framework that I intend to support may I suggest that you do a duplex interface with a single "lane" of data. This would give you clock, data_out, data_in, and 1 control signal. If the Basys2 is the message originator it could then check the data echoed back from the Arty against the original data stream. ( It would be extremely poor form to just tie the input to the output on the Arty without implementing a true transmitter and receiver). You might be able to see that what you want to do has its own complexity to figure out if you are creating a true duplex data interface ) Clearly, you'll be doing your own challenge as 3 or 4 lanes of data are likely to transmit the complete data payload quicker than 1 using the same design. If it gets you to do something other than make comments I think that it's a great idea. I'll make the best of the little boat I'm consigned to sail the seas in.

Eventually, I intended to use the pmod challenge as a jumping off place for a real data interface. This wouldn't use any PMOD connectors as the Nexys Video, the Genesys2 and Atlys boards all have those nice HDMI hoses to work with and I'm sure to get much better results than anything using the PMOD connectors could do; and only easily obtainable cables required. But this thread is for the Differential PMOD Challenge; one that I think is more interesting and offers the greater opportunity for widening one's range of skills. If you want to win the ultimate data transfer award using Digilent boards then you'll' want to have 2 Genesys2 boards and use those awesome mDP hoses. HDMI doesn't have a chance.

Frankly, none of my source code files are that long or complicated so I think that everyone is better off using the Testbed as the basic test mechanism.

Captain Zygot Blye 

Link to comment
Share on other sites

Sacrifice a wire pair for a clock line?  Sacrilige!  What a waste of a perfectly good wire-pair to transmit data upon!  Why would you ever do that?

I was actually thinking of a simplex transmitter that would achieve the full speed transmission across all 4-wire pairs.  Why not?  That was the spirit of the test, was it not?

Now I just need to figure out how to get a Pmod-Pmod twisted pair cable.  Does Digilent sell one of these (such as this 2x6 pmod cable perhaps?), or will I need to make it myself?

Dan

 

Link to comment
Share on other sites

Perhaps I should point out--I first cut my teeth on MFM signal processing.  Using that approach, plus theoretical limits, etc., but ignoring channel impairments, you should be able to get 325Mbps on each channel.  While this is one commendable approach, I'm still hoping to achieve >400Mbps across each individual channel, and just wondering what those channel impairments are going to do.  Indeed, MFM puts a lot of its energy into a narrow tone within the signal--something that would be a problem were a reflection to grab you at just that distance.  (PSD screen shot attached, for frequencies up to Nyquist.)

Dan

mfm.png

Link to comment
Share on other sites

Well, you've finally got me a bit intrigued. Don't hold out hope for a pre-made cable... but if you find one you are blessed indeed; however when you're ready to test out your design and nothing is happening you might want to read through the project documentation. I suggest that you DO NOTconnect the power pins between the boards. I've already given way more information concerning the analysis phase than I intended but please do your due diligence before diving in.

Bon Voyage.

Link to comment
Share on other sites

ATTENTION: To anyone wanting to use the Basys3 board for the Differential PMOD Challenge. I was a bit hasty looking over the schematic and then indicating that this board has a differential PMOD. The Basys3 has an XADC PMOD. I've never used this board. In glancing over the schematic I noticed the _P and _N references on JXADC but somehow missed the XADC (???! bad eyesight). Before you speed ahead I want to emphasize the need to do your analysis. I'm not going to do it for you but I will make the suggestion that this board doesn't qualify for a Differential PMOD Challenge. Unfortunately, Digilent saved some "ink" on the schematic so you'll need to hunt for additional resources to determine that the IO pins can be used as differential IO. The User's Manual suggest not... but I don't rely on Digilent User's Manuals to be correct. I apologize for the poor guidance.

Link to comment
Share on other sites

D@n,

Somehow your MFM post wasn't visible until this morning so my past two posts ignored it. Very intriguing. But your caveat "ignoring channel impairments" renders everything else in your post meaningless. Sorry, but the challenge is about reality. You have to use real FPGA devices, real IBUFs, real OBUFS, and twelve inches of real wire to participate. All of those will force you to account for channel impairments which tends to be very unkind to idealistic designs implemented in hardware. But I'm still keenly interested in seeing your implementation.

On a different note. I've been doing some pondering. I've looked over the Arty schematic and using 2 of these boards seems to be a reasonable basis for doing a version of the challenge. It has two differential PMOD connectors so you can do a real duplex design. Since this board has some connector pins connected to FPGA MRCC IO pins you could also provide an external clock source and use the framework that I've provided and use one Arty board. The UART IP won't work so you'll have to provide another user interface. You'll have to create a modified Testbed source to handle that user interface. The rest is trivial though determining the highest data rate will be more time consuming. I don't have an Arty board so I can't verify your results though if you provide a testbench that would be nice. Who knows; if anyone offers an Arty based design worth taking the time to consider Digilent may make a quick sale of 2 Arty boards.

If you're like Mike and have Genesys2 and Nexys Video boards then why not use those? You can easily to the challenge without any effort other than constructing two interface cables. One would connect the data source on the first board to the data sink on the second and the data source on the second board to the data sink on the first. The test could be run from the first board the same way that all of the others interface designs have been tested and, more importantly, I can verify your results. 

But hey, nobody is saying that anyone can't do their own challenge or project.

Link to comment
Share on other sites

After a night's sleep I've decided that my response to D@n's MFM post came out a bit harsh. I tend to be overly apologetic so I'll just say this. Think that I'm wrong? Prove it. It's not that I like being wrong but I do want to be enlightened when mistaken. 

I've also decided to bring some order to the Differential PMOD Challenge (DPC).

There are three boards that I am now aware of that are suitable platforms for the challenge. All have two differential PMOD connectors and at least one is a requirement. Two boards have been supported because I can verify results on hardware that I have access to. I'm not getting into the business of releasing anything that I can't verity. The Arty has been brought to my attention but I won't support it unless there is sufficient interest in the project inducing me to buy a board. Otherwise I have no use for that board ( don't take this as a negative criticism of the Arty ). The only real hurdle to using the Arty board is the problem of providing a second clock for the data sink. I've mentioned possibilities that I believe don't work so someone will have to come up with an alternative ( I think that there is at least one ) that will work; and to me this means using an IO pin connected to the clocking network of the FPGA. Other than that there isn't a big hurdle to supporting the board. My CmodA7-35T project already has user's interface compatible the the Arty FPGA device. 

As for using two boards here are my thoughts.

I insist on a consistent measurement for data throughput. This means including any preprocessing or other latencies created on the data source side. Other than having a setup whereby control and timing measurement is done on the data stream initiator board I don't know how to do this. So implementing a duplex interface as mentioned before is workable. At this point this means using a combination of Nexys Video and/or Genesys2 boards. If I do a real board to board interface I will likely start with a project using the HDMI hardware. I don't consider that project to be related to this one other than honing skills in the DPC should be a good basis to work from.  An HDMI interface would work for the Atlys and possibly other boards as well. Some of you might be surprised at how well that old Spartan 6 family compares with the Series7 devices in this area. For anyone bent on submitting a two board solution I still recommend using one data lane; if for no other reason than sparing all of us from the hard labour of constructing multiple cable assemblies.

I also insist on a common user's interface. I can't think of a good reason not to.

To anyone not liking the DPC format or not wanting to support the framework I encourage them to create their own projects inspired by the DPC but I won't necessarily support non-compliant entries to this one. It would all be to the good as far as I'm concerned. If I'm the only "contestant" in the DPC then so be it. I will be disappointed if I'm the only one posting working design code related to it though. 

Link to comment
Share on other sites

  • 1 month later...

All,

I've a Nexys 4 DDR Artix-7, with x4 Pmod ports. I'd like to use the total 32 inputs to build 16 differential input single bit ADC's. I'd like to maximise the sampling frequency, pushing 10's to 100's Mbit/s on each differential channel if possible. Are there any commercially available boards that could i could use for this, or what would i need to design and build myself. 

many thanks,

Neil 

Link to comment
Share on other sites

@zygot,

I'm expecting the cables to run this test between an Arty and a Basys-3 to arrive in a couple of weeks, so I might finally be able to try my hand at this challenge!

My first task is going to be calculating a PSD of the channel: Place random digital data through on one end, and look at the Fourier transform of a measured autocorrelation on the other end.  That should produce a reasonable estimate of what the channel impairments are.  My hypothesis is that the channel will handle lower frequencies just fine, but degrade gently towards the higher ones.  While we've discussed channel reflections here, and while the PSD should show evidence of any if there are such, I'm not really expecting to see them.  (I'll let the data surprise me.)  Indeed, I'm not expecting any correlations longer than 64 bits at the highest speed (between 650-900 Mbps), but ... I've been surprised before.  I'll post the results here when I have them.

Dan

Link to comment
Share on other sites

Dan,

that's great! So when could novices like me get to see some results and a photo of this kit and begin to understand the elements, so we can go off and try build our own, for all those novel applications that need these few hundred Mbps data rates into an FPGA?

thank you, Neil

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...