[libre-riscv-dev] [Bug 154] Cell for Dependency Matrices is needed

[bugzilla-daemon at libre-riscv.org]

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

Staf Verhaegen <staf at fibraservi.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |staf at fibraservi.eu

--- Comment #19 from Staf Verhaegen <staf at fibraservi.eu> ---
> if *that* was returned to its original implementation (single bit inputs, single bit outputs) then the valid concerns you raise would disappear, allow me to explain.
> ...
> in this regard they are extremely similar to how OpenRAM works, and consequently i believe a similar programmatic layout approach may be deployed.
>
> thus even if we did have to redesign the layout per geometry it is such a
> trivial task (move some fully and exclusively straight and horizontal wires up
> or down a bit) that even without having done this task yet i would be honestly
> surprised if it was problematic or costly.

Having been a SRAM compiler developer in my previous live, I tend to have a
different opinion on trivialness of maintaining a DepenceMatrix compiler and
porting it to new nodes. For porting an existing SRAM compiler to a new node we
accounted I think 9 manmonths of work. I agree, that for the DependencyMatrix
the work on the SRLatch will be much less than on the SRAM bit cell but, still
...

That said I like having different opinions, would be nice if both options could
be included and compared to show the actual benefit of doing the
DependencyMatrix in a custom way. Having the DependencyMatrix as nmigen code
like I propose definitively seems the trivial option to me. It will also allow
to easily test design on FPGA etc.

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