Are the FPGA designers just being dogmatic?

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.

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?

John

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.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

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.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

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

:-)

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

The _real_ one true rule is....

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

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.

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

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. 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.

John

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 ****

:-)

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

Nial.

But what if only one of those 12 does? Or what if you want all the performance you can get, so you run 50 tries and pick the fastest one?

If some compiles have a lot of jitter on some outputs, and one is a lot better, we use it.

Can't argue with that.

John

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.

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.

(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...)

---Joel

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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

I do all sorts of multiple clock domains on Xilinx Spartan parts, although generally the slower parts. There are a BUNCH of gotchas, however, where you cross clock domains, and you have to carefully consider all possible cases. Your slow clock rise time plus high source impedance, as well as other circuits switching on the chip, can combine to make this a completely different problem, namely a form of the ground-bounce situation, where outputs interfere with slowly-changing inputs.

Jon

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

--Winston

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.

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.

Oh no, they found me.

--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

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?

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

--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

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

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.

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
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

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.

--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

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

o

EN YOUR

Builds are always deterministic. They run on a deterministic machine that is incapable of producing non-deterministic results unless there is a failure of some sort.

But you can alter various parameters on successive runs that give different results in the placement and routing. That's what meeting timing is all about, adjusting the placement and routing until it meets your timing constraints. Sometimes they aren't met before the max number of iterations are met. Then you need to make a change and run it again.

hmmm... this IS SED. Isn't having no rules a rule? I guess it could be an observation... like Moore's Law.

Rick