On 11/16/2011 2:00 PM, David Riley wrote:
On Nov 16, 2011, at 1:38 PM, Mouse wrote:
I have a
boardful of TTL which I designed and built to allow a
parallel port to control (via relays, driven off discrete
transistors controlled by logic levels) a bunch of mains outlets.
There are a few signals which could sort of be seen as clocks - for
example, one of them drives the clock input to a shift register -
but no global clock that applies to the whole circuit. Would this
be unrepresentable in an FPGA - or, rather, would it have to be
redesigned to operate with a global clock to be representable in an
FPGA? You make it sound like it.
It should be doable, but you might be able to achieve better
performance, etc. if you were to make it as synchronous as possible.
You can certainly have signals that run straight into a pin, go
through a whole lot of combinational logic, and come out another pin
with no clocks whatsoever.
- Dave
For some of the stuff that I do, I have to deal with multiple external
asynchronous events and signals. Almost all of my designs are
synchronous (usually with a module here or there that is purely
combinatorial) and so you normally bring your asynchronous signals into
your sync clock domain so that you can deal with it/process it/connect
it to other modules, and so forth.
My clock is normally much faster on the sync side than the async side,
so having enough time to properly receive/sample the signal is easy.
When you have multiple signals, it's just a matter of having separate
processes(hardware, really) that deal with each signal independently.
My designs are mostly finite state machines, because this makes the most
sense to me, and I find that I can implement just about anything using
one of them. The async signal causes a move from one state to the next,
and then I react accordingly.
When I've got to react to that async signal and immediately notify
another external device, my clock is running fast enough, that the
propagation delay through my logic is pretty tight. How long depends on
the logic required, but again, since the sync clock is much faster ---
it normally doesn't matter.
You know, since both Altera's and Xilinx's tools are free --- one can
download their multi-platform tools, code up some
VHDL/Verilog/RTL/whatever and then simulate it using their included free
simulators. Some of the timing analysis stuff is pretty neat to look at too.
A lot of the descriptions of tools and simulations breaking down don't
show up in normal hobby use. While it's not a fuzzy feeling knowing that
the simulators/synthesizers aren't perfect, they are pretty damn good,
and work absolutely fine for most small->medium sized projects. I'm
still in the process of building my "things to avoid problem list", but
there are common rules of thumb that if you follow, you'll likely go
down a good path.
Expecting these tools to somehow work magic and be 100% bug free is an
unrealistic expectation and most people who expect this are drastically
underestimating the complexity of tools involved.
Modelsim for simulation and synplify pro for synthesis seem to be
popular commercial standards. A limited Modelsim is included with Altera
software, where Xilinx includes their iSim which isn't horrible.
Altera's synthesizer seems to be better (properly inferring the hardware
from the HDL, requiring less resources) than
Xilinx's XST but this might
be a religious war I don't want to start. :)
Keith
P.S. vi rocks.