[Libre-soc-dev] NGI POINTER gigabit ethernet router ASIC roadmap

[Tobias Platen]

On Mon, 2021-11-01 at 11:11 +0000, lkcl wrote:
> (Staf, summary, i know you are busy with deadlines: no real change
> here for you)
> 
> there is not much time to get a lot done and not enough full time
> committed people to do it.  therefore some tough decisions need to be
> made to limit what goes into the ASIC.
> 
> we have 5-6 months to get the entire HDL ready and simulated for the
> gigabit router ASIC.  layout will have to start around month 4-5 into
> that, with preliminary HDL.  total available time including the MPW:
> ELEVEN months.
> 
> that is all.
> 
> bare minimum features:
> 
> * MMU
> * bitmanipulation ALUs
> * reasonable performance (i.e. not 1 instruction per 10 cycles as we
> have with TestIssuer)
> * RGM-II ethernet interfaces (5 for preference)
> * UTMI / ULPI interfaces (2 for preference)
> * JTAG
> * UART (16550 for preference)
> * GPIO (plain and EINT)
> * SDRAM
> * DMA Engine
> 
> everything else is unimportant.
> 
> * there is not enough time to do out-of-order (it was 5 months just
> doing the 6600 experiment), a FSM is too slow therefore we do an in-
> order core making sure to plan ahead for OoO (use
> ReservationStations, use MultiCompUnits)
> 
> * SVP64 again has to be cut. SimdSignal is not ready in time, elwidth
> overrides are not ready in time (simulator or HDL) and an Issuer for
> SVP64 is particularly complex: that was learned from TestIssuer. it
> also greatly increases the number of regfile ports needed.
> 
> * the FP unit again has to be cut.  it is not important for a router
> ASIC.  too much adaptation / completion is needed to make it Power
> ISA 3.0 compliant
> 
> 
> Staf: if you can still do regfiles with byte-level write-enable this
> will save time when we get to SVP64 (which if we get the other EU
> funding will be sooner rather than later)
> 
> Jean-Paul: when we did DFFs/SFFs for regfiles they were distributed
> extremely optimally right the way through the layout.  the actual
> ALUs were distributed as well, and it was both very cool and well
> routed.
> 
> but, for fixed size (compact) regfiles that are basically SRAM
> blocks, this is a very different scenario, and having those SRAMs
> (regfiles) up in the top row is going to cause huge routing
> congestion.  something to think about.
> 
> Dimitry: if you can do the bitmanip instructions in the Simulator
> (convert verilog reference code to Power ISA pseudocode) that would
> be very helpful.  this is under a new (approved) NLnet grant, we can
> add you to Libre-SOC team, i will take care of 3mdeb.
> 
> Jacob: if you can keep an eye out and coordinate with Dimitry on the
> pseudocode / simulator, it would be good if you could do the HDL for
> the bitmanip instructions.  you will need to work together on shared
> unit tests.
> 
> note: *please do not compromise performance* or waste any extra
> design time which we do not have by attempting to force the
> instructions to be constant time.  constant time for the bitmanip
> instructions is NOT on the requirements, i have made this very clear
> in the NLnet Grant. there is NO user GUI or console interaction, it
> is a NETWORKED device not a Graphical Interface device, and therefore
> a timer may be added to delay network packets (part of the DMA
> Engine) which achieves the same end result.
> 
> Andrey: we need a pinmux and peripheral autogenerator.  it is planned
> 2+ years ago and the frontend is already done, it generates CSV/JSON
> files. litex is NOT going to be used, Florent has had 3 strikes (3
> opportunities).  instead we use nmigen-soc and CSR auto-allocation,
> all dynamically allocated.  integration with fuse-soc and nmigen is
> apparently underway: this *may* prove useful but we have to see how
> it goes.
> 
> Varun: i am waiting to hear back from you if you would like to do
> your MSc on the peripherals.  as i wrote to you i have been able to
> track down the RGMII code by Harry Ho: he completed Eth Rx but had
> not completed Eth Tx in nmigen. it is only around 80 lines of nmigen
> HDL to add that functionality and we have what we need.  also there
> is a UTMI/ULPI interface already written which i tracked down. 
> testing these with cocotb and other unit tests and so on will be
> important.
> 
> Tobias: you and i need to do the MMU and memory infrastructure.  this
> is really important to have, because we need to be running OpenWRT
> with an MMU.
I agree, I hope that I will be able to work on the MMU and memory
infrastructure about 10 to 15 hours a week. 
> 
> Cesar: if you and i can work on the In-Order core, in particular if
> you can take care of the Issuer, i will pull together the main pieces
> you will need, make small adjustments to Core, create
> ReservationStation FUs.
> 
> Kyle: if you can add options to be able to run TestIssuer or the new
> InOrderIssuer (when it is ready) so that comparisons to make sure the
> new HDL gets the right answers compared to the original, that would
> be great.
> 
> a more "sophisticated" Test API would be to have "breakpoints".  one
> of the issues we will run into is that the in-order core will have
> overlapping instructions, because of pipelining.   but, of course, if
> single-stepping there *will* be no overlap, and there might be
> overlap bugs.
> 
> therefore, the option is needed to allow a *group* of instructions to
> run, and to take a snapshot State afer a  *group* has run.
> 
> basically, breakpoints, just like in gdb.
> 
> that's mostly it.  any questions.
> 
> l.
> 
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev