Capabilities of Zynq-7000 DevBoards

[Geralt]

Hello!

Me and my colleagues want to do a project and we are thinking about using one of the various development boards with Zynq-7000 for that purpose.
Basically we just want to sample and measure some signals and transfer them to a PC (preferably via gigabit-ethernet) for evaluation. So the Zynq would have to do a real-time hardware-in-the-loop task.
The signals we want to measure are as follows:

• 3 analog signals sampled @ 1 kHz by an ADC
• 3 analog signals sampled @ 100 kHz by an ADC
• 2 incremental encoders
• the frequency of a quadrature pulse signal (we would need a pin for edge-detection and a counter that counts the time between the edges)

However, the documentation of those Zynq-7000 development boards on the internet is quite poor. In most hardware user guides I only found that the Zynq-7000 only has the XADC which is dual, but we would need to sample 6 different signals. I have neither found any support for incremental encoder interfaces, nor any GPIOs that are capable of accessing a software timer for edge-detection.

In the Xilinx forum somebody recommended using the PYNQ-Z1 but I do not know how freely you can program the Zynq-7000 with Python. As I said, we would need at least two interfaces for incremental encoders and I have seen some examples how to implement this on an FPGA. But those examples always included coding in VHDL. Is it possible to program the Zynq-7000 in Python with the same degree of freedom as in VHDL?

Which development board (and maybe additional boards/cards) would you suggest to use and why?

Best regards!

[Geralt]

8 hours ago, zygot said:

@Geralt

It might be fine though I don't know how to synchronize the XADC to external ADC modules.

I thought that this would be an easy part. I have not worked with these boards and ADCs before (mostly with microcontrollers) but I thought that you simply send a "start of conversion" signal to any ADC, external as well as internal. Or you keep those ADCs running continuously and just sample the output registers with the desired sampling frequency. I do not have an idea which problems you are addressing in your post.

8 hours ago, zygot said:

@Geralt,

I keep forgetting to mention this. I didn't notice a justification for an ARM or even a soft core processor in your requirements. If all you want to do is capture multiple channels of data over a period of time, store it in a buffer, and transfer it to a PC with no minimum time requirement then you can do this with any FPGA board having sufficient external memory resources. An all HDL implementation might be a whole lot less complicated and faster to execute, provided that you and your colleagues are proficient in HDL development. Given the project as described that's the approach that I'd take.

The only reason why I considered the Zynq-7000 boards is that some colleagues already programmed them and have a bit experience with them. First we wanted to use a microcontroller (most of them provide A LOT MORE peripherals than those Zynq boards) but the problem was the data transfer of the MCU to a PC at such high sampling frequencies: If there is a little latency in UART, SD card communication or Ethernet, MCUs have too little RAM to buffer all the data that is accumulated during this time.This is the reason why my colleagues recommended those Zynq development boards.

If you know better alternatives please feel free to suggest them! That is basically the reason why I opened this thread.

[zygot]

@Geralt seems to have lost interest in this thread but for anyone wanting to find a cheap FPGA with embedded ARM platform needing multiple channels of A/D conversion the Terasic DE10-Nano or older DE0-Nano-SoC boards might be of interest. Both have an LTC2308 ADC which might be suitable for Geralt's purposes. Both have lots of IO that's easy to access. I haven't used the DE10-Nano. It's been a while since I used Altera's ARM FPGA toolchain and remember not being very fond of the experience but maybe things have improved since then.

[zygot]

23 hours ago, hamster said:

I had to buffer it in memory, because a small delay on the PC end would cause the FIFO on the FPGA board to overrun. I could have most likely used a second thread to write the data in real time if I needed to.

For what it's worth ( and that might not be much...) based on what I know about the project I'd be doing something similar to @hamster's approach. But then I've already completed projects using a standalone DDR controller and the USB2.0 parallel data interfaces. I pointed out the particular comment above because, to all who venture there, this comment is a diamond in the rough. One can waste a lot of time debugging the wrong things to discover that their PC OS is not playing nicely with an otherwise well thought and executed design. This can be a problem with any interface. Be aware that using USB to transfer very small blocks of data generally reduces the transfer rate considerably due to software and protocol overhead. Instead of trying to transfer large volumes of raw data directly I've found it wise to packetize the data and timestamp x number of samples. You don't need to add a lot of packet overhead but if post-processing starts giving odd results you have some way of detecting lost data. 

