On Sunday, January 20, 2019, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:
It's more for the purpose of designing analog IP cores which require manual
"finesse" when being placed and routed.
The actual place and route of the SoCs and MCUs will of course be done
automatically using the nice place&route tool from Andreas.
There are a number of NxN and NxM Dependency Matrices that I would prefer to be laid out parametrically or manually, as separate library cells, FOLLOWED by using a nice autorouter tool.
The amount of CPU time taken by an autorouter to identify something that is *already known* by a human to be regularly structured is going to be a waste of time and power, and it is unlikely to be able to spot that it may be laid out regularly in the first place.
I have seen the results created by autorouters. They are a dog's dinner mess, and the algorithms an insane order of complexity.
Giving autorouters limited rein and doing a complex design in a hierarchical fashion will be critical to getting a sane layout.
You may be thinking of a different couple of orders of magnitude less than the task I have in mind, here David. I am designing a quad core 800mhz design with L1/L2 cache, multi issue out of order vector processing, virtual memory and 16, 32 and 64 bit IEEE754 FP units (we may also add FP8, have to see).
Performance target is 4 32bit FP FMACs per core per cycle, so a total of at least 16 FMAC ALUs, potentially double that, to minimise data routing (a trick I learned on comp.arch: ALUs are cheap, data routing horribly expensive).
I am NOT going to throw such a massively complex design at an autorouter and hope for the best. It would be flat out insane to consider.
The hybrid hierarchical approach would allow the autorouter to lay out an FPU FMAC cell, that, on successful completion, can be incorporated into a larger ALU cell (per core), that in turn may be incorporated into a CPU Cell, that in turn may be incorporated into an SoC final layout.
Each time *using* the autorouter however NOT repeat NOT to allow it to REDO cells that have already been done: ONLY allow it to place and route them.
Restricting and simplifying the scope of work needed to be done by SEVERAL orders of magnitude.
In this way I stand a chance of having a complete design in a sane amount of time.
-David
> Also, again, the ability to recursively include PCB (or library parts)
> within PCBs aka Cells.
>
> I did not reply earlier, the reason for this is firstly a full cell may have
> already been done (manual or auto routing) saving time and CPU , secondly,
> certain layouts may simply be far too complex or regular and may need to be
> generated either programmatically or by having blocks that the autorouter
> is permitted to place and route but not alter, thus saving time and also
> making the design easier to verify.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68