[sdiy] FPGA multiplier

[Magnus Danielson]

From: ASSI <Stromeko at compuserve.de>
Subject: Re: [sdiy] FPGA multiplier
Date: Sun, 7 Dec 2003 10:03:29 +0100
Message-ID: <03120710032908.00646 at Robert>

> On Saturday 06 December 2003 21:34, Magnus Danielson wrote:
> > 2) Avoid or reduce the amount of asynchronous flip-flops.
> 
> I think Magnus means the use of asynchronous Set or Reset, in which 
> case I'd say you should avoid them like the plague. They are there 
> because sometimes there is no other solution, but they are all too 
> easily used for the wrong things.

Actually, this is just part (but a correct part) of what I said. I really mean
asynchronous flip-flops, which is a huge class of flip-flops. But if we now
look at asynchronous Set/Reset inputs you could map alot of different
flip-flops into a bunch of logics and a SR-FF.

> Also in an FPGA, the number of clock nets is a constrained resource and 
> while you can use any signal to clock an FF, you should really strive 
> to just use the dedicated clocks. I your first design you should 
> probably use just a single clock.

One thing that people do in classic logic is to toss the clock through a gate,
which you should not do these days, but rather use a gate with "clock enable"
(often just called ENABLE). This is a bit of a different thinking, but when you
think of it, you can significantly reduce the number of clock domains this way,
since as soon as you gate a clock, the resulting gated clock is it's own clock
domain.

> Both things are easy to mess up in VHDL and one should try a few very 
> small examples to see when the logic synthesis will infer one or the 
> other.

Indeed, but most of the times you should strive to keep everything in a single
clock domain and convert any external clock domains quickly into the internal
clock domain when possible. The more clock domains you have to deal with, the
more asynchronous clock domain border logic is needed and thus the related
analysis and verification. Naturally, if you have a multiple of the same logic
that helps to reduce the worstcase somewhat, but regardless you need to keep
attention to the topic.

> > [...] There often need
> > for some asynchronous handling, like going between two synchronous
> > clock domains (which is asynchronous to each other), but you want to
> > make any such transition at as few places as possible.
> 
> Synchronization of completely unrelated clock domains is really not for 
> beginners.

You could have stopped right there, I agree. You *really* want to avoid trouble
in your first attempts, make sure you have one and only one clock domains.

1) People don't sufficiently understand the problems of asynchronous signals.
2) People don't sufficiently understand the problems of asynchronous clock
   domains.
3) People don't sufficiently understand the problems of clock domains with near
   same frequencies.

etc. etc. it's a bloody field in itself and it is even fashinating that people
don't even know the basic terms and definitions of the field (sigh).

> You really need some expensive tools (clock generators with 
> PRBS and arbitryry pattern output and controlled jitter). Only the PRBS 
> part is easy to do in the FPGA itself, so you can do sort of a self 
> test. Most commonly it is needed to implement UART or FIFO blocks - go 
> find some free IP for that instead of re-inventing the wheel.

If somebody wants a PRBS-block in VHDL, please let me know and I toss you the
code. It does parallelized from (through a generic naturally!) and can be used
for various polynoms.

> Another common pitfall is the use of clock gating. This really does not 
> work in FPGA, instead you have to use clock enable/disable networks to 
> "freeze" the FF in question while the clock is still running.

Indeed. See my comments above.

> > Asynchronous
> > designs is more difficult to do than synchronous design and testing
> > is even more difficult.
> 
> I'd not tackle truly asynchronous designs with the free tools, I have 
> enough gray hair already.

Much of it isn't really in the tools but in the thinking, and no tool can ever
really solve poor system engineering and detailed design. You can do
asynchronous design with say WebPack, but you need to care about the details -
alot!

However, most problems is easilly solved in only a few clock domains anyway.

> > 3) Use the flexibilities of the VHDL language to make the code
> > readable rather than what makes "obviously minimal logic"
> 
> Seconded. Just like in programming, rule#1: Don't optimize. The logic 
> synthesizer is normally much better at reducing combinatorial logic 
> than any designer will ever be, especially as both the Altera and 
> Xilinx FPGA are based on lookup-tables, where it ultimately does not 
> matter if a function is made up of NOR or AND. Spend your time getting 
> the relations between the combinatorial blocks correct, clear and 
> concise. Also, avoiding tricky formulations will help to stay clear of 
> any bugs in the synthesis engine.

Also, many tricky bugs occur due to the codes inability to properly make the
logical expressions. Also, it is difficult to verify and also make propper
changes to the code. Sometimes you save ALOT of time by just toss such code
and redo it.

The kind of guidelines I gave is intended for those starting in the field.
Usually you can do alot when following that basic ideas, and the little extra
you have to deal with you can spend quality time on.

Cheers,
Magnus