Resolving chronic itch with the Ethernet PHY

[zygot]

Connecting Intel (Altera) and Xilinx worlds with a cheap cable.

I've been doing FPGA development using Altera and Xilinx development tools for many years now. This has produced a lot of years long itches that I've found hard to make go away. Generally, these irritations are caused by obstacles thrown in my way by vendors wanting get money out me. It's really hard to find inexpensive Altera based development boards with an Ethernet PHY not connected to an ARM PS, or with a decent UART port or any useful USB port. However, you can find ways to connect Altera based development boards to ADC/DAC devices with reasonable performance. In the Xilinx world it's the other way around. Both vendors have made playing with transceivers very difficult, especially for the non-premium devices. Both vendors try to use their soft-processor based development flow as the only way to do anything useful with their development boards.

The HSMC has long been the standard IO interface providing a reasonable number of IO for both low speed and high speed uses. But try and find a reasonably priced Xilinx development board with an HSMC connector. For too many years the 8 signal PMOD has been the only IO available in the Xilinx world until recently when boards with an FMC connector have become available. Recently, expensive Altera boards with an FMC connector have also become available. So, I have a lot of hardware that can do a lot of things... except what I want.

What to do... what to do...

Recently, I released an Ethernet test tool to the Digilent Project Vault. If view counts are any measure there hasn't been much interest. I've recently make a demonstration project that resolves a few of the previously mentioned itches. Below is a brief description.

The project connects my ATLYS board to two channels of 100 MHz ADC and DAC interfaces. The ALTYS uses the high speed USB 2.0 Adept interface to connect to a C program for downloading DAC waveforms to and upload ADC samples from the DDR2. DAC waveforms can be of arbitrary length. All of this data goes through the ATLYS Ethernet PHY to an Altera Cyclone V GT based development board with 2 HSMC connectors and the rare Ethernet PHY - FPGA fabric connections. One of the HSMC connectors has a Terasic DDC board with 2 250 MHz DACs and 2 150 MHz ADCs. At best Gigabit Ethernet supports 125 million bytes/s full duplex data rates... but the good news is that this is, unlike USB, a sustainable rate with very low latencies. Currently, the project runs all 4 converters at a 100 MHz sample rate. The sample rates supported through the Ethernet cable are 25 MHz. DAC samples from the ATLYS use 4X interpolating filter in the Cyclone FPGA to create 100 MHz samples. ADC samples are decimated to 25 MHz sampling rates. DAC data is sourced from 2 16 KBx16 block ram DPRAM waveform buffersi a ping-pong arrangement so that I can write new waveform data without disturbing the DAC outputs. Whenever the read pointer crosses from one half of the buffer to the other half the Cyclone sends an ADC packet to the ATLYS with 8192 samples. The start of the packet is used as a synchronizing signal to the ALTYS to know when to send the DAc packet. The Ethernet PHYs transfer 100 million bytes/s
for DAc waveforms longer than 16384 samples continuously. That's the overview. Why bother to post this? I'm not the only one with an itch problem. Hopefully, this project will spark some interesting solutions to their problems.

I've provided 2 pictures to show what's going on. In both CH1 and CH2 are the DAC outputs. CH3 is the ADC packet and CH4 is the DAC packet. Notice the latency bewteen the packets in the blowup image.

[zygot]

There's a lot that I could say (would've said ) about this project and will be happy to reply to any questions. Honestly, I did expect some comments based on the pictures.

One thing that I intended to mention was the idea of using lookup tables for waveform generation. This is the method that I chose and is very flexible in terms of what kind of waveform can be produced. It is also limited in terms of resolution. You can understand this by working out the possible sinewave frequencies that can be produced with any given integer number of samples. Use a spreadsheet to show Fs/n, where n is the number of samples per cycle and Fs is the sampling rate. The alternative is to use and NCO ( numerically controlled oscillator ). This can easily provide a much greater degree of resolution but most of those frequencies will have appreciable jitter. I mention this because as I was starting out I used NCOs as a reference (sanity check) for the early versions of my Cyclone build. If you're going to do a complicated design  involving multiple FPGAs and software it's almost always quicker to get to the end by doing multiple controlled, easily verifiable, design steps. It's no intuitive but more steps, more iterations often gets you from point A to point B sooner. Anyway that's why you see sinewaves in the pictures.

As an aside, my NCOs use a lookup table to generate the sine function. This presents the same kinds of issue as the project design approach but requiring a more complicated analysis. One problem is that the greater the bit width the larger the lookup table requirement is, if you want to represent all possible values. Most digital NCO implementations ignore these gaps. The alternative is to calculate the phase on the fly... not impossible with low end FPGA devices but not easy.

Normally, in real systems digital samples directed at DACs are filtered for a variety of reasons. The 4x interpolating upsampler in the Cyclone HDL does this and has consequences that might not be desirable.

Also not obvious is that when you use the digital or analog clock resources in your FPGA you are restricted in your choice of output clocks even though there is a combination of multiplier and divider values that might be close to the clock rate that you want.

I love this stuff, and we haven't even gotten to modulation... but if you don't have the hardware you can't play game.

I also have this long simmering itch to a project that so far has the title "Fun with Phasors"... still thinking about how to do it ( it's got to be fun which isn't how I remember my early motors coursework )

[zygot]

I had intended to include these scope pictures:

One shows the DAC waveforms after the first DAC packet updated the waveform buffers. The waveform buffers are initialized in the configuration bitsteam.

The other shows the latency from when the ATLAS gets an ADC packet to when a DAC packet is sent.