Interfacing peripherals that run on different clocks.  - Page 1
Forum section: electronics / general

author: rokspy
author_rank: Contributor
timestamp: April 01, 2023, 07:25:54 pm
content: Hey,So I have a board that has a camera outputting pixels at 96Mhz rate, SDRAM that runs on 143MHz , and a Cyclone IV EP4CE22E22C6 to whom the peripherals are connected to. The goal is pretty straight forward - transfer data from the camera to SDRAM. The FPGA has some amount of internal RAM memory, but not enough to store the whole image. What would be the best way to approach this problem? At the moment I'm thinking of inferring a dual port dual clock RAM on the FPGA as a buffer between these two peripherals, where one side can only write and the other side can only read + additional communication to control this interface.I was also thinking of some request signal from the camera controller side, where the rising edge would indicate new data, and then the SDRAM could do one write and wait for the next rising edge, but this is not really optimal as SDRAM could go into refresh state and will definitely miss data, and would not really work in case when I would want to read from the SDRAM.Thanks for your suggestions in advance!

author: ejeffrey
author_rank: Super Contributor
timestamp: April 01, 2023, 07:35:30 pm
content: A dual clock FIFO is probably more appropriate for this task. Its constructed from a dual clock SRAM block with additional handling for synchronizing the read and write pointers safely. You can also package your data into an Avalon-ST stream (which also has signals for framing) and then use a Avalon clock converter although that isn't necessarily easier than just using a FIFO unless you are interfacing with other modules that have Avalon interfaces.

author: rokspy
author_rank: Contributor
timestamp: April 01, 2023, 08:29:35 pm
content: Yes, FIFO seems exactly what I need. Just checked, Quartus provides IP for it as well, pretty much with the configuration options I need. I tried implementing something like this myself, successful with lower frequencies and in sim, but ran into timing violations with higher frequencies, should have checked the IPs before...

author: AK6DN
author_rank: Regular Contributor
timestamp: April 02, 2023, 12:25:46 am
content: Take a look at this documentation:https://www.intel.com/content/www/us/en/docs/programmable/683522/18-0/fifo-user-guide.html

author: AndyC_772
author_rank: Super Contributor
timestamp: April 02, 2023, 07:02:26 am
content: Unless this is for a one-off hobby project, check availability on that device right now. That whole family has been 'on allocation', ie. completely unavailable, for the last couple of years. It's not officially discontinued, but it might as well be.I wouldn't be putting any more effort at all into developing with that family - use your time to pivot to a new FPGA vendor.

author: rokspy
author_rank: Contributor
timestamp: April 08, 2023, 09:12:50 pm
content: Nah, nothing related to industry and mass production. It's a university level project (student satellite), where already did the board, but just have to do the actual implementation on the FPGA. The availability of the chip is a pain, though, we literally have 2 chips in stock and that's it...

author: rokspy
author_rank: Contributor
timestamp: April 08, 2023, 09:33:04 pm
content: Update: The FIFO IP worked as planned. Can easily do peripheral-peripheral or peripheral-system interface. Writing and reading from SDRAM also works with FIFOs and is consistent with the sim. There are some minor issues during READ (data multiples when buffer is full, or out of order data access after changing the active row), but they seem more related to my own implementation.. Thanks yall

author: BrianHG
author_rank: Super Contributor
timestamp: April 09, 2023, 12:57:51 am
content: You can also use dual clock, dual port block memory and implement your own read and write counters/pointers on each side, with 1 or 2 enable/block ready signals which cross the clock domain. This is actually what the dual clock FIFO actually is, but now you have an additional degree of control for random read or random write pointers. Or, reserve memory elements for special auxiliary functions.