FPGA interface to an asynchronous microcontroller memory bus

The computer must give you some strobe that indicates valid data. Do a worst-case analysis whether your FPGA clock guarantees capture within that window. Otherwise implement dirct data capture in the IOB and postpone the synchronization to 24 MHz. Always assume worst-case timing and phasing... Peter Alfke

"Laurent Pinchart" wrote

Laurent, No, you can't. From DS001 FCLKINLF Input clock frequency (CLKDLL) Min(-6) 25 Max(-6) 100 Min(-5) 25 Max(-5) 90 MHz Cheers, Syms.

Oops, you're right. I'll then use a 25MHz main clock, or keep the current one if 24MHz turns out to be enough. My initial question still applies though :-)

Laurent Pinchart

The microcontroller has read, write and address strobe signals. The problem is that the bus is asynchronous, which means that the FPGA might sample the signals when they are not in a defined logic state. This implies meta-stability problems if I remember my classes properly. What are the basic guidelines to handle such problems ?

Laurent Pinchart

has

I don't know what peripheral you want to implement, but for an address latch / decoder an FPGA sounds like an overkill. Spartan-II is not expensive, but consider the power supply and sereal EEPROM etc. A CPLD may be a simplier solution. Say 9572?

The FPGA will do many things in parallel. One of the things it will do is a latch that's clocked by the appropriate edge from the AVR that is independent of any logic that's changed by the FPGA's clock. After the data is latched, it will set a "new data available" flag that's handled by the FPGA's clocked logic.

No problem. In Frequency Synthesis mode (Fx output), it is only the output frequency (not the input frequency) that must be above 24 MHz... Peter Alfke

There was a descent thread of a PC104 (ISA) bus a while back. Try googling "Async logic in FPGAs"

BTW, sometimes MPU's give bus timing with respect to the chip's clock input.

- Newman

signals.

like to

This is a latched interface example that worked for me using Xilinx FPGAs (Spartan II). Your design must be *extremely* careful about the ALE, nRD and nWR signals (both in your board and in the FPGA - perhaps buffering them adequately). I also registered carefully the internal outputs of my design that interacted with the interface.

---8| |--> A AD | |--> DI ALE -->| || |--> WE nWR -->| |--> RST CLK -->|> | +----+

A: {AH, AD_address} DI[7:0]: AD_data input DO[7:0]: output to AD data WE: write strobe RST: reset (both nRD and nWR asserted)

module avr( CLK, AH, AD, ALE, nRD, nWR, A, DI, DO, WE, RST ); parameter AH_size = 0;

input CLK; // not used in this implementation input ALE, nRD, nWR; input [((AH_size>0) ? AH_size-1 : 0):0] AH; // if AH_size == 0, AH is unused inout [7:0] AD;

output WE, RST; output [AH_size+7:0] A; output reg [7:0] DI; input [7:0] DO;

reg [7:0] AL; // Address-low latch

assign A = (AH_size>0) ? {AH, AL} : AL; // Full address

wire nALE = ~ALE; // needed for XST to synthesize a latch for AL wire RD = !nRD && nWR; wire WR = !nWR && nRD;

assign WE = !ALE && WR; assign AD = (!ALE && RD) ? DO : 'hz; // Memory read output drive control

assign RST = !nRD && !nWR; // Reset signal generated by asserting nRD and nWR simultaneously

always @(AD, nALE) if (!nALE) AL

I did not test this setting extensively so I can't

I got a good chuckle from your quote

-Newman

to

has

signals.

ALE is guaranteed to be valid during the AVR positive edge. I did an interface once for the mega103 which is harder, and that latched the data on the write strobe (open when low).

Sample the write strobe with the FPGA clock. If it goes from low to high you have the valid data in the latch, and can copy this to a register clocked with your 24 Mhz

Maybe it is easier if you could run your FPGA at 32 MHz and generate the AVR 16 MHz from an FPGA output

An FPSLIC design would make life easier, but maybe it is too msall in FPGA and memory size. The new ones run at 40 Mhz.

Can't you run the MCU form a clock drived from the FPGA one - that way they won't be asynchronous.

"Rich Webb" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

problem

the

We handle this situation in this way. NO oversampling. Since there is no need to do so. A read acces to a register inside the FPGA is plain combinatorical, no problem here. A write access to a register is defacto a clocked process, so we use WR as a clock (on a global clock net) to load data into FPGA registers. For an address latch its similar, use ALE to clock the address into the latch/register. Here you dont need to wast a global clock net, local routing (low skew lines) do fine, since the latch is small (just a handfull of flipflops)

The right way to go. Dont forget to synchronize the flag using the classic

Regards Falk

Wow! You use REAL Latches. I never dared to used them. If it works stable, my are sure of my deep repect.

I would have doubled (or quadroupled) the 24 MHz clock and synchonized the write signal.

Cheers, Chris

Pablo Bleyer Kocik wrote:

synchonized

You bet. And for really critical applications (ie potentially lethal for living beings), *I even don't trust clocks*. Synch or asynch, I end up implementing smart, redundant, buffer-isolated interfaces with internal consistency checks in case something goes mad. There are horror stories even at sub-MHz frequencies!

The horror... The horror...

-- /"Horror and moral terror are your friends. PabloBleyerKocik / If they are not then they are enemies to pbleyer / be feared. They are truly enemies." @embedded.cl / - Colonel Walter E. Kurtz, Apocalypse Now (1979)

There are a few reasons why I choosed the Spartan-II. First, I need several counters, a peripheral interrupt controller, a PWM signal generator and possibly other things. All that wouldn't have fitted in a CPLD.

The second reason is that I have several in stock :-)

Laurent Pinchart

I thought about doubling the clock as well for the same reason. How safe/unsafe is a real latch in a Spartan-II ? What should I know about it ?

Laurent Pinchart

No I can't. The datasheet states that the MCU internal clock is delayed by an unknown amount, so even if I could get it to work, there would be no guarantee, and the risk is too high.

Laurent Pinchart