Asynchronous v. Synchronous Logic

[Altera_Forum]

Am (still) relatively new to FPGA development. Please bear with me. 

 Am using an FPGA to monitor address/data lines on an old (very old) MPU. I need to capture when an address is asserted on the bus and when the data is valid for read/write cycles. I understand the timing of the MPU quite well.   The simple solution would be to construct an always loop that executed on the edge of the address valid/read/write MPU signals. However, in some of my reading it appears that asynchronous always loops are considered bad. However, if I use a clock, the logic gets rather complicated as there are different wait states based on the accessed device.  My question is, is the "simple" solution valid? Or will I get myself into trouble? 8>)  Thanks, in advance,  ME

[Altera_Forum]

It is perfectly valid - just bear in mind that the async solution cannot have its timing analysed and you run the risk of race conditions. It is only bad because you cannot garantee the timing and the timing will vary with temperature, and cause glitches. 

 As long as you can cope with these (major - ie. it might work for a bit, then not) problems, then theres no problem.

[Altera_Forum]

Tricky, 

 Many thanks. There is very little that the always loop will interact with. So I can't forsee any race conditions. And the MPU is soooooo slow, a few ns here or there shouldn't be a problem. 8>)  Thanks again for the guidance....  ME

[Altera_Forum]

Typically reads don't care about having data valid at a very specific moment (only that addresses are stable long enough) so doing a continuous display of data during the read cycle whether the address has settled or not should be fine. If you're doing an operation like a FIFO where the read triggers an increment, there should be a single synchronous edge-triggered event to indicate the completion of the cycle. 

 For writes, the timing is much more critical to be communicated and typically an edge - a write enable or an ALE, for instance - is used to transfer data.   So reads can be asynchronous (or the output from a synchronous block updating from a higher speed clock) but writes and FIFO address updates should have synchronous edges to qualify the events.   With your asynchronous blck, how do you guarantee that one and only one address is written?

[Altera_Forum]

Hi John, 

 Thanks for the thoughts. Am using an old 80196. Address is always valid on falling edge of ALE. Reads and writes are valid on rising edges of RDn and WRn. For each signal, the data remains valid for approximately 30ns AFTER the corresponding edge. While a rising edge ALE would work, the address remains valid (and subsequently the data remains valid) for the 30ns after the RDn or WRn transitions high.  ME

[Altera_Forum]

So your synchronous event for a write is the rising edge of WRn. 

 Your read *data* can be generated asynchronously from the address without qualification or synchronously from the falling edge of the ALE (either of which could ba gated downstream by the RDn). Any FIFO read counters would be updated synchronously from the rising edge of the RDn.  You should be able to get everything you need with very clean synchronous design.   - John

[Altera_Forum]

Using edge sensitive always blocks trigerred by nRD or nWR isn't asynchronous logic. It's synchronous using multiple clock domains. In this case, the problems are brought up by transfering data or state information between clock domains. 

 As you say the clock frequency is low, synchronous edge detection in a single clock domain should however work well. It's the preferred method to interface synchronous logic e.g. with an asynchronous data bus, provided the system clock can keep up with the bus speed. It usually works when all involved control signals are wider than a clock cycle.  ALE can be usually processed with a separate address latch.