On Tuesday 06 April 2004 05:15 pm, Mike Jarabek wrote: > You are correct, it's not always a bad idea. I did not qualify my > statement adequately. When you use the clock as part of your logic > you automatically double the frequency that your circuit must operate > at. This is probably not a big deal when your clock is under 20MHz, > but it certainly affects your design at speeds like 100MHz. If the
Oh, well, yeah. :) No arguments there. In fact, I'm surprised that modern microprocessors don't have input-only and output-only buses exposed at the physical pin boundary. I know it takes a lot of pins to be able to do so, but egads, with 400+ pin BGAs, you'd think it would draw some attention. I suppose point-to-point buses like HyperTransport offer similar functionality to having split, fully synchronous interfaces though. My ultimate goal is to produce an asynchronous, MISC architectre CPU that I can use in a future design, specifically because the reduction in EMI and power consumption more than outweighs its disadvantages. But that is a very, very long-term project for me, and is not a high priority. My immediate priority is to deliver my product via the 65816 microprocessor, something that I know will work, and do so within budget. Seeing fully asynchronous cores on opencores.org gave me the confirmation that such a thing is possible. > design is fully synchronous, the clock automatically qualifies your > signals because no state changes happen until a rising (or falling > edge). Correct. However, I still need some combinatorial circuitry to handle the three-stating of buses and output enables and such, so that data becomes valid prior to a clock edge. Again, all this happens inside the chip, BUT only is significant for the 6502/65816 local bus interface. Everything else uses a split input-only and output-only set of buses, using multiplexors to simulate a true shared connection. > Using a clock as a qualifier inside of an FPGA can be dangerous. > Especially if you are using a look up table based FPGA, if one of the > signals is asynchronous to the clock, glitches can appear on an Forgive my naivity, but why is this? This seems like such a basic thing to be able to do. I know that many FPGAs have dedicated lines to support a clock, complete with clock skew compensation buffers throughout the chip. But what if the clock were also routed to a data input, for use in a border interface of some kind? > When you do this in an ASIC, you have to carefully constrain the paths > when you attempt timing closure. It's often hard to communicate this Ahh, I should say that I'll be targeting either a CPLD or FPGA for my designs. No way in hell I can support a custom ASIC (much as I'd love to...). :) -- Samuel A. Falvo II