[Notarobot]

@zygot

I think you hit the major point. Posters need to do their homework as all professionals do. But since it's time consuming and tedious, people tend to shoot general questions hoping to fish a solution.

Matching an optimal IC with the project requirements is hard. There are so many chips and parameters and lengthy datasheets. If possible I always use evaluation boards before using it in the design. It is way less costly that correcting the whole design.

It was a pleasure to take part in this discussion but need to go...

[zygot]

@Geralt,

As I've suggested before anyone wanting to use an ADC module should not be viewing it as an appliance. They must get the datasheet for the specific ADC IC and understand how it works. The AD7791 on the PMODAD2 is a good illustration of my point. The data sheet headline advertises a 4 channel ADC with a (typical) 1 uS conversion time. Sounds perfect right? But then you look at the specification for the data throughput rate. This is 1/(3.4 MHz x 17.5 + 2 uS) = ~140000 samples/s. And the absolute maximum SCL clock rate of 3.4 MHz requires a capacitive load on the digital signals < 100 pF. As an exercise verity this yourself. Look at the I2C data format. Then keep reading...

One thing that I have done is use an ADC evaluation board with an FMC connector and one of my FPGA boards. Some of these aren't very expensive but again you need to know what exactly you are buying before handing over your money.

 

[Geralt]

10 hours ago, Notarobot said:

@Geralt

1. I used Zybo only for proof of concept then I switched to the Avnet MicroZed and PicoZed boards which provide access to PL via expansion connectors. They also sell a prototype carrier card and one very elaborate FMC carrier board.

The normal ZedBoard (bigger size than MicroZed) also provides those expansion connectors, right? Do they have a specific name (e.g. FMC)?

Thanks @all so far!

[Notarobot]

@Geralt

1. I used Zybo only for proof of concept then I switched to the Avnet MicroZed and PicoZed boards which provide access to PL via expansion connectors. They also sell a prototype carrier card and one very elaborate FMC carrier board.

2. Achieving "simultaneous" (within ns) sampling is absolutely possible because properly designed boards have equalized propagation on all IO traces and FPGA timing tolerances can keep propagation inside the chip very tight.

3. SD card can be easily utilized by the processor because Xilinx provided free IP. WIth it I got writing speed around 11 MB/s. Commercial IP promised 25 MB/s but I didn't test it. Latencies and delays depend on the architecture but at your data rates shouldn't pose a problem. In my case because of much higher data rate I was forced to test and benchmark every operation to find bottlenecks. SD card requires a whole chapter to discuss but I have to tell that it is reliable; extensive data validation showed no data losses

4. To ensure deterministic performance and due to unavoidable latencies I used only VHDL and C for programming in a standalone ARM environment.

5. In my opinion CAN is the best / easiest data transfer option. All IP is provided by Xilinx, all programming requires several subroutines in C and one extra breakout board for physical external interface. With standard protocol Zynq can transfer about 66 kB/s (1 Mbit/s connection speed).  It is very reliable and 2-wires only.

Good luck!

[hamster]

As a side issue, I recently did something that had similar data requirements - capturing 2-bit samples at 16,386MHz (32Mb/s) for an extended period of time (many minutes)

I used an older NEXYS2 board because it has the Digilent EPP interface, that can stream at well over this speed.

- A simple HDL design captured the data, wrote it into a FIFO with a sequence counter bit so I could detect dropped data

- Some more HDL read the FIFO, and sent the data up the EPP interface to the host PC.

On the PC it then:

- Allocated a large buffer (a couple of GB IIRC)

- Cleared the buffer to force it into memory, so it woudn't stall

- Streamed in the data from the EPP interface

- Once data was in buffer on the PC it was written to the slow disk SATA 

I had to buffer it in memory, because a small delay on the PC end would cause the FIFO on the FPGA board to overrun. I could have most likely used a second thread to write the data in real time if I needed to.

It ended up being a very small simple design when compared to what you are contemplating. Have a look at https://github.com/hamsternz/Full_Stack_GPS_Receiver/tree/master/misc 

[Geralt]

4 hours ago, Notarobot said:

For prototyping I've used Zybo board with three Pmod-AD1 each combining two 12-bit ADC chips.

Do you know if the Zybo board provides any additional GPIO connectors apart from the Pmod ports? The ZedBoard has an FMC connector in addition to the Pmod connectors but the Zybo does not seem to have anything apart from Pmod.

