17 Nov
2011
17 Nov
'11
7:41 a.m.
On Nov 17, 2011, at 10:24 AM, Chuck Guzis wrote:
Thanks for that information--I'll have to go back
and revisit some of
my old code and see exactly what it was that was the stumbling block.
One that I recall was a peripheral interface that did little other
than propagate and switch signals. The error messages that I was
getting made me relent and add synchronizers for a fully-clocked
design. It worked, but I always wondered why that was necessary,
seeing that I could do the same thing without a clock and a board of
TTL.
Given the number of warnings the synthesizer probably threw up when it saw a large design
without a clock it could infer ("NO CLOCK FOUND - WORLD PROBABLY ENDING"), I
probably would have thought the same thing too.
I think part of the problem is the industry's infatuation with fMax as a benchmark of
tool quality; without a clock, there is no fMax, so the timing analyzer is a bit lost as
to what to do. "So, uh, you got any setup time constraints for me? No? I guess...
I guess I'll just find some propagation delays for you, then? Fine, but I'm not
going to like it."
Interestingly, though, you *can* do designs without a "clock" that use
read/write strobes as they're intended to be used; the read/write strobes, for all
intents and purposes, act as the clocks (typically, you'd use active-low #RD/#WR as
the active clocks to the flipflops and use #CS as the clock enable). A lot of older chips
worked that way (or at least similarly) internally anyway. The tool will give you some
nonsense number for fMax (I mean, if you really wanted to do read or write strobes as a
periodic clock, I guess you could), but it'll also give you setup/hold times and
minimum pulse widths for high and low as well, which is much more useful in that
scenario.
- Dave