Part I: An Introduction to the RISC-V Architecture

[@UliTroyo]

*INTRODUCTION*
5:14 RISC-V origin story
6:19 RISC-V foundation
6:57 foundation Members
7:26 status of the RISC-V specifications
-
*BASICS*
8:49 RISC-V ISA naming conventions
9:35 the standard extensions
11:37 register file
12:43 RISC-V modes
-
*RISC-V INSTRUCTIONS*
13:29 RISC-V reference card
14:36 compressed instructions (C extension)
15:47 code size comparison
16:13 atomics (A extension)
16:56 fence instructions
18:00 CSR and ECALL instructions
-
*RISC-V CONTROL AND STATUS REGISTERS (CSR)*
18:46 what are control and status registers
19:33 identification CSRs
20:19 machine status (mstatus) - the most important CSR
21:29 timer CSRs
22:21 supervisor CSRs
23:14 virtual memory
24:43 physical memory protection (pmp)
-
*RISC-V INTERRUPTS*
26:23 RISC-V interrupts
27:59 machine status (mstatus) - as it relates to interrupts
29:03 machine interrupt cause CSR (mcause)
30:13 machine interrupt-enable and pending CSRs (mie, mip)
31:24 machine trap vector CSR (mtvec)
32:14 trap handler - entry and exit
34:46 interrupt handler code
35:41 compiler interrupt attribute
36:43 RISC-V global interrupts
37:22 PLIC interrupt code example
38:26 RISC-V interrupt system architecture (M-mode only example)
-
*MORE INFORMATION*
38:51 Resources
-
*QUESTIONS*
41:25 Does RISC-V define a 128-bit architecture, and does it support the compressed instructions?
41:48 In M-mode, would you need to have both the mie bit set in mstatus and the proper bit in the mie register?
42:14 Which version of the Linux kernel has support for the RISC-V architecture?
42:36 Which single-board computers support this Linux kernel?
43:10 What is precisely the definition of "hart"?

[@ikidu1102]

This should be pinned. Great job!

[@rmk_online]

Great job! Thanks for the help.

[@stok3si3]

Starts at 3:45

[@enotdetcelfer]

One could argue 8:48 even :P

[@ShashankHegdeabc]

it would be great if the presentation deck was made available in description. :)

[@pitankar]

sifive.cdn.prismic.io/sifive/25f3cf28-47ae-4cea-9e64-ecd43dea7f11_An+Introduction+to+the+RISC-V+Architecture.pdf

[@adamhorvath88]

15:46 Shouldn't this chart be titled Binary Size Comparison? The compilers were working with the same sources if I understand it correctly.

[@totohayashigo]

good job !!!

[@w3w3w3]

Amazing! =D thanks so much

[@Clark-Mills]

Trusted hardware thought...
Given that the up and coming open ISA that RISC-V brings and potential silicon that will be certified as compatible with the RISC-V architecture... there might be a way for us to have a processor that is likely to be compliant and will likely fail a "magic packet" type embedded in silicon exploit.
We could get a core fab'd in country "A" and the same core fab'd in country "C". We get one each of these cores and run them them in lockstep, we would expect similar results out of each beast. As soon as one cores outputs differ from the other we can raise a flag and signal badness.
It is improbable that both cores would contain identical backdoor triggers given their differing origins.
This could be "trusted hardware" of sorts, no?

[@aladdin8623]

I appreciate your idea, but the problem with all, so called "trusted" security hardware is a general one. Even if the ISA is freely usable, there is no real possibility to verifiy, what is going on beneath the ISA. I mean the microcode, which is a black box especially to software developers. Even a hardware developer can not really find out, what an unknown chip actually does at the transiator level without papers.

[@diegonayalazo]

Thanks

[@roaaalsadeq3530]

hello..can you help me to translate code from C language to RISC-V?
أعجبني
تعليق
مشاركة

[@truectl]

The worst kind of "powerpoint" video. We can read slides. Reading them to us is of no help.