[libre-riscv-dev] minimum viable ASIC

[Yehowshua]

> On May 8, 2020, at 5:50 AM, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> i'd like to discuss what the minimum viable ASIC would look like,
> that, if we're happy to do so, we could hit the October 2020 deadline
> with it and not be completely stressed.
> 
> my take on this is, which i've added here (do edit, comment etc.
> https://libre-soc.org/180nm_Oct2020/)
> 
> * a Wishbone interface.  this allows us to drop *directly* into
> already-written Litex "SOC" infrastructure (leaving all of us in the
> core team free to focus on the essentials)

This is a good call. I talked to Florent from Enjoy Digital last week, and he said he’s willing to help with LiTeX integration for LibreSOC. He also said Enjoy Digital is available for hire depending on how much must be done.

> * the dependency matrices are essential.
> * a Branch Function Unit is essential (minimum of 1)
> * Load/Store Function Units are essential
> * so are multiple register file files (SPRs, Condition Regs, 32x INT Regs)
> * the integer pipelines (integer and logic instructions) are essential
> (the FP ones not so much)
> * a very very basic Branch Prediction system (fixed, but observing
> POWER branch "hints")
> * a very very basic Common Data Bus infrastructure.
> * a TLB and MMU are not strictly essential (not for a proof-of-concept ASIC)
> * neither in some ways is a L1 cache
> * interfaces we need as a bare minimum include GPIO, EINT, SPI and
> QSPI, I2C, UART16550, LPC (from Raptor Engineering) and that actually
> might even be it.
> 
> secondary priorities (which are approximately in priority order)
> 
> * a PLL (this is quite a lot however it turns the ASIC from a 24mhz
> design into a 300mhz design)
> * a TLB and MMU (in combination with a PLL if it is GNU/Linux OS
> capable we have an actual viable *saleable product*, immediately)
> * dual L1 Caches with the 2x 128-bit-wide L0CacheBuffer to merge 8x LD/STs
> * multiple Common Data Buses to / from the RegFile along with a 4x
> "Striped" HI/LO-32-ODD/EVEN access pattern.
> * multi-issue
> * PartitionedSignal-based integer pipelines
> * an FP regfile and associated FP pipelines
> * SV compliance
> * 128x INT/FP registers
> * GPU-style opcodes - Jacob you mentioned Texturisation opcodes as
> being more important than e.g. SIN/COS.

And keep in mind, if we aren’t able to finish the GPU opcodes by October/November/December(according to Staff - these are the available 2020 slots), Raptor has agreed to foot 20k for the silicon, again, in exchange for some equity.

> * additional interfaces such as RGB/TTL, SDRAM, HyperRAM, RGMII,
> SD/MMC, USB-ULPI
> * a pinmux
> 
> so the *absolute* basic - minimum viable ASIC - is to be honest really
> not a lot.
> 
> now, i was contacted by Rudi, from http://asics.ws, he has some time
> available, he's been doing ASIC design for 20+ years.  he's more than
> happy to take care of the interfaces for us.  we define the set, he
> will get on with it, design the Wishbone Registers etc. for us.
> 
> given what's already been achieved, that *really does* leave us with a
> very small amount of work to do.  the integer pipelines are something
> that's really quite straightforward to do, and basically "track" the
> work that Michael's been doing on the simulator.
> 
> one essential aspect of the simulator work is: unit tests have to be
> done.  those *exact* same unit tests we can use to test the hardware
> version, either against the simulator *or* against qemu, it's all the
> same.
> 
> if MarketNext find people fast, we will have a whole batch of people
> who can help hammer through the tasks, which will give us the space to
> focus on "difficult" bits.
> 
> thoughts appreciated.
> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev