Are the FPGA designers just being dogmatic?

[Mr.CRC]

Hi:

Over on comp.arch.fpga, god help you if you mention feeding a clock
other than The One True Clock into an FPGA, in case you need to divide
it, or make pulses out of it etc.

No, you must *always* under all circumstances, re-synchronize all inputs
to The One True Clock.

Granted, this is a good first guideline to follow. However, it just
doesn't work if the operations performed on the externally supplied
clock must remain synchronous and jitter-free relative to that external
clock, with jitter under the period of the fastest possible clock in the
FPGA.

What do you make of this resynchronize or die rule?

It seems like practical reality warrants a little more flexibility.


Thanks for comments.

 

[Mike Perkins]

Having everything synchronized to one clock greatly simplifies the
design, however this is not an absolute requirement. Sometimes it is
necessary to have several asynchronous clock domains in one FPGA. We've
done that many times; there is nothing inherently wrong with it. Passing
the signals between the domains takes some care; however it could be
done without much problems.

I thoroughly agree with this.

For the novice it is easier and more reliable to have a single clock domain.

You have to be bitten once or twice by meta-stability to appreciate the
importance of passing data reliably from once clock domain to another
using proven techniques.

However, multiple clocks domains is often a necessity and can also give
improved EMC.

 

[Nial Stewart]

Over on comp.arch.fpga, god help you if you mention feeding a clock

other than The One True Clock into an FPGA, in case you need to divide
it, or make pulses out of it etc.

Don't think we can't see you over here!

No, you must *always* under all circumstances, re-synchronize all inputs
to The One True Clock.

No, in the example you posted it's the easiest way of getting it to work
_reliably_.

Granted, this is a good first guideline to follow. However, it just
doesn't work if the operations performed on the externally supplied
clock must remain synchronous and jitter-free relative to that external
clock, with jitter under the period of the fastest possible clock in the
FPGA.

What do you make of this resynchronize or die rule?

The _real_ one true rule is....


****DON'T DO ANYTHING THAT IS BUILD DEPENDANT****

It seems like practical reality warrants a little more flexibility.

