- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all!
My FPGA (CycloneII) is a slave on an MCUs external bus interfaces (EBI). The MCU shall read the content of FPGAs embedded RAM preferably without wait state. Unfortunately I don't know yet now to get the logic fast enough. The EBI is operated at 60Mhz and the FPGA has a 166.7Mhz clock. I've used the FPGA clock to clock the RAM. The address lines are permanently connected to the RAM. The Output to the EBI is done using unclocked logic. Using SignalTap I can see, that data from the RAM is updated one clock cycle after address changes. But the data needs an other clock cycle be be visible for the MCU. So I guess, there are some timing constraints missing between the FPGAs clock and the data output pins. I've studied AN433 but didn't found the point. Can anyone please advice now to speed-up the interface? Thank You! PaulimanLink Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You mention the MCU requiring the data to be presented for another clock cycle - is that right? If so, it's not timing constraints that's the problem - it'll be the logic.
You will need to configure your MCU in a way as to postponing changing the RAM address and read selects for an additional clock cycle. If it was a Nios processor, external peripherals can be configured to add 'wait states' while the peripheral gets the data ready. Is that not what you need?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are probably doomed to fail.
To avoid metastable issues you need to synchronise the address lines to the fpga's clock. This requires at least one additional clock delay that you haven't allowed for. This means that you actually need to generate a 60MHz clock on the fpga that is phase synchronous with the 60MHz EBI clock, and then use that clock to latch the addresses into the internal memory block. Doesn't help you find the latch in the read data path though. Are you sure your problem isn't an additional latch in the addresses?
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page