Granularity of components for FPGA synthesis?

Since you're talking about pblocks, I'm going to assume Xilinx family. In my experience, and usually advocated by Xilinx - you're much better off with a lighter touch - if any. I never floorplan until forced to. Follow good synchronous design principles. Register often. Apply, and check timing contraints. Let the tool do the rest.

On (very) rare occasions this isn't sufficient, then floorplan lightly - locking down RAMs/PLLs/BUFGs.

The tools just do a better down when left unconstrained.

Regards,

Mark

I'll second that. I had the opportunity to try out PlanAhead when it was still HierDesign, before Xilinx bought them. I worked on a tight V2 design for some time, then eventually found that the tools did a better job unconstrained. I did need to use multi-pass place&route on that design (now part of SmartXplorer). But I could never get the design to place & route after constraining it to pblocks. It may be that a less full FPGA would have worked better with pblocks, but these are precisely the ones that work well without any manual placement help.

One real problem is that Map will flatten the design in order to do global optimization. Keeping hierarchy to facilitate the use of pblocks actually hampers QoR during mapping.

Also you talk about "data path" which has a tendency to mean a section of the code that goes all over the physical design. Constraining this to a pblock doesn't sound helpful unless you can break the data path up into regions logically.

Now it may end up that your design has a more regular structure than my typical designs. In that case you might be able to win from using manual floorplanning. On the other hand, unless you're really trying to optimize something for re-use in a larger design, if the tools do a good enough job without floorplanning, why bother?

ts

hich

Since you're talking about pblocks, I'm going to assume Xilinx family.

My suggestions would also be let the tool do it first and see it makes the timing you need (if you have a spec). If you are looking to go as fast as p ossible, it might make sense to open the layout and start clicking on the s lowest paths and see how the components are placed. Sometimes one sees quit e suboptimal choices by the placer and it helps to write some placement con straints based on that.

Of course this is only the second step. First one has to look at the genera ted blocks and see if the synthesizer is making any sub-optimal choices. Th is usually happens with selection of existing hardmacros vs fabric elements . As an example it turns out the next version of the Vivado synthesizer lik es inferring DSP48s quite a bit and would use one even though the same logi c with fabric elements would be much faster, forcing one to sprinkle "use_d sp48 = no" constraints all over the RTL. Annoying but necessary.

snipped-for-privacy@dspia.com

Thanks for the answers. I will keep what I have now of floorplanning, becau se I like to have a clean result (ISE seems to throw stuff around like an e xpanding gas cloud), but I will keep it at that. I now get 190 MHz, I do no t have a spec, but I wanted to know how fast I (clockwise) I could make my design. And it is now mostly hampered through the fact that I use 64k bytes of block RAM, which I really had to constrain, because without this it use s block RAM in weird places.

Regards,

Jurgen

Hi Jurgen. Sorry to join the party late. I tend to buck the conventional wisdom on things like this. I did my first programmable logic design back in the 1980's when we used PALs (22V10, etc.) Generally you took *total* control of your design. You could use equations, but even when I did I liked knowing exactly what was going on with each and every fuse.

I miss those days - the modern trend seems to be for us to "program hardware"; it all is starting to feel like software design. I still like to floor plan tight little units of logic. Everyone here may be right, but my answer to the "if the tools will get you there, why bother?" is...

"Because I can."

-- Kip

With even the smallest modern FPGAs having 500K + "fuses", ie. configuration bits, it would be a very daunting task to know what they all do! Also, for design security and manufacturer's protection of their internal IP, they are getting VERY secretive of the internals.

Jon

Agreed on both counts. Regarding the first one, though, I don't mean to imply that I don't want to have access at all to modern tools. In a really large design, well beyond my ability to hold in my mind at the "detail level," I'd definitely use modern tools. But I'd still like to be able to do the performance-critical bits under full manual control - a lot like using an assembler to do the most critical bits of a software design and then wrapping that in compiled code.

And I think the parts of the IP that I'd need to know in order to do what I discuss they already reveal, via detailed drawings of CLBs and things like that. It's mostly the interconnect network that they don't document very well.

Anyway, I'm just pipe-dreaming. I've already accepted that the world just hasn't evolved the way I'd have preferred. To paraphrase Connor Macleod on that point - "in lots of different ways."

-- Kip