[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #127 from Staf Verhaegen <staf at fibraservi.eu> ---
(In reply to Jean-Paul.Chaput from comment #126)
> 
> * For the layout, less so. I reason along the same lines as Staf, but
>   maybe less radically (or I'm lagging behind).
> 
>   * If you break your design in too tiny blocks you will prevent
>     the placer to perform some placement optimization. So, in
>     my opinion you should have one or two level of hierarchy in
>     the layout placement.

Placing the standard cells itself can be done quite fine grained without the
need for open room (extra open room is only added to get the pin density low
enough so the router can complete). If you want to place higher level blocks of
different sizes and shapes you seriously complicate the problem. Given that the
normal placement of standard cells is already a difficult NP problem you don't
want to add such extra complication to the algorithm. Existing algorithms will
also no be able to cope with it either (proprietary placers allow to have
multi-row macros for for example 4-bit registers).

And it is not only optimization in placing that you block but also optimization
in synthesis. If you have for example an inverter on the output of such a low
level block that is connected to the input of another block with an inverter on
it these two inverters will be removed during synthesis after flattening the
design. This can be generalized in that you block synthesis optimization in
each path that goes over the block boundary if you don't flatten.

>       The top level floorplan (full chip) and maybe a supplemental
>     one in big top-level sub-blocks.
>       Staf recommend to do it completely flat (his arguments makes
>     perfect sense, but I need to see it by myself).

I can agree that if you make a multi-core chip it may make sense to do the P&R
on one core and manually place the different instances of the cores in the
floorplan.
But the use case I am focusing on is people that develop their design using HDL
like nmigen or SpinalHDL on a FPGA and then order an ASIC for that. For them
the ASIC compilation should be a fully automated process and they should not
have to take care of floorplanning. In such a setting flattening seems the most
efficient approach and if the compiler wants to keep hierarchy it should be
able to determine itself where to keep hierarchy on its own.
I see it the same way as the optimization flags for compilers; most people will
stick to use -O[0-3] and only for very specific cases one fine-tunes the
optimization flags to get optimal performance or even use some hand coded
assembly somewhere.

-- 
You are receiving this mail because:
You are on the CC list for the bug.