[libre-riscv-dev] Introduction

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Jan 30 20:58:25 GMT 2019


On Thursday, January 31, 2019, Aleksandar Kostovic <
alexandar.kostovic at gmail.com> wrote:

> Hi Luke,
>
> Yes i actually have read it fully. I am currently building the whole risc-v
> toolchain along with spike simulator. Excited to play with that!


I found that using the sifive repos got the buildroot up and running the
quickest, i think i only had to make 1 kernel config change: enable SBI
Console.


> Also i have checked out the nmigen and i am pleased to say it am getting it
> very well. Altho its not what i am used to, i find it quite minimalistic.


Yes, that is the really interesting part, for me, and i think it is a
reflection more of how simple HDLs are.


> Most of examples listed in nmigen repo are under 30 lines of code and that
> is super nice. Its not as verbose as i thought it would be, so thats a
> plus. It really will be keeping us sane during the design as it will ease
> the code understanding. I think i got this as far as nmigen goes.
>
>
Cool. I particilarly like the FSM and Memory classes, and also i found
another python style class that can help with making pipelines. It
overloads __getattr__ and generates a sync.eq thing depending on the
pipeline stage number.

The FSM class is really good as it is very difficult to get state machines
both correct *and* clear in verilog.


Also i have read upon the spectre and meltdown stuff. Sure we could rely on
> software patches, but its better to have them in hardware. I am yet to
> understand how a possible solution would be for doing the patches in
> hardware, so i wont make any conclusions on it.
>
>
Spectre is basically hell for OoO. Dealing with it in hardware just isn't
that simple.

Jacob explained it well: past or future instructions affect the completion
time of the current one. This occurs through resource starvation of *any*
shared resource.

So that includes internal data buses, register file ports, shared ALUs,
operand forwarding buses, caches, memory ports - EVERYTHING.

Point being, it's not just about the L1 cache, it'svthe entire OoO paradigm
that's shot to s***


> I think i am getting the flow of the development and i and getting most of
> the stuff. So far so good :)
>
>
:)



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


More information about the libre-riscv-dev mailing list