[libre-riscv-dev] minimum viable ASIC

* [libre-riscv-dev] minimum viable ASIC
@ 2020-05-08  9:50 Luke Kenneth Casson Leighton
  2020-05-08 10:29 ` Staf Verhaegen
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Luke Kenneth Casson Leighton @ 2020-05-08  9:50 UTC (permalink / raw)
  To: Libre-RISCV General Development

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)
* 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.
* 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@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

^ permalink raw reply	[flat|nested] 21+ messages in thread