It does, but you need to know a bit more about the device structure /architecture
and how the tools treat your HDL (as you've picked up).


Nial.

 

[Nico Coesel]

Hi:

Over on comp.arch.fpga, god help you if you mention feeding a clock
other than The One True Clock into an FPGA, in case you need to divide
it, or make pulses out of it etc.

No, you must *always* under all circumstances, re-synchronize all inputs
to The One True Clock.

Granted, this is a good first guideline to follow. However, it just
doesn't work if the operations performed on the externally supplied
clock must remain synchronous and jitter-free relative to that external
clock, with jitter under the period of the fastest possible clock in the
FPGA.

What do you make of this resynchronize or die rule?

It is a good rule just like not using the 'goto' statement when
programming. Once you got more experienced you'll find there are
exceptions to the rule.

 

[Nial Stewart]

That's another rule that begs to be broken. Sometimes we do a dozen

p+r runs, with different starting seeds, to find the one that passes
timing best. Then we use it.

John, there's no need for this, if it passes timing it passes timing.

If the design is properly constrained this is all you need, the tools do
worst/best case timing on all clocks/data paths for PVT corner cases
(at least for Altera).

****DON'T DO ANYTHING THAT IS BUILD DEPENDANT****
The tools support this, so other people
must do it, too. Changes, especially small changes, can usually later
be sneaked in without disturbing things much.

OK, so the one golden rule wasn't properly specified.

**** DON'T DO ANYTHING THAT WILL DELIVER UNPREDICTABLE FUNCTIONALITY WHEN YOUR
BUILD SAYS IT HAS MET THE TIMING CONSTRAINTS ****



Running multiple passes to meeting properly constrained timing is
acceptable behaviour!


Nial.

 

[Winston]

Hi:

Over on comp.arch.fpga, god help you if you mention feeding a clock
other than The One True Clock into an FPGA, in case you need to divide
it, or make pulses out of it etc.

No, you must *always* under all circumstances, re-synchronize all inputs
to The One True Clock.

Well then, thank God they are dogmatists and not autocatic.

--Winston

 

[[email protected]]

That's silly. We often have several clocks on an FPGA, and often some
of those clocks don't run continuously. Crossing clock domains must be
done carefully, but it's not a moral sin or anything.

Well, FPGA manufacturers go to great lengths to provide multiple, accurately
timed, clock distribution nets within chips, so I don't think the idea is to
prevent more than one clock domain. The key is to properly synchronize all
inputs to *all* clock domains.

How are you going to synchronize an Ethernet or PCI Express interface
block to some dumb slow local clock? What if synchronizing adds too
much jitter, or just won't keep up?

Multiple clocks, async logic, flops or shift registers clocked by
not-official-clock pins: not for wimps.

Modern FPGAs are full of PLLs and DLLs anyhow. Why would people put a
dozen clock PLLs on a chip if only One True Clock is allowed?

Again, I think the issue is to make sure everything with the domain is
properly synchronized. It's obviously easier to design fully synchronous
logic.

 

[Mr.CRC]

Don't think we can't see you over here!

Oh no, they found me.

 

[Mr.CRC]

John, there's no need for this, if it passes timing it passes timing.

If the design is properly constrained this is all you need, the tools do
worst/best case timing on all clocks/data paths for PVT corner cases
(at least for Altera).




OK, so the one golden rule wasn't properly specified.

**** DON'T DO ANYTHING THAT WILL DELIVER UNPREDICTABLE FUNCTIONALITY WHEN YOUR
BUILD SAYS IT HAS MET THE TIMING CONSTRAINTS ****

I like it this way.

Running multiple passes to meeting properly constrained timing is
acceptable behaviour!

Is there a potential for non-deterministic outcomes to the build process?

If so does that actually mean one pass can meet timing and another not?

Nial.

PS, I asked over here because I know at SED there are no rules.

 

[Mr.CRC]

Nah. If you know what you're doing, there's no reason not to use as
many clocks as you like; you just need to be cognizant of the
possibility of metastability, how to cross clock boundaries, etc.

Well I've already seen and dealt with metastability, so that's in the
understood dept.

The folks preaching the One True Clock approach either (1) figure you're
a newbie or (2) they themselves just have the Readers Digests
version of FPGA design knowledge, and somehow figure it's best if you
just follow what they know rather than figuring out for yourself what's
going on.

Well I'm a newbie at FPGAs, but not at being able to learn new
electronics with little help. However, with FPGAs, there are
considerable realms of knowledge that seem difficult to acquire without
making mistakes and learning from the experienced.

For ex., there is nothing in any of the several books I have on the
subject so far of using timing constraints.

(I've seen this in other areas as well; a classic example was a guy who
steadfastly wanted an individual ground return pin for each and every
digital signal line we had going through a connector, despite the fact
that the signals in question had edges rates in the ballpark of
microseconds and frequencies in the kHz range...)

Oh I can't stand when people do rule of thumb designing with no
comprehension. The guy I replaced at work was like that. Then again,
my problem tends to be excessive analysis and modeling when a little
tweaking will suffice. But that's one of my kinds of fun.

 

[Mr.CRC]

I worked at a company for a while that had two engineering groups. One
(call them "s**t sweepers"), where I worked, was a short walk away from
the manufacturing floor. We tended to get all the "hurry up and fix
this problem so we can ship" issues. The other (call them "the golden
boys") was 2700 miles away, and were tasked with prototyping new,
short-run products. Their style was to get a prototype working even if
it had to be hand-built by degreed engineers, then throw everything over
the wall to manufacturing and respond to all requests for continuing
work with "nuh-uh, we're in a hurry on this here _next_ important thing".

They'd do FPGA designs that were so close to the edge that they had
scripts that would try and try again, sometimes for days, to get the
designs to meet timing. Once they had something, they'd jump back and
yell "it's done!" then go hide.

Then manufacturing would find some problem that only cropped up at cold
(or hot) extremes, and management would make _our_ FPGA guys fix it.

_We_ didn't pull that s**t unless we were well and truly backed into a
corner, and even then we'd be simultaneously working (or at least
scheming) on architectural changes to make the timing better next time.

I "get" to do everything, from system design, analog, digital logic,
embedded software, mechanical chassis design, PCB layout, assembly,
test, documentation, deployment and support!

I consider it to be a major fail if anything I deploy to the lab winds
of costing the scientists time if a bug shows up. I have managed to
avoid a single incidence of this in 12 years. The price paid is
somewhat slow project completion, however. Fortunately, this is
tolerable in a research environment.

Our programmer OTOH thinks the scientists' time is better spent than his
revealing bugs.

Different philosophies.

 

[Nial Stewart]

**** DON'T DO ANYTHING THAT WILL DELIVER UNPREDICTABLE FUNCTIONALITY WHEN YOUR

I like it this way.
Is there a potential for non-deterministic outcomes to the build process?
If so does that actually mean one pass can meet timing and another not?

Oh aye, if your design is getting full or you have to meet some tight
timing constraint you might find it'll take a few runs to get a sucessful
build. There are scripts that will run a number of builds with
different seed values until timing is met.

But the rule still holds, if the build meets your timing constraints
it _should_ work 100% reliably.

BTW, if things are getting this tight on a build it might be time to look at
hand placement of critical paths and locking them down, or assigning
areas of the FPGA to sub modules of your design, but this is more
advanced stuff.



Nial

 

[Winston]

As in Churchill?

As in Orwell's character in _1984_.

“There are a terrible lot of lies going about the world, and the
worst of it is that half of them are true.”

Winston Churchill

--Winston