[libre-riscv-dev] System-Wide Complexity Rant (was store computation unit)
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Jun 6 03:09:14 BST 2019
On Wed, Jun 5, 2019 at 4:53 PM Samuel Falvo II <sam.falvo at gmail.com> wrote:
> Right; I get this. My point is that this initialization can (and,
> arguably, should) be the domain of the system hardware in which it's
> mounted -- the RAM controller core *itself* should take it upon itself
> to at least provide a *minimally functional* SDRAM configuration at
> reset time, so that the system firmware doesn't have to deal with it.
yyeah except the DRAM controller even changes the impedance and the
timings at both ends. what settings do you use? DDR4 even starts to
take temperature fluctuations into account, the speeds are getting so
high.
if it wasn't a parallel bus this would not be a problem.
diff-pairs solve this no problem, hence HMC and Gen-Z (both based on PCIe PHYs)
> (The vastly simplified interface to HyperRAM seems to suggest I'm not
> the only one to think along these lines.)
yehyeh, we like HyperRAM.
> Should I have to rewrite/recompile my entire bootstrap and/or kernel
> just because SDRAM is replaced by WhizBang RAM five years from now?
basically... in the embedded space... yes. because the product
lifecycles... well, if you're not buying new product every 12-18
months, the corporates haven't done their job properly by building in
enough obsolescence.
oh did i say that on a public mailing list?
> I think that's total bullshido,
preeetty much
> and much of the philosophy of the
> Kestrel's hardware development reflects this. It's why the KIA core
> has a hardware-resident FIFO (so it can be useful in the absence of
> interrupts), why this SIA blocks the CPU when transmitting too fast
> (so the same debug print routines works in emulation and in live
> hardware), and why the SIA cores come out of reset with baud rates set
> according to their intended use (so terminal driver is at 9600 bps be
> default, while the block storage is set to 115Kbps by default), etc.
nice.
> If we just focused on the problem solving, things might be better;
> but, it doesn't happen that way as far as I can see. So we get
> ultra-complicated standards like SDRAM initialization protocol, SD
> card initialization protocol (which actually exposes voltages and
> currents to the software layer; a layer which has no business dealing
> with such matters),
this one i _do_ understand, because they've had to build in backwards
and forwards dynamically-detectable compatibility.
fortunately, for embedded (and early boot) purposes, most SD/MMC
interfaces support "SPI mode", despite the SDCard Association
declaring "my mummy says you gotta switch dat off for SDMMC 4.0"
*sigh*.
:)
SPI mode is single-bit bi-directional and does not involve any of the
voltage / current negotiation, nor does it involve going about
25mbit/sec.
you can usually just go straight into an extremely simple SD/MMC
initialisation sequence, and it so happens to be preeetty much the
same sequence (the same command) for SPI *and* QuadSPI devices.
> USB and its entire driver stack architecture, ...
> I could go on.
yeah i know of no USB2 stack that fits into 16k. however.... some of
ST's ICs support multiple USB1.1 endpoints extremely well, and they
are only like... 32k-128k on-board SRAM.
> What I explicitly don't want is an $800 paperweight if I botch the
> system firmware,
haha, now you know why the pinmux for the libre riscv soc brings out
JTAG, SD/MMC and UART0 TX/RX onto pins that are highly likely to go to
an *external* SD-Card port :)
this design trick i learned from allwinner.
Bank A, 10-15
https://libre-riscv.org/shakti/m_class/pinouts/
Bank C 52-55 is actually the exact same JTAG port just muxed by an
external hard-selection pin that sets the default power-on/reset
pinmux. it's deliberately muxed with SPI so that, again, you only
need to bring out 4 wires to both boot or debug a system.
> The Kestrel-3 would have been done two and a half years ago had it not
> been for that RAM chip. OTOH, that also gave me the time needed to
> discover and learn about Yosys and the more open source friendly
> development boards out there, to find libre-riscv, and to learn about
> scoreboards and OoO techniques, so maybe a mixed blessing?
yay! :)
More information about the libre-riscv-dev
mailing list