You can refer to the below application notes and examples for getting started and post any question here.
We will help you through the development.
Thanks for the help! Before I get started I wanted to ask if what I am trying to do is reasonable or if you think there's a better way to do it. I'm trying to avoid FPGA if possible for simplicity reasons, not so much cost. I could also consider PSoC, CX3 etc. if you think there's a better fit.
Host CPU (Windows 10) will write bitmap image data via the FX3 SDK (Visual Studio/C#) to the FX3 over USB3. FX3, via a custom GPIF II interface, will output a video stream (it's the exact same output timings from this thread: Cypress USB 3.0 to RGB888 parallel 24 bit output) to a downstream video device.
It would be a 32 bit GPIF II interface (of which we will only use 24 bits) at 100MHz pixel clock from the FX3.
I need the FX3 convert something like 25 bitmap images per second. Each bitmap is about 4 million pixels (24 bits per pixel of course) This puts us in the 25 * 4 Mb ~100 Mb/sec throughput ballpark which I think is OK for FX3?
The image pixel size will always be the same size but I would like to be able to change the size if needed via firmware changes (e.g., 1920X1080, 2560X1600 etc. subject to throughput constraints of course), but the video interface and timings will be the same.
I don't need the timing to be super-accurate: once the data from a complete image is loaded in to the FX3 bufffer(s), FX3 outputs that data (in video format) and waits for another data set to fill up the input buffer--it may be hundreds of milliseconds in this wait state or it may be as fast as I can get the data from the host CPU to the FX3.
I was thinking that a double buffer would be used like in AN75779 except that AN75779 is going from Video Data→FX3→Host CPU and I want to go Host CPU→FX3→Video Data (the timing/protocol of the MIPI and the video I want are very similar).
Do you see any show stoppers here? I had planned on using the state machine in AN75779 as a starting point and then designing it to "go backwards"--is this a good idea? Any other general guidance would be greatly appreciated.
This one's going to be much more fun than our USB→Serial work
This is Venkat Subbiah from Packet Path(www.packetp.com). We are just finishing off a project where we have interfaced FX3 with an Altera Cyclone5 FPGA and we are well versed with FX3 and GPIF interface. Please email me on firstname.lastname@example.org if you are looking for a consultant.
FX3 is best suited for this application as the GPIF is easily configurable as needed.
FX3 GPIF II can operate at 100 MHz , which is capable of transmitting at max speeds of 2400Mbps (100M*24bits per sec), when 24 bit data bus is used.
The state machine of AN75779 will need changes.
1. Configuration of FX3 as Slave
2. Internal Clock generation
3. Data width and related changes
4. control signals.
The DMA channel direction needs to be changed where P-port will be consumer and U-port will be the producer.
AN75779 is based on UVC class framework, the descriptors and the firmware needs to be modified as required by your application.
You can also refer to USBBulkSourceSink firmware example and the streamer application from the FX3 SDK to test the streaming bandwidth.
OK this sounds like a good fit...two more questions:
1. What kind of USB3 latency will I see for each transaction that writes a chunk of data (in this case a bitmap image) to the FX3?
2. Once the FX3 input buffer is full I assume we will only need some small number (~10) of clocks for the FX3 to start the output on the clock + data bus?
Yes, If there is no need to alter the data that is sent from host to FX3, then you can use a AUTO channel to reduce the delay and commit the data to the interface automatically.
The delay incurred from the host side needs to be tested. But at 3.0 speeds and maximum transfer sizes, the delay will be too low.