4 hours ago, Notarobot said:

I am wondering what is the benefit of switching from microcontrollers to Zynq, higher DAQ rate?

As I wrote in the previous post: Higher rates for data transfer and sufficient RAM for buffering if there is latency (or breaks in writing cycles on the SD card) in the data transfer. Unfortunately, you have far less peripherals than on MCUs.

[Notarobot]

@Geralt

In addition to very valuable consideration by @xc6lx45 and @zygot I'd like to share some of my experience in multi-channel ADC on Zynq at much higher speed.

First of all It is definitely durable and cross-coupling can be made a on issue. However, it depends on your requirements and implementation.

I used a combination of both FPGA and ARM processors on Zynq 7010. ARM were utilized for data storage, communication (CAN, RS232) and control while FPGA did parallel data acquisition and control of ADC chips. Everything was done using one ARM processor running under barebone realtime environment. I've tried XADC at 1 MHz sampling rate and abandoned when realized that amount of load it would put on the processor won't leave any resources for my other tasks. The beauty of FPGA that it does wonderfully multiple routine operations in parallel and releases the processor for math, data management and communication. 

For prototyping I've used Zybo board with three Pmod-AD1 each combining two 12-bit ADC chips. All were sampled at the same frequency, however, you can skip as many acquisition periods as you want. Single frequency simplifies FPGA implementation or, specifically, timing constraints. Although at 100 kHz rate it shouldn't be difficult. The key issue in this project was finding an optimal architecture applicable to Zynq. Writing and testing of the VHDL programming code was on the second place.

With that said you may find that multiplexing of XADC will meet your requirements. As far as I know most of TI motor controllers use multiplexing of analog sensors. This way you will minimize the need for HDL programming and save on development time, possibly.

I am wondering what is the benefit of switching from microcontrollers to Zynq, higher DAQ rate?

[xc6lx45]

9 hours ago, Geralt said:

I thought that this would be an easy part. I have not worked with these boards and ADCs before (mostly with microcontrollers) but I thought that you simply send a "start of conversion" signal to any ADC, external as well as internal. Or you keep those ADCs running continuously and just sample the output registers with the desired sampling frequency. I do not have an idea which problems you are addressing in your post.

If you're planning to sell 1k+ units, consider using the XADC. Otherwise, the effort isn't worth it. Instead, three PMOD boards with six identical channels seems the better alternative.

[zygot]

@Geralt,

You can access the XADC through the DRP in the PL or, I believe, from the PS. You'll have to go through the documentation to see if it's possible to start conversions at the same time in the XADC and external PMOD modules. I doubt that the conversion time for the XADC and any external ADC IC is the same so getting concurrent samples is unlikely, or at least non-trivial as I see it. The ADC clocking certainly won't be the same. The devil, as they say is in the details, and you will have to handle both. Xc6ls45 seems to think that this can be done. I haven't tried. I do know that offering suggestions without actually going through the exercise of a full design effort is a good way to lead someone astray. To have a chance at taking near simultaneous samples on 6 channels you will likely need to operate all of your ADCs from logic in the PL. Think about using one sample rate and decimating the low Fs channels to get to a 1 KHz sample rate. You might be able to throw away samples or do an integrate and dump. There's always the possibility of making your own analog acquisition board...

If you have experience with Zynq based boards then by all means use what you are familiar with. If you have good competence with HDL development then the Zynq might be superfluous. Regardless, you will need to do some HDL design to implement the encoders and run the ADCs. There are FPGA boards with SDRAM or DDR RAM that aren't Zynq based. You might have difficulty with the SDRAM or DDR controller and this is an area where the Zynq does make things simpler. The boards from Digilent ( and there are many on the list ) that I have experience with are older and probably more expensive than the cheaper Zynq boards that you are considering and I hesitate to comment or recommend anything that I don't have experience with. The only Zynq based board from Digilent that I know well is the Zedboard. It's been a while since I've spun out a project based on the Zedboard however.

Again, you have more information about your requirement than I do so I can only offer arms length general guidance.

[zygot]

Clearly any reference to "simultaneous sampling" is not an absolute but depends on what you are measuring and how you intend to use the measurement data. The questioner hasn't provided details about that, nor is it necessary to do so as long as he does the analysis correctly.

