FPGA to microprocessor external memory interface

[vandelay]

Hi,

I am working on a circuit layout where I need to integrate a microprocessor to an FPGA (Xilinx Spartan-6), and the microprocessor hardware resources available to me is an external memory interface (capable of both SDRAM and SRAM). Now, the FPGA is there to provide I/O peripheral resources, likely a dozen or so of SPI-like ports (plus UART and PWM), it will take care of sending and recieving data between external devices and internal memory much like a DMA, and for programming convinience I’d like to treat it as some sort of RAM from the microprocessor (to read and write memory buffers on the FPGA as if it was a regular memory). The data bus is 16-bit wide, separate address pins (no address/data multiplexing).

I am new into the field of FPGA so I have to ask: Which signals will be needed for this? Can I use a static RAM (SRAM) interface, or will it be better to use extra support pins and interface it as SDRAM? Also, it would be great to know the reason for the suggestion given.

Dunno if it is useful information, but the microprocessor has two memory interfaces where external processor memory goes on the other interface, so the FPGA has an entire bus all to itself, with short traces and great signal integrity.

Sincerely,
Kjetil

 

[Beetroots]

Either, SDRAM may give you a higher data bandwidth. Is the FPGA clocked of the same clock from which the processor bus timings are derived? If not (data inputs to the FPGA are asynchronous to it's clock) then you'll have to synchronize the inputs to prevent metastability problems (pass them through a couple of d flops clocked by the fpga clock).

Just for interest, which processor is it?

 

[rberek]

Most processor interfaces are SRAM-like. Data, Address, a Chip Select and a Read/Write flag are all that are normally required for the simplest interfaces.

SDRAM interfaces are more complicated and you have not described any behaviour that warrants the added complexity of an SDRAM interface.

r.b.

 

[vandelay]

Thanks a lot for your replies guys.

Either, SDRAM may give you a higher data bandwidth. Is the FPGA clocked of the same clock from which the processor bus timings are derived? If not (data inputs to the FPGA are asynchronous to it's clock) then you'll have to synchronize the inputs to prevent metastability problems (pass them through a couple of d flops clocked by the fpga clock).

Just for interest, which processor is it?

As the current design stands, the FPGA is asynchronous to the processor, it has its own oscillator. Processor is an Texas Instruments OMAP-L137 (one 300MHz fixed/float DSP core + one 300MHz ARM926EJ-S core). Just for the record, in case you'd dig into the datasheet, there is indeed a parallel interface multiplexed on the same pins I'm using (called UHPI, Host Port Interface) that could do the FPGA interface, but I've opted to aim for the external memory interface instead.

Most processor interfaces are SRAM-like. Data, Address, a Chip Select and a Read/Write flag are all that are normally required for the simplest interfaces.

SDRAM interfaces are more complicated and you have not described any behaviour that warrants the added complexity of an SDRAM interface.

r.b.

OK, so besides D[0..15] and A[0..n] I would need CS, WE, and OE signals from the processor, and I would not need SDCKE, RAS, CAS. But should I route any of the WAIT, CLK, or DQM[0..1] signals to aid the interface?

I could in principle route all signals to keep options open for the FPGA, but I am trying to keep the vias grid under the processor from completely perforating the GND/PWR planes (low tech PCB fab :|), so every pin I can exclude improves the layout...

Out of curiousity, what behaviour would argument for an SDRAM interface?

 

[rberek]

As a bare minimum, you would require data, address, a ReadNotWrite signal and a chip select. If you want to make it synchronous, you would provide a clock. If you want the FPGA to control how long the access takes, you would also have the FPGA generate an acknowledge signal.

In general, the processor bus to an FPGA only needs to set control registers and read status registers, and perhaps load and read internal memories to the FPGA. More often than not, this is done at fairly low speeds with simple single burst transactions. Thus there is rarely a need for anything complex here. Hence the desire for a low speed, low pin count interface. The most complex processor interface I've had to use in 22 years of telecom chip designing was a PCI interface, and quite frankly, that was overkill.

If you have more complex needs, then by all means use a more complex bus. But treating the FPGA as an SDRAM may not just mean using the more complex bus. If you use the SDRAM interface of the processor, it might also insist on accessing the FPGA as an SDRAM protocol-wise as well, which means burst control, bank and row precharging, bank selection, auto or manual refresh, etc. None of these have any meaning to the FPGA, but will require complexity and needless overhead.

Figure out your bandwidth needs for the processor bus, and any functionality you will require from the bus. If you are just accessing control and status registers, or low bandwidth data storage memories, then do the simplest thing you can.

I'd worry more about needing extra pins for features that get thrown at you later, than using them for a processor bus.

But that's just my opinion. And I simply can't think of a reason offhand why you would use an SDRAM interface for an FPGA, unless the FPGA was being used as a slave SDRAM controller or something. Perhaps others have some ideas.

r.b.

r.b.

 

[vandelay]

As a bare minimum, you would require data, address, a ReadNotWrite signal and a chip select. If you want to make it synchronous, you would provide a clock. If you want the FPGA to control how long the access takes, you would also have the FPGA generate an acknowledge signal.

You make alot of sense :idea: A good integrity clock and an acknowledge will be all the "extra" pins I include in the bus, just in case..

Figure out your bandwidth needs for the processor bus, and any functionality you will require from the bus. If you are just accessing control and status registers, or low bandwidth data storage memories, then do the simplest thing you can.

Thing is, while my basic requirements does not require much bandwidth at all (say reading a dozen 16-bit sensor values each millisec, handle radio communications at <230kbps, and controlling servos and electronic speed controllers), the FPGA includes a dense high speed connector for expansion boards. This is a modulized system, not an optimized consumer product focusing only on certain functions. Thus, the functionality of the expansion boards are unknown, and a decent bandwidth between processor and FPGA will help with flexibility.

Another aspect is that the Spartan-6 have a fairly good DSP capability, so it may be used for coprocessing duties as well, that will also possibly demand a good bandwidth.

I'd worry more about needing extra pins for features that get thrown at you later, than using them for a processor bus.

I configure the FPGA from the processor using an SPI port (MOSI,CLK), and I have included extra SPI pins (CS, MISO, ENA) for the purpose of using this (fast) SPI interface after the FPGA is configured as well. I am thinking this will do decent as a flexible messaging system (independant of the data transferred on the bus), and if need be, the 5 SPI I/O pins can be used for interrupt-style flag signalling. Also, I have a fairly good address range, and can probably sacrifice a couple of address pins as well, that are also configurable as general purpose I/O.