Need help selecting a microcontroller or FPGA

[EggertEnjoyer123]

The ftdi_readstream function (with some modifications) was used to read the data streaming from the board.

Is it a blocking call with 100% cpu-load, as ftdi like to do? Is it "libftdi library" communicate with driver directly (I need) or use dll from ftdi as superstructure?

I am using the open source libftdi1 library: https://www.intra2net.com/en/developer/libftdi/index.php
I'm fairly sure that the call blocks, which is why I'm running it in another thread in my C code.

Adapted from fastftdi.c - A minimal FTDI FT232H interface for which supports bit-bang mode, but focuses on very high-performance support for synchronous FIFO mode

How?? I totally failed to use synchronous FIFO mode from ftdi! It's interrupted stream when reload command! I succeded with asynchronous for non-interrupted receive.
...
EggertEnjoyer123, in your file -
https://github.com/EnPassant123/FMCW_radar_2/blob/main/c/ftdi_stream_modified.c
- written clear:

Use asynchronous transfers in libusb-1.0 for high-performance streaming of data from a device interface back to the PC.

Why do you use synchronous mode later in text?

That part was copied from the libftdi1 source code. If you couldn't get synchronous mode to work, here's some things to check:
1. Make sure SIWU is high. If not, there will be no data sent over.
2. There is a bug in the libftdi1 source code. This line has been changed:

Code: [Select]

struct timeval timeout = { (ftdi->usb_read_timeout / 1000), (ftdi->usb_read_timeout % 1000) * 1000};The original code has:

Code: [Select]

struct timeval timeout = { 0, ftdi->usb_read_timeout * 1000};With my FTDI setup, the timeout was 5000, and because the timeval struct can't have values >=1000000 for the microseconds element, the original code wouldn't work. My new code correctly fills in the timeval values. The asynchronous transfers thing is just for libusb (which is a library on the computer side), and it only affects how the computer processes the samples. The FTDI chip is still reading/writing data on a 60MHz clock.

[Postal2]

If you couldn't get synchronous mode to work, ...

I could. I tried to capture IR remote with synchronous mode and it's absolutely impossible because gaps. You cannot use this mode for continuous streaming from real-time devices like adc. You will see input data correctly, but cannot be decoded because broken timeline.

                    if (ftdi_set_bitmode(ftdi,  0xff, BITMODE_SYNCFF) < 0)
                    {
                        fprintf(stderr,"Can't set synchronous fifo mode: %s\n",
                                ftdi_get_error_string(ftdi));
                        goto cleanup;
                    }

- this mode cannot be used.

[EggertEnjoyer123]

If you couldn't get synchronous mode to work, ...

I could. I tried to capture IR remote with synchronous mode and it's absolutely impossible because gaps. You cannot use this mode for continuous streaming from real-time devices like adc. You will see input data correctly, but cannot be decoded because broken timeline.

                    if (ftdi_set_bitmode(ftdi,  0xff, BITMODE_SYNCFF) < 0)
                    {
                        fprintf(stderr,"Can't set synchronous fifo mode: %s\n",
                                ftdi_get_error_string(ftdi));
                        goto cleanup;
                    }

- this mode cannot be used.

You can use it if you use a FPGA to synchronize the ADC output with the 60MHz clock, like I did. Otherwise, if you're just trying to run it constantly at 60MHz it wouldn't work because of dropped packets.
The reason why packets are being dropped is because you are operating too close to the 480 Mbps limit (realistically maybe 300 Mbps can be done at best). If you use a FPGA you can get away with a much lower data rate which means no dropped packets. 

Basically synchronous mode works, but if you try to hold the WR line low to force it to constantly write, it would drop packets because you're running at the theoretical limit for USB ( 60MHz * 8 ). For your application the FT232 is probably not needed, you can just use a microcontroller to time the pulses from the IR sensor, and then report the value back through UART.

[Postal2]

You can use it if you use a FPGA ...

Oh, sorry, I missed the FPGA. FPGA is good when enough buffer in it, it will compensate glitches from ftdi. FX2LP could be more reliable for your purposes, it was bad advice to use ftdi.

For your application the FT232 is probably not needed...