In the case where the analog signals being measured have a very low source impedance relative to the circuitry doing the measuring and the signal amplitude is fixed then it is possible that using a resistor network to present a scaled amplitude to the ADC is suitable. Usually analog conversion is done with a very high input impedance so that the signal being measured isn't affected. As long as you know what you are doing and test the whole measurement setup properly there are a number of options. It depends on the project and how accurate the measurement have to be. There are a lot of things to consider that might not be obvious. I just thought that introducing a few of them might be relevant to the discussion.

[xc6lx45]

1 hour ago, Geralt said:

Of course you can never achieve "simultaneous" sampling. There is always some nanoseconds delay/difference. At some point you even have to consider the signal propagation of the clock or convert signal over the PCB conductors. But I think if we use separate ADC peripheral boards and those two XADCs, we could firstly solve the problem of inter-channel-coupling and secondly achieve a sampling pattern that is "quite simultaneous". I think (or better hope ) that this will not make a big difference since the input signals are limited in their bandwidth far below the sampling frequency.

Well, in practice you can, with an accuracy much better than ADC specs. The XADC even has a dedicated mode for that, and with external ADCs it's fully under my control when I generate the CS signals (which trigger conversion). Now if your signal is heavily oversampled, it shouldn't be that critical. Just don't try to demodulate 1024QAM...

Note that your sampling interval is 1000 ns at 1 MSPS, so there are opportunities to screw up timing in ways that would be impossible with transmission lines alone

Scaling the voltage down is easy, just use a resistive divider. E.g. use CMOD A7 schematics. Keep in mind, the source resistance should be fairly low, see XADC doc for recommendations. The PMOD schematic has a nice looking opamp circuit for analog filtering.

 

[zygot]

@Geralt,

I keep forgetting to mention this. I didn't notice a justification for an ARM or even a soft core processor in your requirements. If all you want to do is capture multiple channels of data over a period of time, store it in a buffer, and transfer it to a PC with no minimum time requirement then you can do this with any FPGA board having sufficient external memory resources. An all HDL implementation might be a whole lot less complicated and faster to execute, provided that you and your colleagues are proficient in HDL development. Given the project as described that's the approach that I'd take.

[zygot]

@Geralt

2 minutes ago, Geralt said:

But I think if we use separate ADC peripheral boards and those two XADCs, we could firstly solve the problem of inter-channel-coupling and secondly achieve a sampling pattern that is "quite simultaneous".

I'd agree, though it's up to you to do the analysis as to your project requirements with regard to measurement phase coherency and accuracy. I've been looking at the AD7476A datasheet to do a rough assessment of @xc6lx45's suggested PMOD ADC boards. It might be fine though I don't know how to synchronize the XADC to external ADC modules. I'm a bit bothered about using an ADC which uses the SPI clock as a SAR clock... don't know. Usually ADC accuracy is dependent on having a very pristine clock. Using a logic derived signal required to implement the SPI interface is not ideal... but again I don't know that it's a an issue for you.

14 minutes ago, Geralt said:

Python would most likely fail feasibility, invalidating the nice top-down plan already on square one.

I don't agree that this statement is necessarily true but you could certainly design a system in which it is. Of course there are a lot of ways to get things wrong and only a few to get everything right in engineering.

[Geralt]

5 hours ago, xc6lx45 said:

The mistake is planning for a simple implementation "project" when most of the work time is actually a "technology study" or even several. E.g. do you have the "technology" to drive ADCs, to store data in DRAM, to provide Ethernet access without dropping samples on incoming packets. If I'd approach this bottom-up, Python would most likely fail feasibility, invalidating the nice top-down plan already on square one.

 

Thanks for the hint. That is why I discarded the Python (PYNQ-Z1) approach. I will now consider using one of the ZedBoards/MicroZed/Zybo. I think they provide a lot more flexibility and overhead in terms of connectors and computational power.

12 hours ago, zygot said:

