[libre-riscv-dev] 130nm for the hackers : finally a reality ?
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Jul 1 14:56:33 BST 2020
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
they also actually *save* time as the alternative (standard) unit tests are
a lot more code.
> > 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
> > > 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
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.
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.
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the libre-riscv-dev