Granularity of components for FPGA synthesis?

[chthon]

Hello,

I am busy designing a small microprocessor system, which I have partitioned into the data path, the micro-controller, the memory, a multiplexer for the data bus input and a couple of simple 8-bit IO ports.

I am now currently busy experimenting a little bit with layout constraints (pblocks), and I was wondering how one normally goes about deciding on which level to stop.

E.g. I have now the data path, which consists of the program counter, a couple of output registers, register file, followed by pipeline registers, followed by the ALU, which feeds back into the register file.

Is it worth while to structure this further, taking the layout of the FPGA into account, and define these data path components so that they can be placed as separate pblocks next to each other?

Regards,

Jurgen

 

[Mark Curry]

In article <b7e47d0a-dc4f-4333-9e43-a3b6b74e8a0c@googlegroups.com>,
chthon <jurgen.defurne@gmail.com> wrote:

Hello,

I am busy designing a small microprocessor system, which I have partitioned
into the data path, the micro-controller, the memory, a multiplexer for the
data bus input and a couple of simple 8-bit IO ports.

I am now currently busy experimenting a little bit with layout constraints
(pblocks), and I was wondering how one normally goes about deciding on which
level to stop.

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

 

On Tuesday, October 8, 2013 12:17:28 PM UTC-7, Mark Curry wrote:

In article <b7e47d0a-dc4f-4333-9e43-a3b6b74e8a0c@googlegroups.com>,
chthon <jurgen.defurne@gmail.com> wrote:
Hello,

I am now currently busy experimenting a little bit with layout constraints
(pblocks), and I was wondering how one normally goes about deciding on which
level to stop.
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 [sic]. Let the tool do the rest.

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 possible, it might make sense to open the layout and start clicking on the slowest paths and see how the components are placed. Sometimes one sees quite suboptimal choices by the placer and it helps to write some placement constraints based on that.

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

kal@dspia.com

 

[GaborSzakacs]

Mark Curry wrote:

In article <b7e47d0a-dc4f-4333-9e43-a3b6b74e8a0c@googlegroups.com>,
chthon <jurgen.defurne@gmail.com> wrote:
Hello,

I am busy designing a small microprocessor system, which I have partitioned
into the data path, the micro-controller, the memory, a multiplexer for the
data bus input and a couple of simple 8-bit IO ports.

I am now currently busy experimenting a little bit with layout constraints
(pblocks), and I was wondering how one normally goes about deciding on which
level to stop.


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?

--
Gabor

 

[chthon]

Thanks for the answers. I will keep what I have now of floorplanning, because I like to have a clean result (ISE seems to throw stuff around like an expanding gas cloud), but I will keep it at that. I now get 190 MHz, I do not 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 uses block RAM in weird places.

Regards,

Jurgen

 

[Kip Ingram]

* chthon <jurgen.defurne@gmail.com> wrote:

Thanks for the answers. I will keep what I have now of floorplanning,
because I like to have a clean result (ISE seems to throw stuff around
like an expanding gas cloud), but I will keep it at that. I now get
190 MHz, I do not 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 uses 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

 

[Jon Elson]

Kip Ingram wrote:

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.

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

 

[Kip Ingram]

* Jon Elson <jmelson@wustl.edu> wrote:

Kip Ingram wrote:


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