Well, no. Now, if you have multiple ADC peripheral boards that you supply the clock and a CONVERT strobe that begins the conversion process on demand there might be some hope for "good enough more or less simultaneous" multi-channel ADC capture. Unfortunately specifying ADCs is not a trivial pursuit; there's a bit of an art to weeding through vendor datasheets to get vital information, and the vendors want to sell chips so they don't make it easy. Trust me, I speak from experience. Usually the multi-channel low conversation rate ADC are SAR types. A few of these have independent ADCs for each  channel. Some have analog sample and hold circuitry to more or less allow "simultaneous" conversion of all of the channels. Others have programmable channel sequencer logic to schedule which channels get sampled and when. Finally, multi-channel ADC ICs have some level of inter-channel coupling of input signals. This can range from not too bad to very significant. It can get complicated and be very time consuming to choose your ADC design. On top of this you should be aware that most ADC applications require some sort of front-end conditioning. For best results you want the maximum signal voltage going into the ADC to be very close to the maximum input voltage specification of the ADC. This is to preserve the dynamic range of the ADC. That is, if your signal is never greater than half of the input range then you are losing 1 msb of digital dynamic range. Also, there are anti-aliasing filters ( some ADC device offer programmable digital input filtering ). None of this is meant to discourage you... just to provide food for thought. ( For real world commercial applications the analysis and number of specs to weed through gets a lot more complicated and includes choosing a ADC architecture appropriate to the task at hand. )

Perhaps the simultaneous sampling of 3 1KHz and 3 100 KHz signals isn't really a requirement. But perhaps you can now understand why instruments that do capture and record multiple analog channels can become expensive.  

Of course you can never achieve "simultaneous" sampling. There is always some nanoseconds delay/difference. At some point you even have to consider the signal propagation of the clock or convert signal over the PCB conductors. But I think if we use separate ADC peripheral boards and those two XADCs, we could firstly solve the problem of inter-channel-coupling and secondly achieve a sampling pattern that is "quite simultaneous". I think (or better hope ) that this will not make a big difference since the input signals are limited in their bandwidth far below the sampling frequency.

We would have to manufacture some addtional hardware anyway to linearly scale the voltages into the input voltage range of the pins (which is quite small for the XADC to be honest). So adding hardware for signal-conditioning would not be a task that requires much greater effort I think.

[xc6lx45]

