Looking for some rules of thumb - migrating a discrete 74HCxxx design into an FPGA

Probably the best way to start would be to use something like the schematic entry module in either the xilinx or altera free toolsets,you'll find that most standard logic devices are available as parts which you can pick and place. Synthesising with one copy will give you an idea of how many you might expect to fit into any device.

297 contains approximately 50 flops and associated logic. As a very rough approximation, you should be able to implement one 297 and your divide by 4 counter in 100-150 LEs. A 10K100 has ~5K LEs so you're looking at ~ 30 of your blocks. But of course it's late and it's been a while since I got any coffee in my system...

Beware of performing a naive (i.e. literal) translation of your SSI design into a programmable part. Often designs using individual chips do things which don't work very well in programmable logic. Some of these are:

1. Gated clocks (to implement clock enables).
2. Using async resets on flip flops and counters to implement logic functions.
3. Hazard coverage. (Usually the tools will optimise out the "unnecessary" logic.)

It's usually a trivial matter to turn these into a more FPGA or CPLD friendly design. This shouldn't affect the gate count / logic cell count much though.

Regards, Allan

For a rough cut, count FFs. THen divide that into the number from the data sheet.

Most modern FPGAs have a basic unit that is a clump of logic and a FF. The "clump of logic" is typically a 4 input LUT (Look Up Table). It can implement any function of 4 inputs.

If your design/problem doesn't have a lot of logic between the FFs, there is a good chance that all or most of it will fit in that 4 input LUT. So counting FFs works out to be a good rough estimate.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

"Rob Barris" schrieb im Newsbeitrag news: snipped-for-privacy@news.newsguy.com...

Ahh, my beloved PLL ;-))

Just have a look at the inside schematics of the 297. There you see serval counter (K, ID counter). Count the FlipFlops required for the Countners. In a CPLD, you have 1 FlipFlop in every macrocell. If you really want to put it into a FPGA, even the smallest can hold a dozen of them.

More or less.

Regards Falk

Hi all!

I don't mean to hijack the thread, but could you possibly elaborate on 1. above?

I may need to start and stop a clock generator cleanly inside an FPGA and my initial thought was to use the traditional "gated clock synchronizer" with one d-latch. Am a bit of a noob with FPGAs so I may well be missing something here.

DJ

Clock gating has two dangerous aspects:

1. The gate will inevitably delay the active clock edge, which may or may not a problem in your case.
2. Indiscriminate clock gating can generate "runt" clock pulses or clock glitches, which can result in unreliable clocking (some flip-flops reacting, others not).

If you use rising-edge clocking, you can enable/disable the clock through an OR gate, whose control input must be synchronous with (clocked by) the rising clock edge. The disabled clock is then parked High, and gets enabled when the clock is High again. Falling-edge clocking does the same with an AND gate, and parks the clock Low. This is safe clock gating, but assumes that the clock is not super-fast. And remember, you must not gate a clock that drives a Digital Clock Manager (Xilinx).

Peter Alfke, Xilinx Applications

Peter,

Lots of thanks for that!

And yeah, of course I'm using Xilinx... ;-))

DJ

Sorry for hanging my question off this thread (should I create a new one in an instance like this?)

Just thinking again, would something along these lines (good old one, unless I'm mistaken) be the same as your second method:

input CLK_IN; output CLK_OUT; input GATE; reg SYNC_GATE;

always @(negedge CLK_IN) SYNC_GATE -------------| D Q |----+ | | | +---O|>CK | | +-----+ | +---------+ +---| | CLK_OUT CLK_IN | | & |------>

Comments?

DJ

Unless you are worried about power consumption it is probably simpler and safer to leave the clock alone and gate whatever it clocks.

If the ungated clock is used in the design it will probably already be on a global clock line and available all over the chip. The gated clock will likely have to be buffered and drive another global clock line. The gated clock will be delayed with respect to the ungated clock so you will have difficulty transferring clocked data from the ungated to gated clock domains. Timing analysis and constraints become more difficult.

A gated clock may seem like the most obvious solution to your design problem, but, generally it is bad news all round.

Just a comment - if you were to implement this in an FPGA, you would need to (tightly) constrain these paths to control the routing delay.

If the routing delay on SYNC_GATE is significantly larger than the path from CLK_IN to the and gate, then you could potentially get a very short clock out pulse. Similarly, CLK_IN taking much longer than SYNC_GATE could also cause problems. Ideally they should be almost matched, with the SYNC_GATE delay being larger than the CLK_IN delay (Of course, it all depends on the speed of your clock).

What exactly you can do with this clock (wrt the routing fabric) is another question :) I would have thought that clock enables would almost always be preferable.

My 2c, Jeremy

Jeremy and nospam,

Thank you for the hints!

This (non-FPGA legacy) clock is not high speed wrt propagation delays (

It isn't that bad. The only problem occurs when the delay between CLK_IN to the FF and CLK_IN to the gate exceeds the FF CK to Q delay + the SYNC_GATE delay. That would produce a glitch when the clock is enabled.

If CLK_IN is on a global clock line that situation is probably impossible although I am not sure what kind of path there is between a global clock line and 'logic'.

Jeremy,neither of us is a fan of clock gating, but I like to explore the limits of "synchronous design". I disagree with your analysis of the need for close delay matching.

Let's take the rising edge case with the OR gate. It only requires that the path from clock to Q and to the OR gate has a longer delay than the direct connection of the clock to OR gate. How much longer does not matter, until it approachess the clock High time. I think that's a reasonable assumption, especially since no designer would intentionally delay the clock signal that is to be gated. I had warned against using this trick for very high-frequency clocks. Peter Alfke

none needed. All the more useful stuff to learn from.

It's not like I have to read all the replies in strict order :)

Rob

Me too :) When things get difficult, or resources are low, then these sorts of tricks can make all the difference, if well understood and controlled (If not, then they can be a source of real problems).

I think we actually agree - I'm just being a bit more paranoid :) Routing delay can add a variable amount of time (per synth run) - by using appropriate constraints the operation can be guaranteed to either fail PAR, or work, yes? This would imply that this technique could possibly be used for mid-to-high frequency clocks (if the technology is fast enough), if appropriately constrained.

The designer may not intend for the clock to be delayed (irrelevant if using BUFGs), but there are situations where the clock could be delayed, if the problem is not well understood enough (local routing anyone?). I think that when we hit the 'limits', what it actually means is that more of the checking either falls strictly on the designer, or more care is needed in order to tell the tools what checking they need to do.

Jeremy