My application is small chunk of other application, where you can work with eMMC via FT232H (even FT232RL) including. You won't be able to find similar therefore my application widely used.

[EggertEnjoyer123]

It would be difficult to just blindly sample at a fixed clock rate using the FX2LP. Because the ADC clock is not synchronous to the FX2LP's clock, a situation where the FX2LP samples at an edge (which causes metastability) could occur. The FPGA is able to fix this issue by sampling the ADC clock at 60 MHz, and then detecting edges, allowing it to figure out when the ADC data being output is valid. The FX2LP, which just blindly samples at 24 MHz, can't do that.

Here's an example of what could happen if you just blindly sample the ADC output at 24 MHz. The orange arrows are when the FX2LP samples. The black line is the ADC clock and the green represents the data. When the FX2LP samples on the falling edge of the ADC clock, the data may not have settled yet. In my example this is shown by the FX2LP reading 0x04 instead of 0x00 on the transition (since perhaps the 3rd bit is slower than the other bits). This would lead to bad samples showing up in the data. There is no easy way to detect such a situation too, since reading the clock wouldn't work. At the edge, the value the FX2LP reads is undefined, and it could be either 0 or 1.

[NorthGuy]

The FPGA is able to fix this issue by sampling the ADC clock at 60 MHz, and then detecting edges, allowing it to figure out when the ADC data being output is valid.

Typically you would bring ADC clock inside FPGA and use it for sampling ADC data. Then you would cross to FTDI clock domain with FIFO or otherwise.

[EggertEnjoyer123]

The FPGA is able to fix this issue by sampling the ADC clock at 60 MHz, and then detecting edges, allowing it to figure out when the ADC data being output is valid.

Typically you would bring ADC clock inside FPGA and use it for sampling ADC data. Then you would cross to FTDI clock domain with FIFO or otherwise.

FIFO is too complicated and consumes too many LUTs probably (I only have 1100). A simple double flop works since 14.4 MHz is slow enough compared to 60 MHz. (The data_valid signal is basically constantly high, so I don't really care about double flopping it)

Code: [Select]

...
  always @(posedge clkadc) begin
    data_valid = data_ready;
    data_buf = datain;
  end
 
  always @(negedge clkusb) begin
    clkadc_2 <= clkadc;
    clkadc_3 <= clkadc_2;
    if (state == 0 & clkadc_2 == 1 & clkadc_3 == 0 & data_valid) begin
      ...
      dataout = data_buf; 
      ...   
    end
    ...
  end


[NorthGuy]

A simple double flop works

It's a good idea to put data through flip-flops too. Otherwise, the data you're sampling is somewhat later than the clock edge you have detected. Probably not a big deal at these speeds, but still.

[Postal2]

... Because the ADC clock is not synchronous to the FX2LP's clock, a situation where the FX2LP samples at an edge (which causes metastability) could occur. ...

See datasheet. Is my understanding correct?
...
Need to reduce sample rate, need to be practical. When using usb HS, need to be oriented to 8MB/sec. It's irrelevant, you can use 100 fpga-chips, but when send raw data you cannot be faster than FX2LP.

[EggertEnjoyer123]

... Because the ADC clock is not synchronous to the FX2LP's clock, a situation where the FX2LP samples at an edge (which causes metastability) could occur. ...

See datasheet. Is my understanding correct?
...
Need to reduce sample rate, need to be practical. When using usb HS, need to be oriented to 8MB/sec. It's irrelevant, you can use 100 fpga-chips, but when send raw data you cannot be faster than FX2LP.

That mode doesn't support 4 channels at 1.2 or 1.8 MSPS. (See page 42).
In any case even if I was able to get it to work with the FX2LP, it would be impossible to also run a DAC at the same time with that chip.

[Postal2]

That mode doesn't support 4 channels at 1.2 or 1.8 MSPS. (See page 42).

I saw. Parallel mode below, synchronisation can be resolved same way.

... it would be impossible to also run a DAC at the same time with that chip.

I didn't go deep into the project, I don't understand what job the DAC do. May be simple cheap programmable oscillator can do the job. Control data can be given from FX2LP in that case.