Digilent PMOD AD1 comes to mind (haven't tried it myself).

https://store.digilentinc.com/pmod-ad1-two-12-bit-a-d-inputs/

I think I can plug two of them into one 12-pin PMOD connector => 2x2 channels.
Never mind what marketing says - "excels even in the most demanding audio applications". 12 bit is so much better than 8 bit

A word of warning:
The "top-down" approach (start with choosing hardware by specs and tools scope e.g. Python) may seem logical. But all too often, people realize only late that the pyramid gets very wide at the bottom and what looked like three hours takes a month or is impossible. The mistake is planning for a simple implementation "project" when most of the work time is actually a "technology study" or even several. E.g. do you have the "technology" to drive ADCs, to store data in DRAM, to provide Ethernet access without dropping samples on incoming packets. If I'd approach this bottom-up, Python would most likely fail feasibility, invalidating the nice top-down plan already on square one.

 

[zygot]

3 hours ago, Geralt said:

Concerning data transfer: If I buy a board with 1 GB RAM, I should be able to dump all the measurement data of about one whole minute into the RAM. After finishing the measurement, the data could be transferred from RAM to the PC. That could either be done by UART, Ethernet or even an SD card, because after finishing the measurement I do not need any real-time performance anymore.

So, for most Zynq boards the DDR Ram is attached to the ARM core(s) and is used by the OS or whatever minimalist software the cores run on. A few Zynq boards also have additional DDR RAM connected to the PL. If you are using one of these then you would have a nice buffer entirely reserved to store a large dataset. If you can reduce the data in real time the storage problem might go away.

Now to the harder issue:

3 hours ago, Geralt said:

So if I would need to sample all the six analog signals simultaneously, I could use the two XADC modules and four additional ADC cards that I connect at those Pmod ports of the development board.

Well, no. Now, if you have multiple ADC peripheral boards that you supply the clock and a CONVERT strobe that begins the conversion process on demand there might be some hope for "good enough more or less simultaneous" multi-channel ADC capture. Unfortunately specifying ADCs is not a trivial pursuit; there's a bit of an art to weeding through vendor datasheets to get vital information, and the vendors want to sell chips so they don't make it easy. Trust me, I speak from experience. Usually the multi-channel low conversation rate ADC are SAR types. A few of these have independent ADCs for each  channel. Some have analog sample and hold circuitry to more or less allow "simultaneous" conversion of all of the channels. Others have programmable channel sequencer logic to schedule which channels get sampled and when. Finally, multi-channel ADC ICs have some level of inter-channel coupling of input signals. This can range from not too bad to very significant. It can get complicated and be very time consuming to choose your ADC design. On top of this you should be aware that most ADC applications require some sort of front-end conditioning. For best results you want the maximum signal voltage going into the ADC to be very close to the maximum input voltage specification of the ADC. This is to preserve the dynamic range of the ADC. That is, if your signal is never greater than half of the input range then you are losing 1 msb of digital dynamic range. Also, there are anti-aliasing filters ( some ADC device offer programmable digital input filtering ). None of this is meant to discourage you... just to provide food for thought. ( For real world commercial applications the analysis and number of specs to weed through gets a lot more complicated and includes choosing a ADC architecture appropriate to the task at hand. )

Perhaps the simultaneous sampling of 3 1KHz and 3 100 KHz signals isn't really a requirement. But perhaps you can now understand why instruments that do capture and record multiple analog channels can become expensive.  

[Geralt]

Thank you very much for the answers!

 

So the XADC can sample up to 8 different signals per ADC. Because it is dual that would result in 16 different signals maximum. But because of the interleaved sampling (one signal after another) you would not reach 1 MSPS, but only 1/8 MSPS (but two signals sampled simultaneously each time). Did I get that right? So if I would need to sample all the six analog signals simultaneously, I could use the two XADC modules and four additional ADC cards that I connect at those Pmod ports of the development board. That should work, right?

Do you know whether those development boards have connectors with simple digital GPIOs for the encoder signals and the quadrature frequency signal? I mean pins apart from the Pmod ports that would all be occupied if I connect ADC cards to them.

Concerning data transfer: If I buy a board with 1 GB RAM, I should be able to dump all the measurement data of about one whole minute into the RAM. After finishing the measurement, the data could be transferred from RAM to the PC. That could either be done by UART, Ethernet or even an SD card, because after finishing the measurement I do not need any real-time performance anymore.

What would you say to this approach?

 

Best regards!

[zygot]

1 hour ago, Geralt said:

But those examples always included coding in VHDL. Is it possible to program the Zynq-7000 in Python with the same degree of freedom as in VHDL?

@Geralt,

You can use Python to execute applications on the Zynq provided that you boot into an OS that supports Python. The Zynq supports full RTOS and OS functionality but going this route is not trivial. Your OS could be a full-blown Linux, RTOS or a carefully crafted set of tools created by Pokey or some other means. Usually applications are coded using the Vivado SDK flow using C/C++. The Xilinx SDK tools are very good for most application code.

VHDL/Verilog would be used to create logic functionality in the Zynq PL. Creating encoders in logic that resides in the PL is an ideal way to use the Zynq device. Of course, you need to learn how to bridge the PL data to the PS side. HDLs are not alternatives to Python or C or any other computer language and you need to learn a different work flow and different concepts to do what is essentially digital design using the PL.

As for using the Zynq internal XADC I highly recommend that you read and understand the Xilinx documentation on how to use the XADC. It is designed to sample multiple channels of analog input but not simultaneously. Understand how to set this up and what the limitations are.

As to using the Zynq as a socket server or other means to communicate to an external device this is also not trivial but has been done. I don't know of any end to end projects that show a newbie how to do this.

[xc6lx45]

Hi,

one key question is whether you need phase-accurate sampling (same sampling instant). In that case, no, because there are only two ADC cores, and channels are interleaved in time.
It's unlikely but I thought I should mention it (for communications it's a killer, or at least requires additional DSP to set it straight)

However, to my knowledge the XADC has an internal 1:8 analog mux for each ADC, routing a total of 16 channels out of the package (from Artix, please double-check for Zynq).
Each ADC may sample 1 MSPS, so in theory (and coded in Verilog), no big deal.

The analog channels are assigned to specific package pins, and it's up to the board whether or not to route them to outside pins (you need to provide a reference voltage to the "-" pin also for single-ended operation. Check XADC reference page 31/32). In most schematics, they have _AD_N and -P in the FPGA pin name so they are easy to spot.

If Ethernet works out of the box, it seems easy. The question is, how low round-trip latency is necessary and how much jitter does the PC end introduce.
With an FTDI chip on the board I can comfortably run at the 8 kHz USB framerate limit (MPSSE mode on the FTDI chip) but it's nothing to be written in a day.

The "incremental encoder", "frequency detection" sound like straightforward RTL tasks. If such a thing exists.