I've been responsible for fetching everywhere with five instruction that you'll find
in there and for validating against outside sources.
So today I'll talk you about challenges with brief first ecosystem specification, things
that I've encountered, then I'm going to delve into the unified database and I'll do a little
call for help.
So background and bio-ismeters will go to, it's going to be the first topic and then I'll
go into challenges that consumers and producers face.
So currently the risk-five ecosystem relies on multiple repositories, there's somewhat disconnected
and the ways for repositories that you'll find describing the ISA will be the ISA manual
that describes the whole ISA, but still there are other repositories like the assembly manual
which describes some pseudo-instructions, risk-five upcodes which has database of all instructions
or almost all of them and still risk-five which is a detailed formal specification of how
the risk-five equals of the risk-five ISA.
But you still do have a lot more repositories around the risk-five ecosystem, particularly
non-ISA that's the case for some peripherals like the advanced input architecture, a clean
bleak and the ILM and you, you'll find even more if you look for this is when no means
all of them.
So technical challenges that we find in this, I'll mostly go over the risk-five ISA manual,
the assembly manual, up-risk-five upcodes and the self-specification.
So the ISA manuals have somewhat of a challenge that is they're not machine-readable
and therefore they're not very fireable, at least not machine-verifiable.
And they also don't come in a version schema.
Well, the ISA schema, all the extensions have schemas, but their source of the repository
is not really schema-based.
Moreover, you'll find the assembly manual, the assembly manual also is not machine-readable
or very fireable in the same sense, it also does not come in a version schema.
And it's not a clear and concise index, also it may not be its purpose, but you cannot
find all the sort of instructions under the risk-five ecosystem there.
Moreover, risk-five upcodes is also definitely not version, there's no version you can
find in there.
And again, it's not a fully descriptive database of all the instructions risk-five
heads.
So I'll go more on this later.
And cell risk-five, well cell risk-five is not so-local, this isn't really a challenge,
cell is and it might be a so-local, it's a formal specification, but then when you try
to parse it and when you try to read it, you'll find yourself in a bit of a field challenges.
Now, challenges that consumers face, consumers and by consumers, I mean all of us
that use the risk-five ecosystem.
Well, since the information is not cross-referenced, it might be tricky.
So if the ISO manual describes an instruction as it happens on the left example, you can
see that there is in codeings, in this case, and there is a text description, this is a full
paragraph that describes, I believe, 18 instructions, all the registered operations.
But there are even cases as the FCVT model, which is just a modular convert to integer,
where you can't even find the encoding for it in the manual.
And although it exists in risk-five occult, there is no clear reference to it, so you'll
basically have to dig and find it out.
Now, more challenges.
There are some inconsistencies throughout the different documents, and what do I mean by
it is?
Some of these documents are maintained randomly, they're not ratified, and they're not verified
by the big groups, but by the big amount of groups that ratifies main manuals.
So in this case, you'll see that there is a destable, which is in the ISO manual, which
is quite nice.
You can understand that they're mapping some pseudo-instructions to their instructions,
and it makes perfect sense, although the assembly manual is the one that has most
pseudo-instructions.
So why would this be in the ISO manual and not in the assembly manual, because it was not
at the time I took this screenshot.
No, it is, but still the point remains, because this is the flow I found.
I believe there are many more.
Moreover, this is not refined in risk-five occult, at all, there are big amount of
pseudo-instructions who are not there, and this is one of those cases, because this isn't
even supported.
If you look at it, this is kind of a normal pseudo-instruction, you can see that the
register's are swapped to make it from greater than to make it from less than to greater
than.
It's pretty standard, but risk-five occult, as I'll show, cannot handle this, and why
is that?
Well, risk-five occult uses a really simplistic representation for instructions, and the
representation goes as this, and as you see, the only thing you would, in theory, have to
do would be to swap the arguments, and you'll have your definition.
Well, say enough, with five occult's, backhand cannot handle this, and it cannot know, and
it does not know in what order the register's coming, so yeah, there is no way this is
going to be in there, unless it's patched.
Now, fixed values are also not supported, this is also quite common in pseudo-instructions,
whenever you have to do an equal assignment, just in this case, you do, risk-five
occult's also cannot parse that error.
Now, usability challenges, let's continue with these.
Developers have a lot of different places to searching, and I just showed you a couple
repos, there are a lot of them, and sometimes it gets tricky for you, and well, I myself
find myself in, find me in this situation quite a lot, I have a lot of source of truth
as to go through, and yeah, that's how my search for information usually looks like.
Now, for producers, for IP vendors, for anyone that is trying to do a risk-five CPU, this
is also a problem, because you will want to document what you're doing.
And well, if the main source is written in a nice kid-up, that's the technology that
it's used for it, you can see that it is mostly text, and it will be like this for
the whole menu.
So, first of all, you won't be able to verify it at all, and then how will you create
your downstream documentation?
Well, you'll find yourself in a case where you'll need to copy paste or rewrite the
spec, and this is a lot error-prone, because whilst the ISO manual is read by, well, probably
everyone here has already looked into it, and I believe thousands or tens of thousands
of people have already read it, to catch errors, ERCPU will probably not be read by 10,000
people.
So, how will you deal with small flaws that may arise?
Well, it's not really that easy.
Again, there is another problem, that is, risk-five is really extensive, there are a lot
of different extensions, you can implement, that's one of the great parts of risk-five,
but you'll find yourself with designs like this, which is really nice in some part, but
if you're trying to do documentation, and even if you're taking consideration that from
these extensions, you'll need to look for the specific version that you want to implement
in your CPU, nowadays most of them are 1.0, 2.0, but we can imagine that in the next few
years, we'll get 3, 4, 5, and you'll basically need to do a lot of work.
So documentation ends up being a really complex task, that's something we don't want
to happen, and it will be hard to keep up with upstream, it will be expensive, and it will
also be time consuming.
Additionally, if you're an IP vendor that's trying to do things fast, well, one thing
that you don't want is documentation to be your bigger roll block, right?
Yeah, and fortunately, there is no existing solution for you to go around these yet.
So, what happens with all these repositories is that I was actually assigned, that's an
option to try to find a way to go around all of them and to figure it out, or how we
can connect it, connect them, but what happened was I, I could not, I have really a mental
question that I was thinking about, like, how am I going to work with this?
Well, that's why I bring you the risk-5 unified database.
So in this section, I'll try to go over a few things, I'll go about what is the UDB, what
how the UDB relates to current challenges, and some use cases that are now and will be in
the future, I believe, useful, where the UDB will be useful for and some future work.
Now, this is kind of abstract, it's really high level representation of UDB, but on the left side,
you'll see that this is a golden source of truth, this is where your spec goes in, where it is already
and additionally, you can add your custom overlay, if by any change, when you're implementing
a risk-5 core, you want to change something on the main spec, you can overlay it over there.
Then, this gets resolved, you get the results spec, you get to pass your own config, because if you're
implementing a risk-5 core, everyone will have a different design, different design of which
that you want to accommodate, and then you'll get your Ruby database view from which you can generate
multiple outputs. So documents are already being generated, there is a really simple ISS also being
generated in instruction set simulator, really, really basic one, just to show the purpose of it,
and then you'll have some raw data, which you can do whatever you want with.
So, basically, before going in depth on the output, I'll just briefly explain what is there
on the source of truth. So, you have your basic CPU instructions, which you may be aware of,
so, arithmetic, logical operations, everything we are already used to. Then we have CSIres,
this is the risk-5 control and state registers, there's a special purpose management,
registers that are used for your CPU to know its state, and many more other things.
Then you have Profile, so, risk-5 defines some subsets of the ISO that allow for
compatibility across different implementations. So, if you follow a certain profile,
you'll know that your software will be fine. And then you have architectural parameters,
this is really for vendors and people implementing that want to show their design choices,
there you have 32 or 64B, if you want to implement each one of them, but really there are many,
many more. I'll go now a bit more in depth about the first three ones, and I'm starting with
instructions. So, instructions where described by name, long name, description,
defined by basically the extensions that define that instruction, and then you have the
in-golvings, matching variables, this will be your registers, your access mode that your
instruction is accessible from, and then you'll have formal specification. In this case, we have
sale, the most known risk-5 formal specification, and there is IDL, IDL was developed by
welcome, it's much easier to read than sale for normal users, but yeah, both are present in the output,
so you can choose. This is what it looks like for a basic integer of instruction, you have your
ad, your integer of brief description of in this case adding to registers, you get the instruction
that defines it, the ad is in the device ISO, so it's the i extension, you have the assembly
code for it, you have the encoding, what's hard-coded, and what are the variables, these guys,
you have source 1, source 2, and your destination register, you have where you can access it from,
from a mode standpoint, whether you're in supervisor, in user mode, virtualized supervisor,
or virtual user mode, and then you'll have the independent timing, this is for some cryptographic
extensions where you want your instruction to always take the same time, you can define it,
and then you have the IDL, that's the operation, that's a formal description, and that's sale,
these are both compatible, so that you can know exactly what each instruction does.
Okay, going back to your size now, CSRs have pretty much the same schema, but for their own purpose,
so you have your name, long name, the address, that your CSR is in, you can see that this
case, it's in thread, it's at 0x02, then you'll have your description, the privilege mode,
it can it is accessible from the length, the extension that defines it, some fields, in this case,
it's a counter, so it's pretty simple, but this gets way, way more complex, and here I've
definitely shortened this software with, this is IDL, and I've shortened it because it was really,
really way bigger for this presentation. Now profiles, we also described profiles so that you can
easily generate your outputs based on the profile we want to follow, so if we take a look at the profiles,
you'll be able to see that for these profile, it is RVI20U32, you'll have the base where you can,
you can be the base that it follows, in this case obviously, I mean 32, it is 32 bit, before it,
you have the mold you can access it from, it's just a privilege in this case, and then you have
introduction, a brief introduction for your profile, this will be useful for documentation purposes,
if you're trying to build it, and then you'll have the extensions that your profile profile defines.
In this case, it's shortened because again, it will be way too big. Moreover, you can even define
some small text as a recommendation and you'll see how this looks in the outputs. So now,
passing from the golden source of truth that we were talking about, we're going to go into the
framework and how this works, I won't go much in depth here, but basically, as the framework,
as I explained in the first design slide, the framework will resolve all your source,
and then it will merge it, and while it's resolved, and then you'll basically apply a
config to it, and from this config, you'll choose either your profile or your specific profile that you want to.
So here you can see a couple of the options you can use when you are using the UDB,
validation options, these are some tests, there's the smoke test, there's smoke test, cross-validates
your information, your instruction information against either GCC, L-L-V-M, or RIS-5
obcodes, this is quite handy to know you're not generating a faulty output, and then you can see
you can generate really wide source of outputs, and you can even stop the UDB at a certain process
of the framework, so if you want to take its data as input, you can choose whatever format
you want or prefer, and on the output, you'll be able to generate documents, you'll be able to
generate an instruction set simulator, and some raw data, but what does this really looks like?
So on the manuals, you'll be able to generate the ISO manual, this is pretty much a mirror of what
the ISO manual has in, it will have some extra indexes that you also can generate, but all these
documents will have them, which can quite handy. Certification documents are something that is already
being used, if you want to certify proper, if you want to have a certification required document,
I'll show this on the next step of this presentation, these are really useful coming from the UDB.
Profile manuals, as I explained, are the only the ISO manual, but trimmed down for a subset,
and extension manuals, you can generate the manual for only one extension, if you may want just to study
for some sort of purpose. Then you have your detailed indexes, this specify instructions,
extensions, and CSRs, this is quite handy, and doesn't really exist anywhere else in the risk
of a ecosystem, so whenever you're trying to fetch information for an instruction, you can just
come here, do a quick search, and you'll find it's way easier. Then, with five upgots output,
with five upgots has several tools that rely on it, the most known one is spike,
the simulator, and you can generate this same output set of the UDB already, and then you have
an instructions that simulator that I'll demo in the next slide. For this demonstration, I'll just
go back to my computer view, if, yeah, and I'll go over the manuals. If you come here, you'll see
that the main, this is basically the mirror for the ISO manual, this comes in an HTML version,
you can see you have and privileged and privileged, nothing really to see here, it's just falls
really the structure of the ISO manual that is already followed. Then you go into the indexes,
and here it comes the kind of the delta of the unified database, if you search for an instruction,
you'll find it's detail, if you want to look for it's encoding, if you may want to look for
where, which mold you can access it from, it's decode variables, and then you'll even have some
ideal that you can read from or some soil. And yeah, this exists for the thousand-place instructions
in risk five. Although some of them do not have fully completed the descriptions, so we'll see that
here we have no synopsis available for this specific instruction. Well, this is a working progress
to fill them in. Then you'll have the same for your CSIres, but in their format as I previously
explained, so you'll have basically this is a table to show the different mold you can access,
and how it behaves, how it should behave. You'll have it's attributes, in this case, again,
it's a counter, so only the counter in the format, and then you'll have the field summary,
fields, and you're software with that you can test the CSIres. Moreover, you'll have a list of
extensions, and these extensions are all the risk five ratified extensions, you may just
quickly go and search through them to understand. At the bottom, there is a really nice index,
you basically can see what instructions each extension adds, and this is quite handy.
Well, then you have your list of parameters. I'll skip this because this is a bit more specific
to your needs, if you want to go looking to the UDB afterwards, I think it's pretty easy,
understandable also. So now, how is the beauty of the UDB? It's really easy to generate
specific manuals. This one is the base integer, IS, IS. So it's basically Rv32 or 64, I, and here
you'll only see, are I extension related content. You'll have a brief description, and then you'll
be able to see all the instructions and more and all the rest of the information that you'll need
for the I extension. Again, if you're trying to build a profile, you can also build a profile release.
As you can see, this has way different sizes depending on which profile you have. Rv32 has
425 pages, but well, it gets way bigger on newer profiles that define a lot more things.
And truly the only thing you'll need to build one output, or the other, is to specify a different
config, and your be all good to go. Again, there are a couple more outputs that are interesting.
As I mentioned, this is a certification requirement document that is generated out of the UDB.
Rv5 has a working group that is the certification and steering committee, and they create
certifications, so that Rv5 implementations need to follow, so that they can get Rv5 international approval.
They are to approve that they are indeed fully compliant with Rv5.
Well, here you'll have it for the MC132. This is one of the configs they do. They also are doing it for
the MC364, and they are describing all of these inside the unified database and generating the
outputs out of it directly. Then, synopsis is also using the unified database to create their
manuals. This is a snippet of an index of instructions. This will be a different view from what you
have seen before. And Qualcomm is also defining a new extension, a Qualcomm microC extension, on the UDB.
It's fully open source, but you'll only be able to look at it at least for now from the UDB.
This now goes on version 0.7, I believe. Moreover, the ISS that I talked to you about,
it's really, really simple, and just to demonstrate the potentials of the UDB and how you can use it for
a source of truth. So, you can see here that you can generate and run some code. That you can run
some code. This is a pre-built binary from Eballiv with five tests. Basically, the intent and
fee of this code is to ensure that the AI instruction is executing correctly. As you'll see,
you have simply a basic problem counter. The goal thing you can find at that memory location
and what instruction it represents. At the end, you'll see a pass message to tell you that your
test is passed, because this is what the binary does at the first hand. Now, back to the presentation.
So, back to the presentation. We'll see just when more output, this is the RIS5 output output.
So, what I'll show here is the Neville end of RIS5 outputs. The RIS5 output generates a JSON from which
it arrives all its outputs, and its JSON looks like this, but this one is generated from the UDB as a source of
information. It can also generate all the other outputs for different use cases. As I said,
in coding.h is used by spike instructions. Go is used by the goal language, and well,
there are many other use cases for these outputs. Now, how does the UDB relates to the current
challenges that I started this talk with? So, it can see instances through all different documents
that sometimes appeared. Well, all these documents that you just saw are built from the same source.
So, you won't ever find an inconsistency, because they indeed are the same information represented
in different ways. Information not being referenced, that also will not happen in the UDB, the
built system, or else stagging, and you'll easily find your information inside those manuals.
Then, creating CPU stock implementation requires copy-pasting DIS. Well, not anymore. If you use the
UDB, you'll be able to just create a config of your CPU and from that, you'll have the documentation
that you'll need. Again, the moreover, current information not being machine readable, as I
showed you, UDB comes with a nice YAML format, and that is totally machine readable, and
parts of all in many ways, you can try to do so. And no reliable solution to create a
alert documentation. Well, I think I've clearly provided the answer for this as the UDB creates
this alert documentation. Now, what does the UDB not solve? Because, well, the UDB is not here to solve
every problems, although we'd like to. The UDB is not meant to describe full SOC, so not as the
peripherals that you may see will not be available in the UDB, only CPU information. And current
roadblocks, copy-pasting is a chicane and egg problem, so the UDB is copy-pasted, and information
is not verified by a lot of people. And information is not verified by a lot of people due to the
UDB team not being huge at this time. Well, I quickly rushed through this slide, because I thought
I was out of time, but I'll go back to it. There is still pros, and that pros will not be verified,
although all the rest of the information can be well, you can't really verify text in any way.
And well, there are, if there is information missing, in some of the new outputs, the UDB
generates, that's because we can't really fetch it from anywhere. I showed you on the index,
there will some blank fields. Now, use cases. So, I've mentioned a few of these use cases,
like the certifications to become a TSIG, is using it to create the CRDs. The welcome has created
an extension, that is only described and available through the UDB as of now.
So, nobts is using it to generate arc-5 processors documentation. It can substitute risk-5
obcodes if at some point that is required. And it can provide content for all the new tools or
documents that you may find with your creativity to use it for. Future work. Well,
future steps are vendors and consumers relying on the UDB to create their documentation.
Even if you have some issues, some CPUs that you don't have really good documentation for,
you can do the test, you can go into the UDB and generate your own documentation.
New tools can be live on the UDB and you can specify your eyes and peripherals there,
maybe, in the future. So, the UDB and goal. The UDB and goal is to become the main source of
information for the risk-5. We hope that happens, but currently we're working to do it.
Call for help. So, before finishing this presentation, the UDB is already being developed
collaboratively. There are several engineers from a whole different companies like
Akiana, Qualcomm, Reval, SIF-5, Synopsis, and Ventania, but we need more help. We need a community
to help us. If you're interested in this, please join us. Check our GitHub repository,
check all the issues and discussions that are currently going on. You can also join our weekly meetings.
Although there is no formal SIG yet, it might happen soon. So, yeah, for now, contact me and I'll
invite you to this weekly meetings. Finally, if you're really really interested in Synopsis,
hiring someone to work on the UDB. So, yeah, contact me if interested or check the QR code.
Thank you.