Re: gEDA-user: HELP with Icarus Verilog, 0.7!

["Samuel A. Falvo II" <sam.falvo@falvotech.com>]

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