Even the smallest FPGAs have four or more clock nets, and that is going back to the 4000's. Clock enables can do a lot for you, in most cases there is not really a need for a proliferation of clocks. Multiple clock domains give rise to potential timing constraints issues, as well as problems crossing clock domain boundaries. Not that any of that is insurmountable, just that it requires extra diligence to make sure you do it right, and that the tools don't mess up your good work. When I said virtex parts, I was referring to the virtex architecture, which includes all the current families. SpartanII is the virtex1 architecture, spartan2e is virtexE, spartan3 is a mutation of virtexII. The point is all of these families have ample routing. Now, whether the tools make efficient use of that routing is another question altogether (they don't, the tools now do a 'lazy' routing that only improves the routing until it is good enough. Problem is in a dense design, the circuitous routing artificially congests the routing resources which can make it appear that you do not have the routing to make timing. Poor placement can also aggravate the routing. The placer is *still* very bad at placing logic when a signal goes through multiple LUTs between flip-flops, often placing the LUTs without flip-flops far from the destinations, and well out of the way between the source and destination. The result is again unnecessary congestion of the routing resources, and pathetic timing results. Floorplanning will relieve enough of the problems caused by the placer that it is very hard to run out of routing. BTW, the routing is generally more stressed with larger devices rather than the smaller ones. Required routing goes up roughly with the square of the number of LUTs, yet the routing network is virtually unchanged across the family. Additionally, placement is more critical with larger devices because haphazard placement will incur large routing delay penalties, and that makes the job of the router tht much harder (possibly leading to a no-route situation due to timing) With small FPGAs, it is the memories followed by logic that gets used up first. I would argue that the routing in the cheap FPGAs is even more abundant. CPLDs are a different animal altogether. There, the routing between macrocells is generally sparse, and without careful planning it can be easy to use up the routing there. I stand by my earlier comments. Chuck McManis wrote:> "Ray Andraka" <ray@andraka.com> wrote in message > news:40AB48D9.C3F88E92@andraka.com... > > If you are doing a synchronous design you normally shouldn't run out of > clock > > resources. What are you doing that uses so many clocks? I suspect your > > clocking is also causing your routing woes. The virtex parts have > abundant > > routing resources; it is not that easy to use them up. > > Some assumptions in there Ray : > > "...If you are doing a synchronous design ..." but these days people are > doing SOC designs that might have a video clock, a CPU clock, a clock > driving an ethernet PHY, and a perhaps some refresh logic for their DRAM > controller. I'm not disagreeing with you, my point was that "gates" are > generally not the thing you run out of first. > > Next up "...The virtex parts..." however the original poster wanted to stay > away from the "expensive" chips. so starting from CPLDs and moving up, > you're somewhat constrained there. Lots of clock resources in a Virtex II > Pro, but then again in single quantities the chip is $300. :-) > > --Chuck-- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
How to select an FPGA size (beginner)
Started by ●May 18, 2004
Reply by ●May 20, 20042004-05-20
Reply by ●May 20, 20042004-05-20
Just to reinforce what Ray says in his response, if you have designs that have a lot of input clocks, I have found that some effort up front to retime these clocks to one higher frequency masterclock (which is clock enabled for each source clock domain) can often save you from a world of pain later on. Especially if you're transferring data between domains. The DCMs are great for making this masterclock. Cheers, Syms. "Chuck McManis" <devnull@mcmanis.com> wrote in message news:IWUqc.51416$fS2.33280@newssvr29.news.prodigy.com...> > "...If you are doing a synchronous design ..." but these days people are > doing SOC designs that might have a video clock, a CPU clock, a clock > driving an ethernet PHY, and a perhaps some refresh logic for their DRAM > controller. I'm not disagreeing with you, my point was that "gates" are > generally not the thing you run out of first. >
Reply by ●May 24, 20042004-05-24
