[libre-riscv-dev] 130nm for the hackers : finally a reality ?

[Luke Kenneth Casson Leighton]

On Wednesday, July 1, 2020, Staf Verhaegen <staf at fibraservi.eu> wrote:

>
> What is time-line that would fit ?


well, if we had other people helping then i would be confident that we
could do something by october.

however i am *literally* the only person doing anything full time (aside
from Jean-Paul who is doing the layout preparation in coriolis2).



> Google announced to do a run somewhere in November but did not specify
> when the design has to be ready for the tape-out. So this is an unknown.


ah ok.  imec actually look better, then.


> I did put end of October for design to be finished to have some room to
> get the design P&Red and DRC clean for the actual tape-out mid November;
> imec also wants first layout two weeks before that final tape-out date,
> e.g. therefor the end of October deadline.


ok that is slightly better.


> So there are 4 months left; maybe some of the formal proof can be done
> after tape-out etc. ?


we actually use the formal proofs as standard unit tests because they give
better confidence.

they also actually *save* time as the alternative (standard) unit tests are
a lot more code.

ironic!


> > indeed.  well with a smaller ASIC, you get more :)  the availablebudget
> does not change.
>
> For the external manufactured things we agreed on paying the money based
> on the invoice from imec, this was also to take into account to possibility
> that the prototype would take more area.
> If we use less budget I suppose part of that budget could be retargeted
> for the 0.13um run we may do afterwards. But let's have this discussion
> when it becomes more clear how much area actually will be used by the
> prototype


good idea.


>
> > > For the 0.18um prototype we can go up to 208 pins for a QFP with 0.5mm
> pin pitch or even 256 pins for a LQFP with 0.4 pin pitch.
> >
> > it's likely we'll be below this simply on time it takes to testdifferent
> peripherals in an FPGA.
>
> I thought you were going to use litex peripherals which I think should
> already be tested.


yes.  Raptor Engineering is working on doing that litex testing and
confirmation.

just so you know: they... found several deep flaws in litex peripherals,
such as the QSPI code.  it was not only terribly slow, the FSM would only
have worked on a few SPI NOR ICs.

their version saturates the QSPI bus and properly implements the SPI
protocol as well.



> With some precautions to be sure to not cause the full chip to fail we can
> put not-fully tested peripherals on the design. Also IO not used by
> peripherals can be GPIO pins.


ok.

btw whilst i'd like to do the pinmux as it saves a lot of manual code
writing i think we may have to skip it and do dedicated pins.

just have to see.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68