Bringing up the OpenHW Group RISC-V tool chains
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61770 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Group theoryReduced instruction set computingCollaborationismComputer hardwareOpen sourceData modelExtension (kinesiology)Standard deviationOpen setMultiplicationSelf-organizationFormal verificationSoftwareSystem on a chipCore dumpTerm (mathematics)Open setOpen sourceFormal verificationSoftwareCore dumpComputer hardwareMusical ensembleElement (mathematics)Task (computing)Projective planeGroup theoryEndliche ModelltheoriePoint (geometry)MereologySoftware developerBitSelf-organizationDirection (geometry)Dependent and independent variablesCollaborationismFamilyComputer architecturePhysical systemIntegrated development environmentKey (cryptography)Level (video gaming)Universe (mathematics)Mixture modelRevision control32-bitEnthalpyMicrocontrollerQuicksortImplementationDifferent (Kate Ryan album)Structural loadExtension (kinesiology)Group actionStandard deviationReal numberProof theorySlide ruleMulti-core processorCartesian coordinate systemPower (physics)File formatOperating systemComputer animation
08:59
Core dumpSoftwareEmulationData modelSoftware development kitComputer hardwareAbstractionProcess (computing)Open setCompilerMachine codeJava appletModule (mathematics)Open sourceObject (grammar)Table (information)TeilkörperArithmetic logic unitOperations researchProgrammschleifeExtension (kinesiology)Structural loadEvent horizonFunction (mathematics)Revision controlAssembly languageWeb pageBitInformation securityProjective planeTeilkörperRevision controlInterface (computing)MultiplicationParameter (computer programming)Self-organizationCore dump1 (number)Computer hardwareSoftwareScaling (geometry)Line (geometry)Level (video gaming)Data storage deviceProgramming languageRange (statistics)Event horizonAbstractionFocus (optics)PlanningView (database)CompilerEndliche ModelltheorieCASE <Informatik>MereologyScalar fieldSet (mathematics)Rule of inferenceHeegaard splittingTerm (mathematics)CompilerImplementationLogic gateFloating pointFunctional (mathematics)FreezingGoodness of fitModul <Datentyp>IntegerSoftware developerForcing (mathematics)Library (computing)Extension (kinesiology)Machine codeEmulatorOrder (biology)Arithmetic meanProcess (computing)InjektivitätDampingStandard deviationComputer animation
17:52
Function (mathematics)Revision controlCore dumpAssembly languageWeb pageExtension (kinesiology)EmulationLatent heatData modelSoftware testingInterface (computing)Server (computing)Linear regressionCompilerSubsetPort scannerTerm (mathematics)Group theoryTeilkörperSoftware testingPoint (geometry)Linear regressionSoftware industryAssembly languageData compressionLatent heatCartesian coordinate systemSet (mathematics)CompilerSpeichermodell10 (number)Flow separationINTEGRALArithmetic progressionStructural loadOpen setComputer hardwareSoftwareKörper <Algebra>GradientGroup theoryComplex (psychology)Limit (category theory)QuicksortLinker (computing)Software bugProof theoryRevision controlBound stateCompilerBitExtension (kinesiology)Group representationProjective planeMereologyWeb pageDifferent (Kate Ryan album)Right angleEndliche ModelltheorieArmMultiplication signCore dumpLevel (video gaming)SubsetSuite (music)Standard deviationPattern languageNetwork topologyGenerating set of a groupComputer programWave packetElement (mathematics)Semiconductor memoryCycle (graph theory)Game controllerCentralizer and normalizerPhysical systemTeilkörperSpacetimeThermal radiationOperating systemProgramming languageConnected spaceForm (programming)HookingImplementationServer (computing)EnthalpyComputer animation
26:45
Revision controlLatent heatTerm (mathematics)Group theoryTeilkörperRepository (publishing)Server (computing)Data modelOpen setFormal verificationCore dumpSoftware testingSoftware developerCoprocessorGenerating set of a groupRight anglePoint (geometry)Decision theoryType theoryImplementationQuicksortExpert systemElectronic design automationParameter (computer programming)Task (computing)Flow separationProjective planeCompilerCASE <Informatik>Dependent and independent variablesDifferent (Kate Ryan album)MereologyComputer hardwareRevision controlOpen setMusical ensembleDataflowSoftwarePlanningWave packetFreewareBitSystem callAssembly languageMultiplication signStandard deviation1 (number)Term (mathematics)DampingTape driveSoftware bugLatent heatExtension (kinesiology)SpacetimeCodeOperating systemStructural loadProcess (computing)DivisorArithmetic meanBlock (periodic table)Computer animation
35:38
Program flowchart
Transcript: English(auto-generated)
00:07
So, thank you all very much, thank you for coming along. My name's Jeremy Bennett, I'm Chief Executive of Embercosm, but Embercosm is an engineering-heavy company.
00:22
We only have one full-time non-engineer in the whole company, and it's not me, so actually I'm a working engineer as well as running the company. And we develop open-source, mostly compiler toolchains, but we also have some open-source AI, and we also have some open-source operating system stuff,
00:40
and because most of what we do is pre-silicon, we do an awful lot of open-source silicon chip modeling. But I'm also here with another hat on, which is that I am chair of the Open Hardware Group's software task group, so I'm responsible for all the software developed for the Open Hardware Group, and I'll talk a bit more about them in a bit.
01:01
And this talk is part technical, but it's partly about the actual practical side of how we go about developing complex software for an open architecture like RISC-V. So let's tell you a bit about the Open Hardware Group.
01:25
So it's a not-for-profit, it's a member-driven collaboration, and it's a mixture of industry, companies like mine, some big companies that you will recognize, NXP as a member for example. It has academics, so quite a few universities are members and part of it,
01:47
and it also has individual members. You can contribute as an individual, and some of the work I'm going to talk about has been just done by people who are individual members. And the goal is high quality, and that high quality is the key thing,
02:01
open source hardware development. The sort of open source hardware that you can put in a commercial chip and be confident you can send it off to be fabricated. So it's collaborative and it's open. It's an open development model, so all these things are open to all. Now the organization's the Open Hardware Group,
02:23
but its cores are known as Core 5 or Core V. So we have a huge family of processors, I'll talk about them. Everything from the smallest RISC-5-32 to the biggest RISC-5-64 designs. And these are standard RISC-5 cores, but with some custom ISA extensions for RISC-5.
02:45
The chief executive is Rick O'Connor, and those of you who have been around for a few years will remember Rick because he was the first chief executive of RISC-5 International. And he's moved from the open source specification world to actually delivering real silicon IP.
03:03
Let's look at the ancestry. So Open Hardware Group grows out of an academic industry project called the Parallel Ultra Low Power Processor Project, PULP. And that was a collaboration originally between ETH Zurich,
03:20
the University of Bologna, and STMicroelectronics. STMicroelectronics no longer active in it, and it predates RISC-5. The first part of PULP was done with open RISC, but for the last many years, it's been a RISC-5 project. And the idea is to get very, very low power multi-core systems.
03:41
So that's where we come from, and the cores started off as these academic research cores. And the point about academic research cores is they are designed to push the forefront of knowledge forward. They're not designed to be exhaustively tested for manufacturing and use in a commercial deployment. That's not the purpose of a university.
04:02
So the natural transition is that Open Hardware Group takes that as an outstanding technical base, and then takes it into a robust standard, okay? We have loads and loads of members, so I've copied this off the website, and it's the wrong format.
04:22
I really want a wider and flatter one, but you'll probably see some logos there. You'll see Embercosm's logos there. The astute of you will notice that Amazon Web Services appears to be both a member and a partner. I think they transitioned from a partner to a member, and the slide wasn't properly updated, okay? So we have lots and lots of members.
04:42
I think it's up to about 70 now, okay? And it might be worth just saying that when you become a member, yes, if you're corporate, you have to pay a membership fee. But that's not the big thing. You can only become a member if you commit resource
05:02
in terms of what you're going to contribute, and that dwarfs any membership fee. You cannot be a member unless you're going to do something, okay? We don't have sleeping members. You've got to be active members, okay? In terms of an organisation, it's very lightweight, and this is one of the big contrasts with RISC-V International.
05:23
At a technical level, we only have five committees. We have an overarching technical working group which has the overall responsibility for the engineering direction. And it has co-chairs. It has Jerome Queravol from Thales and David Lynch, and I can't remember where David Lynch comes from actually,
05:42
but two companies joined chess, and that meets every month as the final arbiter of technical stuff. And then all the work of this organisation is handled by just four committees. The CORS group, headed up by Ian Bink from Silicon Labs, and that is responsible for the tracking, the development of the CORS, okay?
06:05
The work is done by the member companies, but these are the groups that have oversight and make sure the quality criterion is maintained. There's a verification task group, and verification is actually separated from core development, even though the two are desperately tightly tied in.
06:23
And that's led by Simon Davidman of Imperus. There's a hardware task group, and this is a slightly strange name perhaps, but the point of the hardware task group is, though this is fundamentally a group developing silicon IP, we do have to have reference implementations,
06:40
and the first reference implementation should be coming out later this year, which is the core 5 MCU, and that has one of the 32-bit cores in it, okay? And lastly, the software task group, which I lead, assisted by Yunhai Zhang from Alibaba Teahead, and that's responsible for all the software projects.
07:01
And again, it's oversight. It's not doing the work, because if you want to be a member, you have to do the work. We do have a bit of a problem there, because we have mostly hardware members and not enough software members. In terms of the roadmap, we've got a flagship application core, that's the CVA6,
07:21
and that's a 64-bit full-blown RISC-V core designed to run Linux, and that comes out of the top-end pulp core under development. There is a smaller 32-bit core, the CV32A5, which is designed to try and do a small Linux system,
07:49
or of course, we've got the issue of getting Linux running on 32-bit anyway. You probably can only just make it out. Each of these projects has a target technology readiness level.
08:03
Are people familiar with technology readiness levels? A little bit, okay. Most of these are aimed at technology readiness level, which is proven in the environment. CVA5 is a bit different. It's aimed at TRL4, which is proven in the lab, and we've got other projects which are outside different levels,
08:21
but mostly we're aiming at TRL5. The flagship, the first project was the CV32E40P, which is a microcontroller class, 32-bit RISC-V implementation, and the first version of that is complete. The second version is under development, and actually, the work Nandini was talking about with built-ins
08:42
is primarily focused at CV32E40Pv2. You will see sitting there, there's something called the CV32E41P, and that's a bit unusual, because it's actually only going to TRL3, which is proof of concept, and it's being developed by Huawei under this group in order to test out the ZC star extension,
09:08
the new compressed extension, and the ZF in X, where you have a shared register bank for floating-point and integer. So it's only a proof-of-concept chip to verify that those work. And then we have a couple of more forward-looking ones.
09:22
CV32E40S is a version of the original CV32E40P aimed at security applications, and the really exciting one is the CV32E40X. That's a bit further out, because the X is a generic extension interface at the hardware level. So this is designed so you can take a core, it's really easy to add in a wide range of extensions,
09:42
and indeed, to the extent you can do the floating-point extension through the CV32E40X. So that's the roadmap we're sitting on, OK? So what about the software projects? Well, I'm going to focus on the tool chains, so the LLVM tool chain, the GNU tool chain, and because we haven't yet got silicon,
10:01
I'm going to focus on a couple of software projects, QEMU and the Verilator model. We have other projects, so I'm responsible for eight projects in tool. There's the SDK, the software development kit, that's actually joined with the hardware group. The hardware abstraction layer, so that we can actually make our software more easily portable as we do more and more of these chips. FreeRTOS with microcontroller,
10:22
you want to, if you're going to go for an RTOS, the obvious one to have to start with is FreeRTOS, and Linux, which is really aimed at the CVA6. So we've got eight projects under our belt. We have a rigorous engineering process, so those of you who work for big engineering companies are familiar with gate-based processes, OK?
10:44
So all of the way we manage these projects is through a gate-based process. You have a project concept gate. That's where you propose a project. You want to work on this project, you explain what it is and why we need to do it.
11:01
And the project will only go ahead if it's voted for by enough members, and members can't just vote and say, hey, that's a good idea, I'll say yes for everything. You vote for it, you're going to commit resource to it. Critical thing is this is a doing organization. So, OK, you then go and explore it, and then we got to a project launch gate. And that stage, not only do you know
11:22
what and why, but now you know how you're going to do it. What do I need to do to get this? And then the big one, the last one, is plan approved. And plan approved means you've resourced it, so you know when you're going to deliver it. And that's quite a big hurdle for some projects.
11:42
And then away the project work goes, I mean, this is a bit simplified, we all know work starts a bit in advance, but the way the project goes, and eventually you get to project freeze, where it's all done. Now, this is brilliant for hardware. It's a very hardware-centric view of the world, because a freeze means something. It's when your chip's gone off to be fabbed.
12:03
It doesn't work quite so well for software, so we've modified it for software. And the first two stages are quite generic, because typically we're working with a big block of common software. We're not writing a compiler from scratch, we're taking the GNU infrastructure, GCC, binutils, and all that, millions of lines of it.
12:22
And that's mostly not changed, and we're changing a bit. Now, some of that is quite the why and the how, the what and the why and the how is quite generic. It applies to probably all Core 5 chips, certainly maybe to all the 32-bit ones. And then for each specific chip, we have multiple plan approved,
12:41
which is where we work out when we're going to deliver it for CV32, E40P, V1, for V2, for S, for X, and so forth. And so we have a whole set of them. But it's still the same process of, you need to know it's properly resourced and so forth. So we'll see that a little bit in action, but that whole engineering focus pervades everything.
13:05
So let's put the content, what's the compiler toolchain? It's not just the compiler, it's the assembler, it's the low-level utilities, it's the debugger, it's the libraries, it's the emulation libraries, it's the standard C libraries, the C++ libraries. And in the ultimate world, if you look at GC,
13:21
this is GCC, it's many, many languages. It's Ada, it's the CC++ family, it's Fortran, it's Java, it's Go. These days it's Rust, it's modular too. And of course we've got things that sit at the high level like OpenMP and OpenACC. That's a huge lot of stuff. We hasten to say, we're a long way off having all of that for the Core 5.
13:41
But it's a lot of code. It's about, it's north of 12 million lines of code and it's a year or so since I last measured those figures. So it's big. And we're trying to get that all seamlessly worked through to work on Core 5. Now, we're not doing it from scratch. Of course, we're starting from RISC-V and then we're adding stuff to it.
14:01
And you can say that LLVM has the same components but they've got different names and a different set of languages. So let's look at the ISER extensions for Core 5. And the Core 5 ISER extensions, there are nine we're concerned with.
14:20
Eight of those come from the Pulp project. So extra addressing modes, post incrementing load and store. Hardware loops, more ALU operations, some special case branching operations. We've got MAC instructions.
14:41
Okay, we've heard about the event load. That's a multi-core feature. And then we've got the Pulp bit manipulation and the Pulp SIMD. Those are not standard bit manipulation and SIMD. Those are different ones, okay? But there's been years of development. The reason they're different is they predate a RISC-V bit manip and they predate RISC-V SIMD.
15:02
And you can see the Pulp SIMD is big. And the reason that Nandni knows so much about built-ins is she's done the built-ins to support those 220 SIMD instructions. So she's nearly finished. And then I think she's going away for a long holiday
15:22
where she never looks at another built-in again. And we've got ZC star. So we had the first GCC implementation supporting ZC star. Of course, these are standard RISC-V compilers. You can still use them for RISC-V. And the hot news is that Core 5 GCC has a pull request to put ZC star 1.0.1,
15:43
which is the freeze candidate support. Once that's been reviewed, that'll go in there, okay? So we've got a lot. The tool chain work is all about supporting these pulp extensions, okay? In terms of the built-ins, you've heard all about them,
16:08
but it's a lot of functions. It's not just Nandni. Nandni has a team with her, a team working on this. And we've got this naming convention. So we get from a naming convention
16:21
that built-ins for RISC-V are built-in underscore RISC-V underscore vendor underscore name. We've got so many, we're actually splitting up into ISA extension and name. There is a rule though, if you're, you can't just have, if what you're doing is a built-in, is it corresponds to a standard built-in,
16:41
then you must use the standard name. So for example, we have in our arithmetic, we have abs, so we've got built-in abs, which is a standard GCC built-in, okay? The built-ins, actually they have the same name for 32-bit or 64-bit. That is not overloading in the C++ sense,
17:01
because either you're running for a 32-bit target or you're compiling for a 64-bit target, you have one or the other there. There's not an overloading, okay? It's also the case if built-ins are not just another way of doing inline assembler, there's not a one-to-one mapping. So for example, for the SIMD addscaler, there are actually two different ways of adding scalars
17:20
in the core five SIMD, one where the scale is in a register, the other where it's a small integer and you can actually put it, there's actually an add immediate instruction. We don't have two built-ins, there's a single built-in, and if the second argument is a small constant that fits there, it will generate the immediate version of the instruction,
17:41
otherwise it will load it into a register. And that's part two of Nandi's talk for the future, because that's quite a lot harder to do in a built-in, okay? And there is a specification, it's big. If you put it into, if you generate PDF, it's 57 pages long, okay? So, and that's one of the things is built-ins,
18:02
built-ins are not quite as easy as you think. There are things you can get wrong there, and you do genuinely have to think and review it. It's under review at the moment, that's not finalized. Okay? So, testing. Now, if we're gonna do full testing of a tool chain, okay, we need a target which has all these ISER extensions.
18:22
They're not standard RISC-V, I can't just take standard RISC-V QEMU or whatever, okay? You can do some testing. So the standard GNU assembler tests, for example, don't need an executable target. They are pattern matching, have you generated something that looks right? Okay? You can do the same with built-ins. You saw it from Nandy's compile time only thing where you look and do a scan assembler to see,
18:42
has that built-in generated just one of the instruction I want? Okay? But more generically, you need to be able to execute your tests, okay? So we have two things. One is we have QEMU for Core 5. That's a project being led by Weiwei Li at the programming languages and compiler technology team
19:03
at Chinese Academy of Sciences in Beijing, okay? That's a work in progress. We're expecting that to become available later in 2023. And secondly, we're using Verilator models. How many people here are familiar with Verilator, Hansho?
19:21
Okay, most of you. Okay, for those who don't, it's a tool that takes a hardware design in Verilog or system Verilog and generates a C++ model from it, a cycle accurate C++ model. And Verilator models are really useful because A, they're easy to integrate to tool chain testing and B, they are what's called implementation models.
19:41
Most models come from the specification of the chip. These are the actual implementation. So we know what you're testing is, what is physically going on the chip. And when you have a model, it's not just enough to have a model, you've got to be able to hook to it. So typically you've got to run, wrap around some form of debug server so you can connect GDB or LLDB. And that's the work in progress. That's due to be completed in the next few weeks.
20:04
And then you'll be able to actually run on the actual model of the actual hardware. Testing policy. LLVM project uses the LLVM integration tester. That is a set of several tens of thousands of tests
20:24
from source code down to LLVM IR. Very comprehensive and we use that. But it isn't a set of execution tests. Now, LLVM does have an executable test suite, but it is a set of applications to run under an operating system.
20:40
And for a small microcontroller, they're not suitable. They need an operating system there. So we can't use the LLVM test suite. So instead we use a subset of the GNU regression tests to test LLVM compilers. And that's widespread. That's not something we've invented. That's been done for years. It's only a subset because there is no point in running the GNU tests of the internal representations inside the GNU compiler.
21:01
But things like the torture tests are absolutely fine whether they're on LLVM or GC. They're compiler agnostic. The GNU tools just uses the GNU regression tests. Something that we're very hot on is exhaustive testing. It's not just that, oh, I tried one thing and it seemed to work. It's a let's make sure we've not missed things.
21:22
So starting at the assembler, we have both positive and negative testing. By positive testing, we mean testing the compiler does what you want. By negative test, I mean testing it doesn't do things when it shouldn't. So for example, if we're looking at an instruction
21:41
that takes a six bit signed constant, we will test it with values of minus 33, too small for a negative number, minus 32, the biggest negative six bit number, zero, because you should always test zero because it's a special case, probably minus seven and plus five, and then we'll test 31 and 32, which is too big.
22:01
And we will check those bounds. And actually we added those tests for zc star and found a whole load of bugs in the zc star spec as a consequence. So we do that sort of thing. And we also test things like we test the extensions. I've got the ELW instruction. I test that the ELW instruction is handled by the assembler
22:22
when I specify XELW, okay? I also test that it doesn't get recognized when I don't specify XELW. So that's really important. And one thing I would observe is, and I've seen this for a long time, is RISC-V is incredibly weak on its assembly level testing. There are about 10 times as many tests for ARM and x86 as there are for RISC-V.
22:44
So, you know, it's important to do that. And so we do core five specific, we're a vendor, core five specific GNU-LD testing, because we're adding some regression, we're adding some relocations. Do they work? At the moment, we've got compilation only tests
23:02
of built-ins using scan for assembler instructions. But when we've got those models running, the QEMU and the Verilator model, we'll be adding execution tests. So not only do I generate the right assembly instruction, but it does what I expect. Not only do I generate the built-in, but it does what I expect. So we'll be adding those in as well.
23:24
And all that testing ties into the difference of this is a commercial grade chip, commercial grade core, sorry, and its associated tool chains, okay? So resourcing, resourcing is an issue because software, these days on a chip, you'll spend twice as much on the software
23:41
as you do on the hardware. But Open Hardware Group is inherently mostly hardware company members, okay? We've got plenty of software members, but we're still in a minority. So it is a challenge to get enough resourcing. As part of my contribution, Ember Cosm makes a lot of contribution, that's part of our membership.
24:01
The PLCT lab in China, they make a big contribution. So that's coming there. And we actually double up, we use them very much as part of our graduate training program as well. So part of the graduate allows us to train a new generation of compiler engineers. But we're also seeing companies like Silicon Labs and Dolphin Design call out to them
24:20
because they help to fund those software companies to do the work. So thank you to both of those. And we do need more of that to come on and I expect it will come along, okay? Secondly is we are not going to maintain out of tree forks of GCC and LLVM. It's a thankless task, it takes up a lot of time. The goal is to get upstream as vendor extensions.
24:42
This is not a new thing. This has been part of GCC since before and part of LLVM, okay? And when you have that triple that says what's your target is, that thing that in your standard compiler says RISC-532 unknown-l-gcc or whatever, that unknown is the vendor field. And we should be using that.
25:01
So if you get these tool change, you'll find they build as RISC-532-core-fee, the vendor,-l-gcc, okay? And that's absolutely standard. It's been around forever. You can see in the GCC build, for example, there are variants of Spark and RISC-5 for different manufacturers, for people who make radiation hardened versions
25:23
for space and so forth, okay? That all works fine. RISC-5 is designed for this. It's extensible. That's the whole point. There is a missing piece of the jigsaw, which is in RV32 in the ABI specification,
25:41
you have relocations, okay? There are 256 possible relocation values you can have. The top 64 of those are reserved for vendors, okay? That's enough probably for any one vendor, but it's not enough for all vendors, and it requires a centralized way of controlling. So we know how to solve this problem
26:01
is that every time you need a relocation to tell you this bit of assembler, when you link it needs adjusting the memory offset, you put down two relocations. One is to say which vendor you are, and that's just a new relocation with 32 bits, so we can have 4 billion vendors, okay? And then the second one is say
26:22
which of those 64 relocations, but it means the vendor relocations, there's a full set for every vendor. So we know the concept. One of my other team, Pietra Ferrara, who's sitting somewhere in the audience, is doing the proof of concept to demonstrate that works. Turns out the GNU linker is rather running at its limits
26:44
with the complexity of RISC-V, so it's not a completely trivial task, but we need that before we can fully upstream all this. The rest of it is all ready to go, and it's all done to upstream standards. There's another thing we found is, you notice I showed you there's two versions of CV32E40P, and they've got
27:03
different instruction encodings, okay? We thought it'd be good to actually have, be able to support both instruction encodings, and if you specify an architecture, you're allowed to specify my RV32IMAC underscore X ELW,
27:23
and you're then allowed to say 1P2, to say I want version 1.2, okay? That's all part of the standard where you name an architecture, but it turns out it's not supported in the assembler, the GNU assembler, and furthermore, the GNU assembler is not written in such a way that it's ever going to be easy to support,
27:42
and we gave up on that, and in fact, we're only going to support the latest version, and that probably ties into the way that RISC-V International's going, okay? So those, if you like, are the key issues we're addressing. On the upstreaming, we're almost certainly going to upstream the ISA extensions that don't need vendor-specific relocations, and we'll put the others up
28:01
once the vendor-specific relocations are ratified by the PSA ABI group, okay? So, there. Get involved, the projects are all on GitHub, the Open Hardware Group has its own repository, and if you don't like building from source,
28:20
you can go to the Embercosm website, you can download pre-built tool chains for GCC and LLVM, for Core 5, for every operating system under the sun, all flavors of Linux, Mac, Windows, whatever. So, get involved. Each of these projects has a project lead. Charlie Keeney leads the LLVM project.
28:43
Chun-Yu Liao from PLCT, you remember I said how you have different plan approved for the different variants? She's in charge of the specific project for CV32E40Pv2. Nandhi Jamnadas, who you heard from just now, leads the GNU tools project, and is also actually responsible for the CV32E40Pv2.
29:02
Weiwei Li from PLCT runs the QEM project, and I'm responsible for the Verilator modeling, because I'm a Verilator guy, okay? And part of this is about bringing on a new generation, that we actually help a new generation on and train. So, there is a half hour call, I'm sorry about the time if you live in America,
29:21
because most of the people involved are either in China or in Europe, so they're on Friday mornings, there's a half hour call on LLVM run by Charlie, and there's a half hour call on GNU run by Nandhi. And the idea is that we'll review people collectively, we'll review their pull requests, and it's as much a training and learning thing as anything. So, if you want to get into this stuff,
29:41
it's actually quite a good way to get a bit of free training. And that's it. So, that's me, that's Ember Cosm, that's the open hardware group. Thank you very much. So, we've got a few minutes for questions. I'm happy to take any questions.
30:00
Yes. Yeah, so, I think we've always used the flow to work, but sometimes it gives us some trouble, because, for example, I'm doing compiler development right now, and then last week I discovered
30:21
that there was a bug in GDB, and nobody is working on GDB anymore for this specific version that we picked out. So, I was just wondering, do you maybe have like a timeframe for these upstreaming of these extensions? And can we, like, if tomorrow we do a tape out, or should I tell my colleagues to do an open hardware core,
30:41
or should I tell them to do the stable or the pulp cores in general? Okay, so the question for the recording, the question was about, if you're working on the ETH pulp cores, which are still there as fantastic research cores, should you use the old pulp compiler, or should you use the core five compiler?
31:00
So, I think there's not a black and white answer on that. The pulp compiler is a fork of GCC from 2017. So, it's quite a long way out, and that means it hasn't got the latest RISC-V stuff in there. Well, we started on the GCC for this. We actually looked at whether we could roll that forward, and it wasn't a sensible starting point. We started from scratch from the latest GCC.
31:23
So, in terms of which core you use, I believe ETH Zurich is slowly moving over to more using the core five, unless you're particularly, because you might, you may as well use these hardened cores. In that case, the obvious thing is to use the core five tool chains, and though they're not yet upstream,
31:41
they're all in the public, and there are pre-compiled ones you can pull up. There is a problem if you're using the old pulp cores, because remember I talked about that version one and version two. The old pulp things are so old, they predate sort of finalization of the RISC-V encoding space, and actually the instruction encodings trample
32:01
on future encoding spaces for RISC-V. So the version two fixes all that, and all the version two instruction encodings are actually now RISC-V compliant. They sit in the custom 0123 blocks. What that means is you can't use this compiler, because we haven't got the version one stuff,
32:20
because the versioning issue I talked about, to compile for the old pulp encodings. So that might be a factor you have to bear in mind there. But the old compiler, I've looked at the old compiler, and it comes down to it's a research compiler. It wasn't designed to be tested, it's designed to prove concepts. And I think I've always very shown, that's the job of universities,
32:42
not to do the exhaustive testing we do, it's a different purpose, so it's a different type of compiler. But it does mean that occasionally you get weird behavior. Yeah, so I haven't really answered the question, but I've given you the decision points to look at. I'd love you to use, by the way, I'd love you to use Core 5, because then you'd be tempted to join in and help here.
33:01
Any more questions? Yes, right at the back. Yeah, absolutely, yes, I should have said yeah. So we have a lot of projects under there,
33:20
and we bring in that roadmap I showed. If you look closely you'll see the dates are all wrong, because some of these have moved out, and we've got a load of problems like the Tristan project that we heard of earlier, which are under the open hardware group. And those of you who use David and Sarah Harris's textbook for design, okay, the WALI processor is being re-implemented
33:42
as a RISC-V processor, and that is being done under open hardware group. So your next generation of textbook will have an open hardware group WALI processor in it. So yeah, there's more than just those cores I said there, but yeah, it's those. And if you are working on a core, and you think you might want to put it in this framework,
34:02
come and talk to one of us. You can talk direct to Rick O'Connor. If you don't know him, come to me, and I will introduce you, okay? Yes. I only have a stupid question. So I work mostly on applications actually, and in our development we usually, we're starting to converge, like developers and testers are sort of converging into one team.
34:22
Like, now you were saying that you actually have to split where some people do like the cores, and others do the verification. Would that also be possible to converge at some point? So this is, so the question is, why do we have, I sub paraphrase as, why do we have separate core task group and verification task group? They do work very closely together.
34:42
This is specifically about hardware verification. It's not about software verification. Software, the argument is completely different, and for the software, the verification and development are closely integrated. I think because hardware verification is so formally structured, there is actually a case to be made for keeping them separate,
35:01
and having the design team and the verification teams distinct. So it sort of makes sense. I'm really a software guy. I'm not an expert on hardware, but it does sort of make sense. But the two teams work very closely together, but it allows one team to focus on the UVM-based test and verification flow, and another to work on the actual
35:20
implementation of the chips. Any more questions? Okay, thank you all very much. That brings the RISC-V dev room to an end, and I hope you enjoyed it. Thank you. Thank you.