[Libre-soc-bugs] [Bug 502] determine SRAM block size and implement it

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue Dec 22 12:41:03 GMT 2020


https://bugs.libre-soc.org/show_bug.cgi?id=502

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #100)
> Hello Luke,
> 
> Staf is now in a state where he can provides me with a first
> version of the SRAM block. So would it be possible to include
> instances of thoses block inside the ls180 dry run ?

well.. yes... if i knew how it was done.  i think the most sensible
thing to do is: you and Staf create a small example, first.  doesn't
matter how it's created: verilog, vhdl, nmigen/ilang, doesn't matter.
it also doesn't matter where it goes: soclayout/experiments12, or
alliance-check-toolkit.

also what i would recommend is to include that 1k DFF SRAM, although
i recommend you make it 512 bytes (and i will include two) because
yosys-abc goes mental above 512 bytes, kicking in a different "technique"
which can take several gigabytes of resident RAM.

with a small example that shows both, we will know if there are any surprises.

it might be necessary for example to put the model into its own special
Cell Library, given its own "instance name", so that it is separate and
distinct from the "standard" Cell Library for memory, which results in the
DFF SRAM being substituted.  i am not the best person to write such a
Cell Library as i've never done one before.

once that's completed i will be able to see how it works, and will be
able to do the same thing for ls180.

at the moment, i have no idea how to use the model shown in comment #8

also, we will know if, like last time, there are any surprises as far
as NDAs are concerned.

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


More information about the libre-soc-bugs mailing list