I have to interface a 8-bit microcontroller (ATMega128, running at 16MHz) to a Xilinx Spartan-II FPGA.
The FPGA will have several roles. It should be an address latch (the bus has address/data multiplexed), an address decoder (to generate chip selects) and a peripheral accessible through memory-mapped registers.
As the bus is asynchronous, I suppose I'll have to over-sample the signals. Could anyone direct me to some documentation about asynchronous bus interfaces for FPGAs ? The FPGA main clock runs at 24MHz, and I'd like to know if this will be enough (the clock can be doubled using a DLL if needed).
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
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 :-)
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 ?
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
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)
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;
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.
--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
"Laurent Pinchart" skrev i meddelandet
news:4223a767$0$30170$ba620e4c@news.skynet.be...
"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
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 :-)
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.