Synchronous over asynchronous VHDL -- any advantages?
Filip Miletic
Greetings everyone!
I hope you can help me resolve the following: I am very unaware of the
reasons synchronous design in VHDL is so much preferred over
asynchronous
one. Why does Xilinx say that it is a good practice to prefer clock
based
processing rather than event based? There have been explanations around
that such an approach is 'easier', but I really fail to see the
difference.
In order to avoid misunderstanding, by 'event based' I mean having some
of the flip-flops clocked by a combinatorial network. This in effect
creates
ff's which are triggered only when needed.
From my point of view, the synchronous design is: a) bulky
b) less power efficient c) error prone if used incorrectly (as it most
often
is, according to my experience with the vhdl cores I inspected).
I do not know if it results in better cell usage as I work only on cores
of
very moderate sizes. There are possible glitching problems as well but
they
can be dealt with by a cautious design.
I know that this requires special treatment of external async signals,
but this is not an issue here.
This question was given rise by the woes a synchronous xilinx-based VHDL
core
has given me: it is a core which communicates with the outside world via
the
uc68k type bus.
Although the signals on the bus are in effect asynchronous, they chose
to
process them in a synchronous manner, by sampling them
with the internal clock before processing. This poses grave
restrictions on the relationship the bus signals are allowed to have to
the
system clock, i.e. if they arrive in an appropriate time -- being
perfectly
legal buswise -- they can get misinterpreted by the input circuitry.
It does work in the original setup, but fails to work if the enable
signals
get too short for the internal circuitry to handle -- which is an
unnecessary
restriction to my mind.
Please advise.
f.
VhdlCohen
>reasons synchronous design in VHDL is so much preferred over
>asynchronous >one. Why does Xilinx say that it is a good practice to prefer
clock
>based >processing rather than event based? There have been explanations around
>that such an approach is 'easier', but I really fail to see the
>difference.
>
>In order to avoid misunderstanding, by 'event based' I mean having some
>of the flip-flops clocked by a combinatorial network. This in effect
>creates>ff's which are triggered only when needed.
A Nightmare to debug, do timing analysis, and is probably susceptible to race
conditions, hazards.
>
>From my point of view, the synchronous design is: a) bulky
>b) less power efficient c) error prone if used incorrectly (as it most
>often is, according to my experience with the vhdl cores I inspected).
BEN: But is easier to analyse the design from a timing standpoint.
WOuld you ratrher have a shaky design that is more power efficient, or a robust
design that works under various temperature and manufacturing conditions?
>
>I do not know if it results in better cell usage as I work only on cores
>of >very moderate sizes. There are possible glitching problems as well but
>they >can be dealt with by a cautious design.
BEN: Timing analysis is a nightmare. So is debugging.
>
>I know that this requires special treatment of external async signals,
>but this is not an issue here.
>
>This question was given rise by the woes a synchronous xilinx-based VHDL
>core
>has given me: it is a core which communicates with the outside world via
>the
>uc68k type bus.
>
>Although the signals on the bus are in effect asynchronous, they chose
>to
>process them in a synchronous manner, by sampling them
>with the internal clock before processing. This poses grave
>restrictions on the relationship the bus signals are allowed to have to
>the
>system clock, i.e. if they arrive in an appropriate time -- being
>perfectly
>legal buswise -- they can get misinterpreted by the input circuitry.
>
>It does work in the original setup, but fails to work if the enable
>signals
>get too short for the internal circuitry to handle -- which is an
>unnecessary
>restriction to my mind.
BEN: Same rationale as above.
-------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdl...@aol.com
Author of following textbooks:
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
Filip Miletic
VhdlCohen wrote:
> BEN: It also creates a design with MULTIPLE CLOCKS!!!!
> A Nightmare to debug, do timing analysis, and is probably susceptible to race
> conditions, hazards.
What I had in mind was a design which uses event based processing for
timing critical events -- this is what I currently do. There are things
for
which you simply cannot afford to have a clock delay for processing.
Such networks in principle do not get very large and have no feedback,
which is good since that can introduce real problems, just as you are
saying.
Of course, it is the designer who must keep them small and feedbackless.
> WOuld you ratrher have a shaky design that is more power efficient, or a robust
> design that works under various temperature and manufacturing conditions?
Well, since now I have to repair a design which does not work under
normal
operating conditions as well... :) Yes, I do prefer a power efficient
design
and some extra thought to make it work well, but then again I am an
university guy, not from the commercial realm. I've no deadlines. :)
> BEN: Timing analysis is a nightmare. So is debugging.
True, but with sync design you can easily see that it does not work;
moreover
you can easily see that it can never work given the way it is wanted to
and the way it does work.
The person who wrote this particular design I am rewriting now loved
state
machines so much that she allowed the it to play around
going from one state to the other, while making it respond slower to the
changes in bus state.
> BEN: Same rationale as above.
Ditto. :)
Thanks for your advice.
f.
darrell mcginnis
latency sensitive designs.
you'd likely be better to oversample more and pass around synchronous edge
detection pulses...
As I recall, an mc68k does have outputs related to the clock but allows
inputs to be asynch. (note there are probably pulse width requirements of
two clocks)
"Filip Miletic" <fmil...@dimes.tudelft.nl> wrote in message
news:3C3C0264...@dimes.tudelft.nl...
Phil Connor
> Why does Xilinx say that it is a good practice to prefer clock
> based
> processing rather than event based?
A good question. My understanding is that only synchronous designs have
their timing preserved through synthesis tools. So you can't be sure an
asynchronous design will always work.
Regards
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Daman Ahluwalia
Asynchronous design definately has its positive aspects..if designed
properly one can achieve high throughput no doubt about that but the
design time for async ckt is considerable more that it sync counterpart..
if one doesnot have deadline and power is the main issue then one can go
in for async design...
another advantage is that u can incorporate ur existing sync algorithms in
to async enviorment too
Daman
--
Daman Ahluwalia
MSCE(Computer Architecture)
University of Southern California,
Los Angeles,
CA 90089
Just Dave
Why does Xilinx say that it is a good practice to prefer clock based processing rather than event based?
The short answer: because we've always done it that way. For about as
long as logic design has existed aside from being an academic exercise,
we have been doing mostly synchronous because it allows us the luxury of
letting the intermediate states glitch and wiggle all they want until
the next clock edge. These intermediate states have no effect on the
machine because the state flip-flops are not updated until everything is
stable. Everybody naturally prefers the path of less thinking and all of
our standard tools and techniques are based on synchronous design.
I took a college course that included asynchronous sequential design
back in 1976 but have never used it in industry. My recollection is that
stable asynchronous state machines have about twice as many states even
if the overall gate count reduces when the flip-flops are eliminated.
I don't have it handy to quote issue and page but the MIT's Technology
Review had an article sometime in the last year or so about some "new
pioneers" in asynchronous design who have done full blown RISC machines
asynchronously but even they freely admitted that the tools were lacking.
Another answer is that Xilinx has catered the entire structure of their
devices to synchronous design. They have always had limited global clock
resources and, in the early days, we learned to limit our clocks to a)
the processor write strobe and b) the system reference. Slower clock
rates are done using the Enable line on each CLB and the flops only
transition at the rate at which tey are enables, which still reduces the
power. Now there are more global clock buffers available, but the same
principle applies. To avoid metastability, asynchronous external events
are first synchonized, then acted upon. For this, one or two flip flops
are sometimes clocked by a different signal, but they remain on the
periphery of the design. Trying to patch together many asynchrounous
pieces in a large design would either require such resync'ing at every
interface or floorplanning beyond anything I'd care to try. I got away
from manual place & route when Xilinx got their automatic tools working
in the late 1980s.
--
David L. Pearson
"If you understand, things are just as they are.
If you don't understand, things are just as they are."
Andy Peters
> VhdlCohen wrote:
>
>>BEN: It also creates a design with MULTIPLE CLOCKS!!!!
>>A Nightmare to debug, do timing analysis, and is probably susceptible to race
>>conditions, hazards.
>>
>
> What I had in mind was a design which uses event based processing for
> timing critical events -- this is what I currently do. There are things
> for
> which you simply cannot afford to have a clock delay for processing.
You can't afford to have known, fixed clock delay, but you *can* afford
to have a delay that can and will vary as a function of temperature,
power-supply levels, chip process, etc? Give me something known and
invariable every time.
--a
Andrew MacCormack
http://www.cs.man.ac.uk/async/background/index.html
The Amulet project built an asynchronous ARM processor.
--
___#--- Andrew MacCormack and...@tality.com
L_ _| Senior Design Engineer
| | Tality, Alba Campus, Livingston EH54 7HH, Scotland
! | Phone: +44 1506 595360 Fax: +44 1506 595959
T A L I T Y http://www.tality.com
Filip Miletic
Andy Peters wrote:
> You can't afford to have known, fixed clock delay, but you *can* afford
> to have a delay that can and will vary as a function of temperature,
> power-supply levels, chip process, etc? Give me something known and
It is not as bad. :) I just suggested such a use for data latching etc.
Besides, if delays are an issue, you could employ feedback to
synchronize
data. Of course, a rule is never to overdo it. :)
f.
Harish Y S
(http://hdlplanet.tripod.com)
Regards,
Harish
"Daman Ahluwalia" <dahl...@sal-sun048.usc.edu> wrote in message
news:Pine.GSO.4.33.02011...@sal-sun048.usc.edu...
> hello,
> Asynchronous design definately has its positive aspects..if designed
> properly one can achieve high throughput no doubt about that but the
> design time for async ckt is considerable more that it sync counterpart..
> if one doesnot have deadline and power is the main issue then one can go
> in for async design...
> another advantage is that u can incorporate ur existing sync algorithms in
> to async enviorment too
>
> Daman