WEBVTT 00:00.000 --> 00:09.080 I've been responsible for fetching everywhere with five instruction that you'll find 00:09.080 --> 00:13.480 in there and for validating against outside sources. 00:13.480 --> 00:19.480 So today I'll talk you about challenges with brief first ecosystem specification, things 00:19.480 --> 00:23.960 that I've encountered, then I'm going to delve into the unified database and I'll do a little 00:23.960 --> 00:27.560 call for help. 00:27.560 --> 00:34.000 So background and bio-ismeters will go to, it's going to be the first topic and then I'll 00:34.000 --> 00:39.920 go into challenges that consumers and producers face. 00:39.920 --> 00:49.880 So currently the risk-five ecosystem relies on multiple repositories, there's somewhat disconnected 00:49.880 --> 00:56.960 and the ways for repositories that you'll find describing the ISA will be the ISA manual 00:56.960 --> 01:01.760 that describes the whole ISA, but still there are other repositories like the assembly manual 01:01.760 --> 01:07.640 which describes some pseudo-instructions, risk-five upcodes which has database of all instructions 01:07.640 --> 01:13.560 or almost all of them and still risk-five which is a detailed formal specification of how 01:13.560 --> 01:16.960 the risk-five equals of the risk-five ISA. 01:16.960 --> 01:22.440 But you still do have a lot more repositories around the risk-five ecosystem, particularly 01:22.440 --> 01:28.680 non-ISA that's the case for some peripherals like the advanced input architecture, a clean 01:28.680 --> 01:34.520 bleak and the ILM and you, you'll find even more if you look for this is when no means 01:34.520 --> 01:36.560 all of them. 01:36.560 --> 01:43.480 So technical challenges that we find in this, I'll mostly go over the risk-five ISA manual, 01:43.520 --> 01:48.960 the assembly manual, up-risk-five upcodes and the self-specification. 01:48.960 --> 01:55.960 So the ISA manuals have somewhat of a challenge that is they're not machine-readable 01:55.960 --> 02:00.440 and therefore they're not very fireable, at least not machine-verifiable. 02:00.440 --> 02:02.520 And they also don't come in a version schema. 02:02.520 --> 02:09.800 Well, the ISA schema, all the extensions have schemas, but their source of the repository 02:09.800 --> 02:12.440 is not really schema-based. 02:12.440 --> 02:17.000 Moreover, you'll find the assembly manual, the assembly manual also is not machine-readable 02:17.000 --> 02:21.680 or very fireable in the same sense, it also does not come in a version schema. 02:21.680 --> 02:26.480 And it's not a clear and concise index, also it may not be its purpose, but you cannot 02:26.480 --> 02:30.600 find all the sort of instructions under the risk-five ecosystem there. 02:30.600 --> 02:35.080 Moreover, risk-five upcodes is also definitely not version, there's no version you can 02:35.080 --> 02:36.480 find in there. 02:36.480 --> 02:40.580 And again, it's not a fully descriptive database of all the instructions risk-five 02:40.580 --> 02:41.580 heads. 02:41.580 --> 02:45.500 So I'll go more on this later. 02:45.500 --> 02:49.060 And cell risk-five, well cell risk-five is not so-local, this isn't really a challenge, 02:49.060 --> 02:54.060 cell is and it might be a so-local, it's a formal specification, but then when you try 02:54.060 --> 02:59.300 to parse it and when you try to read it, you'll find yourself in a bit of a field challenges. 02:59.300 --> 03:04.820 Now, challenges that consumers face, consumers and by consumers, I mean all of us 03:04.820 --> 03:07.100 that use the risk-five ecosystem. 03:07.100 --> 03:12.140 Well, since the information is not cross-referenced, it might be tricky. 03:12.140 --> 03:17.540 So if the ISO manual describes an instruction as it happens on the left example, you can 03:17.540 --> 03:23.340 see that there is in codeings, in this case, and there is a text description, this is a full 03:23.340 --> 03:29.980 paragraph that describes, I believe, 18 instructions, all the registered operations. 03:29.980 --> 03:36.300 But there are even cases as the FCVT model, which is just a modular convert to integer, 03:36.300 --> 03:40.220 where you can't even find the encoding for it in the manual. 03:40.220 --> 03:44.780 And although it exists in risk-five occult, there is no clear reference to it, so you'll 03:44.780 --> 03:49.340 basically have to dig and find it out. 03:49.340 --> 03:50.860 Now, more challenges. 03:50.860 --> 03:54.740 There are some inconsistencies throughout the different documents, and what do I mean by 03:54.740 --> 03:56.460 it is? 03:56.460 --> 04:00.540 Some of these documents are maintained randomly, they're not ratified, and they're not verified 04:00.620 --> 04:06.820 by the big groups, but by the big amount of groups that ratifies main manuals. 04:06.820 --> 04:12.140 So in this case, you'll see that there is a destable, which is in the ISO manual, which 04:12.140 --> 04:13.140 is quite nice. 04:13.140 --> 04:17.820 You can understand that they're mapping some pseudo-instructions to their instructions, 04:17.820 --> 04:23.680 and it makes perfect sense, although the assembly manual is the one that has most 04:23.680 --> 04:24.680 pseudo-instructions. 04:24.680 --> 04:29.220 So why would this be in the ISO manual and not in the assembly manual, because it was not 04:29.300 --> 04:30.940 at the time I took this screenshot. 04:30.940 --> 04:35.860 No, it is, but still the point remains, because this is the flow I found. 04:35.860 --> 04:38.700 I believe there are many more. 04:38.700 --> 04:44.340 Moreover, this is not refined in risk-five occult, at all, there are big amount of 04:44.340 --> 04:48.700 pseudo-instructions who are not there, and this is one of those cases, because this isn't 04:48.700 --> 04:50.100 even supported. 04:50.100 --> 04:53.860 If you look at it, this is kind of a normal pseudo-instruction, you can see that the 04:53.860 --> 04:59.820 register's are swapped to make it from greater than to make it from less than to greater 04:59.820 --> 05:00.820 than. 05:00.820 --> 05:05.940 It's pretty standard, but risk-five occult, as I'll show, cannot handle this, and why 05:05.940 --> 05:06.940 is that? 05:06.940 --> 05:12.700 Well, risk-five occult uses a really simplistic representation for instructions, and the 05:12.700 --> 05:20.020 representation goes as this, and as you see, the only thing you would, in theory, have to 05:20.020 --> 05:25.100 do would be to swap the arguments, and you'll have your definition. 05:25.100 --> 05:30.940 Well, say enough, with five occult's, backhand cannot handle this, and it cannot know, and 05:30.940 --> 05:36.540 it does not know in what order the register's coming, so yeah, there is no way this is 05:36.540 --> 05:40.260 going to be in there, unless it's patched. 05:40.260 --> 05:45.060 Now, fixed values are also not supported, this is also quite common in pseudo-instructions, 05:45.060 --> 05:50.500 whenever you have to do an equal assignment, just in this case, you do, risk-five 05:50.500 --> 05:53.660 occult's also cannot parse that error. 05:53.660 --> 05:58.380 Now, usability challenges, let's continue with these. 05:58.380 --> 06:02.180 Developers have a lot of different places to searching, and I just showed you a couple 06:02.180 --> 06:08.460 repos, there are a lot of them, and sometimes it gets tricky for you, and well, I myself 06:08.460 --> 06:14.180 find myself in, find me in this situation quite a lot, I have a lot of source of truth 06:14.180 --> 06:21.060 as to go through, and yeah, that's how my search for information usually looks like. 06:21.060 --> 06:27.300 Now, for producers, for IP vendors, for anyone that is trying to do a risk-five CPU, this 06:27.300 --> 06:31.460 is also a problem, because you will want to document what you're doing. 06:31.460 --> 06:36.820 And well, if the main source is written in a nice kid-up, that's the technology that 06:36.820 --> 06:42.540 it's used for it, you can see that it is mostly text, and it will be like this for 06:42.540 --> 06:43.540 the whole menu. 06:43.540 --> 06:49.140 So, first of all, you won't be able to verify it at all, and then how will you create 06:49.140 --> 06:50.780 your downstream documentation? 06:50.780 --> 06:55.700 Well, you'll find yourself in a case where you'll need to copy paste or rewrite the 06:55.700 --> 07:02.380 spec, and this is a lot error-prone, because whilst the ISO manual is read by, well, probably 07:02.380 --> 07:07.620 everyone here has already looked into it, and I believe thousands or tens of thousands 07:07.620 --> 07:13.700 of people have already read it, to catch errors, ERCPU will probably not be read by 10,000 07:13.700 --> 07:14.700 people. 07:14.700 --> 07:18.660 So, how will you deal with small flaws that may arise? 07:18.660 --> 07:21.380 Well, it's not really that easy. 07:21.380 --> 07:26.340 Again, there is another problem, that is, risk-five is really extensive, there are a lot 07:26.340 --> 07:30.940 of different extensions, you can implement, that's one of the great parts of risk-five, 07:30.940 --> 07:36.780 but you'll find yourself with designs like this, which is really nice in some part, but 07:36.780 --> 07:41.060 if you're trying to do documentation, and even if you're taking consideration that from 07:41.060 --> 07:45.580 these extensions, you'll need to look for the specific version that you want to implement 07:45.580 --> 07:52.300 in your CPU, nowadays most of them are 1.0, 2.0, but we can imagine that in the next few 07:52.300 --> 07:59.260 years, we'll get 3, 4, 5, and you'll basically need to do a lot of work. 07:59.260 --> 08:03.740 So documentation ends up being a really complex task, that's something we don't want 08:03.740 --> 08:09.340 to happen, and it will be hard to keep up with upstream, it will be expensive, and it will 08:09.340 --> 08:11.380 also be time consuming. 08:11.380 --> 08:16.220 Additionally, if you're an IP vendor that's trying to do things fast, well, one thing 08:16.220 --> 08:21.500 that you don't want is documentation to be your bigger roll block, right? 08:21.500 --> 08:27.940 Yeah, and fortunately, there is no existing solution for you to go around these yet. 08:27.940 --> 08:32.540 So, what happens with all these repositories is that I was actually assigned, that's an 08:32.540 --> 08:38.020 option to try to find a way to go around all of them and to figure it out, or how we 08:38.020 --> 08:44.220 can connect it, connect them, but what happened was I, I could not, I have really a mental 08:44.220 --> 08:49.740 question that I was thinking about, like, how am I going to work with this? 08:49.740 --> 08:55.180 Well, that's why I bring you the risk-5 unified database. 08:55.180 --> 09:01.580 So in this section, I'll try to go over a few things, I'll go about what is the UDB, what 09:01.660 --> 09:07.660 how the UDB relates to current challenges, and some use cases that are now and will be in 09:07.660 --> 09:14.540 the future, I believe, useful, where the UDB will be useful for and some future work. 09:14.540 --> 09:25.020 Now, this is kind of abstract, it's really high level representation of UDB, but on the left side, 09:25.020 --> 09:30.300 you'll see that this is a golden source of truth, this is where your spec goes in, where it is already 09:31.180 --> 09:36.140 and additionally, you can add your custom overlay, if by any change, when you're implementing 09:36.140 --> 09:41.260 a risk-5 core, you want to change something on the main spec, you can overlay it over there. 09:42.620 --> 09:48.460 Then, this gets resolved, you get the results spec, you get to pass your own config, because if you're 09:48.460 --> 09:53.260 implementing a risk-5 core, everyone will have a different design, different design of which 09:53.260 --> 09:59.660 that you want to accommodate, and then you'll get your Ruby database view from which you can generate 09:59.660 --> 10:06.460 multiple outputs. So documents are already being generated, there is a really simple ISS also being 10:06.460 --> 10:12.140 generated in instruction set simulator, really, really basic one, just to show the purpose of it, 10:12.780 --> 10:17.260 and then you'll have some raw data, which you can do whatever you want with. 10:19.500 --> 10:28.220 So, basically, before going in depth on the output, I'll just briefly explain what is there 10:28.220 --> 10:33.500 on the source of truth. So, you have your basic CPU instructions, which you may be aware of, 10:33.500 --> 10:40.220 so, arithmetic, logical operations, everything we are already used to. Then we have CSIres, 10:40.220 --> 10:45.020 this is the risk-5 control and state registers, there's a special purpose management, 10:45.020 --> 10:50.940 registers that are used for your CPU to know its state, and many more other things. 10:50.940 --> 10:57.500 Then you have Profile, so, risk-5 defines some subsets of the ISO that allow for 10:57.500 --> 11:01.660 compatibility across different implementations. So, if you follow a certain profile, 11:01.660 --> 11:06.220 you'll know that your software will be fine. And then you have architectural parameters, 11:06.220 --> 11:11.180 this is really for vendors and people implementing that want to show their design choices, 11:11.180 --> 11:16.620 there you have 32 or 64B, if you want to implement each one of them, but really there are many, 11:16.620 --> 11:23.260 many more. I'll go now a bit more in depth about the first three ones, and I'm starting with 11:23.260 --> 11:28.460 instructions. So, instructions where described by name, long name, description, 11:28.460 --> 11:33.900 defined by basically the extensions that define that instruction, and then you have the 11:33.900 --> 11:39.020 in-golvings, matching variables, this will be your registers, your access mode that your 11:39.020 --> 11:43.820 instruction is accessible from, and then you'll have formal specification. In this case, we have 11:43.820 --> 11:50.700 sale, the most known risk-5 formal specification, and there is IDL, IDL was developed by 11:50.700 --> 11:58.140 welcome, it's much easier to read than sale for normal users, but yeah, both are present in the output, 11:58.140 --> 12:06.300 so you can choose. This is what it looks like for a basic integer of instruction, you have your 12:06.300 --> 12:13.580 ad, your integer of brief description of in this case adding to registers, you get the instruction 12:13.580 --> 12:18.380 that defines it, the ad is in the device ISO, so it's the i extension, you have the assembly 12:18.380 --> 12:23.820 code for it, you have the encoding, what's hard-coded, and what are the variables, these guys, 12:23.820 --> 12:29.580 you have source 1, source 2, and your destination register, you have where you can access it from, 12:29.580 --> 12:36.860 from a mode standpoint, whether you're in supervisor, in user mode, virtualized supervisor, 12:36.860 --> 12:42.940 or virtual user mode, and then you'll have the independent timing, this is for some cryptographic 12:42.940 --> 12:47.580 extensions where you want your instruction to always take the same time, you can define it, 12:47.660 --> 12:53.260 and then you have the IDL, that's the operation, that's a formal description, and that's sale, 12:53.260 --> 12:58.460 these are both compatible, so that you can know exactly what each instruction does. 12:59.980 --> 13:08.140 Okay, going back to your size now, CSRs have pretty much the same schema, but for their own purpose, 13:08.140 --> 13:13.660 so you have your name, long name, the address, that your CSR is in, you can see that this 13:13.660 --> 13:20.460 case, it's in thread, it's at 0x02, then you'll have your description, the privilege mode, 13:20.460 --> 13:27.900 it can it is accessible from the length, the extension that defines it, some fields, in this case, 13:27.900 --> 13:33.500 it's a counter, so it's pretty simple, but this gets way, way more complex, and here I've 13:33.500 --> 13:40.060 definitely shortened this software with, this is IDL, and I've shortened it because it was really, 13:40.060 --> 13:46.860 really way bigger for this presentation. Now profiles, we also described profiles so that you can 13:46.860 --> 13:53.020 easily generate your outputs based on the profile we want to follow, so if we take a look at the profiles, 13:53.020 --> 14:00.940 you'll be able to see that for these profile, it is RVI20U32, you'll have the base where you can, 14:00.940 --> 14:07.420 you can be the base that it follows, in this case obviously, I mean 32, it is 32 bit, before it, 14:07.420 --> 14:13.740 you have the mold you can access it from, it's just a privilege in this case, and then you have 14:13.740 --> 14:18.460 introduction, a brief introduction for your profile, this will be useful for documentation purposes, 14:18.460 --> 14:25.260 if you're trying to build it, and then you'll have the extensions that your profile profile defines. 14:25.260 --> 14:31.420 In this case, it's shortened because again, it will be way too big. Moreover, you can even define 14:31.420 --> 14:37.980 some small text as a recommendation and you'll see how this looks in the outputs. So now, 14:37.980 --> 14:42.220 passing from the golden source of truth that we were talking about, we're going to go into the 14:42.220 --> 14:48.860 framework and how this works, I won't go much in depth here, but basically, as the framework, 14:48.860 --> 14:54.860 as I explained in the first design slide, the framework will resolve all your source, 14:55.660 --> 15:00.540 and then it will merge it, and while it's resolved, and then you'll basically apply a 15:00.540 --> 15:06.780 config to it, and from this config, you'll choose either your profile or your specific profile that you want to. 15:08.780 --> 15:13.980 So here you can see a couple of the options you can use when you are using the UDB, 15:15.580 --> 15:20.780 validation options, these are some tests, there's the smoke test, there's smoke test, cross-validates 15:20.780 --> 15:26.300 your information, your instruction information against either GCC, L-L-V-M, or RIS-5 15:26.300 --> 15:31.340 obcodes, this is quite handy to know you're not generating a faulty output, and then you can see 15:31.340 --> 15:38.460 you can generate really wide source of outputs, and you can even stop the UDB at a certain process 15:38.460 --> 15:44.860 of the framework, so if you want to take its data as input, you can choose whatever format 15:44.940 --> 15:51.260 you want or prefer, and on the output, you'll be able to generate documents, you'll be able to 15:51.260 --> 15:56.940 generate an instruction set simulator, and some raw data, but what does this really looks like? 15:56.940 --> 16:02.940 So on the manuals, you'll be able to generate the ISO manual, this is pretty much a mirror of what 16:02.940 --> 16:10.140 the ISO manual has in, it will have some extra indexes that you also can generate, but all these 16:10.140 --> 16:15.020 documents will have them, which can quite handy. Certification documents are something that is already 16:15.020 --> 16:21.660 being used, if you want to certify proper, if you want to have a certification required document, 16:21.660 --> 16:27.580 I'll show this on the next step of this presentation, these are really useful coming from the UDB. 16:27.580 --> 16:32.860 Profile manuals, as I explained, are the only the ISO manual, but trimmed down for a subset, 16:33.420 --> 16:39.100 and extension manuals, you can generate the manual for only one extension, if you may want just to study 16:39.580 --> 16:45.340 for some sort of purpose. Then you have your detailed indexes, this specify instructions, 16:45.340 --> 16:50.060 extensions, and CSRs, this is quite handy, and doesn't really exist anywhere else in the risk 16:50.060 --> 16:55.420 of a ecosystem, so whenever you're trying to fetch information for an instruction, you can just 16:55.420 --> 17:01.500 come here, do a quick search, and you'll find it's way easier. Then, with five upgots output, 17:02.540 --> 17:07.340 with five upgots has several tools that rely on it, the most known one is spike, 17:07.980 --> 17:14.060 the simulator, and you can generate this same output set of the UDB already, and then you have 17:14.060 --> 17:20.380 an instructions that simulator that I'll demo in the next slide. For this demonstration, I'll just 17:21.820 --> 17:33.500 go back to my computer view, if, yeah, and I'll go over the manuals. If you come here, you'll see 17:33.500 --> 17:38.940 that the main, this is basically the mirror for the ISO manual, this comes in an HTML version, 17:38.940 --> 17:44.860 you can see you have and privileged and privileged, nothing really to see here, it's just falls 17:44.860 --> 17:51.020 really the structure of the ISO manual that is already followed. Then you go into the indexes, 17:51.020 --> 17:57.820 and here it comes the kind of the delta of the unified database, if you search for an instruction, 17:57.820 --> 18:03.740 you'll find it's detail, if you want to look for it's encoding, if you may want to look for 18:04.540 --> 18:09.900 where, which mold you can access it from, it's decode variables, and then you'll even have some 18:09.900 --> 18:16.700 ideal that you can read from or some soil. And yeah, this exists for the thousand-place instructions 18:16.700 --> 18:25.100 in risk five. Although some of them do not have fully completed the descriptions, so we'll see that 18:25.100 --> 18:31.260 here we have no synopsis available for this specific instruction. Well, this is a working progress 18:31.260 --> 18:36.700 to fill them in. Then you'll have the same for your CSIres, but in their format as I previously 18:36.700 --> 18:41.980 explained, so you'll have basically this is a table to show the different mold you can access, 18:41.980 --> 18:47.260 and how it behaves, how it should behave. You'll have it's attributes, in this case, again, 18:47.260 --> 18:52.380 it's a counter, so only the counter in the format, and then you'll have the field summary, 18:52.380 --> 18:59.340 fields, and you're software with that you can test the CSIres. Moreover, you'll have a list of 18:59.340 --> 19:04.140 extensions, and these extensions are all the risk five ratified extensions, you may just 19:04.860 --> 19:10.780 quickly go and search through them to understand. At the bottom, there is a really nice index, 19:11.420 --> 19:17.660 you basically can see what instructions each extension adds, and this is quite handy. 19:18.620 --> 19:25.260 Well, then you have your list of parameters. I'll skip this because this is a bit more specific 19:25.260 --> 19:30.780 to your needs, if you want to go looking to the UDB afterwards, I think it's pretty easy, 19:30.780 --> 19:38.380 understandable also. So now, how is the beauty of the UDB? It's really easy to generate 19:38.940 --> 19:47.500 specific manuals. This one is the base integer, IS, IS. So it's basically Rv32 or 64, I, and here 19:47.580 --> 19:54.060 you'll only see, are I extension related content. You'll have a brief description, and then you'll 19:54.060 --> 20:00.300 be able to see all the instructions and more and all the rest of the information that you'll need 20:00.300 --> 20:06.380 for the I extension. Again, if you're trying to build a profile, you can also build a profile release. 20:06.380 --> 20:11.900 As you can see, this has way different sizes depending on which profile you have. Rv32 has 20:11.900 --> 20:19.980 425 pages, but well, it gets way bigger on newer profiles that define a lot more things. 20:19.980 --> 20:24.940 And truly the only thing you'll need to build one output, or the other, is to specify a different 20:24.940 --> 20:32.700 config, and your be all good to go. Again, there are a couple more outputs that are interesting. 20:32.700 --> 20:38.300 As I mentioned, this is a certification requirement document that is generated out of the UDB. 20:38.540 --> 20:44.300 Rv5 has a working group that is the certification and steering committee, and they create 20:44.300 --> 20:51.180 certifications, so that Rv5 implementations need to follow, so that they can get Rv5 international approval. 20:51.180 --> 20:55.340 They are to approve that they are indeed fully compliant with Rv5. 20:56.620 --> 21:04.540 Well, here you'll have it for the MC132. This is one of the configs they do. They also are doing it for 21:04.540 --> 21:10.540 the MC364, and they are describing all of these inside the unified database and generating the 21:10.540 --> 21:17.980 outputs out of it directly. Then, synopsis is also using the unified database to create their 21:17.980 --> 21:23.020 manuals. This is a snippet of an index of instructions. This will be a different view from what you 21:23.020 --> 21:30.940 have seen before. And Qualcomm is also defining a new extension, a Qualcomm microC extension, on the UDB. 21:30.940 --> 21:36.380 It's fully open source, but you'll only be able to look at it at least for now from the UDB. 21:37.100 --> 21:45.260 This now goes on version 0.7, I believe. Moreover, the ISS that I talked to you about, 21:46.060 --> 21:51.660 it's really, really simple, and just to demonstrate the potentials of the UDB and how you can use it for 21:51.660 --> 22:02.620 a source of truth. So, you can see here that you can generate and run some code. That you can run 22:02.620 --> 22:09.340 some code. This is a pre-built binary from Eballiv with five tests. Basically, the intent and 22:09.340 --> 22:17.100 fee of this code is to ensure that the AI instruction is executing correctly. As you'll see, 22:18.060 --> 22:25.020 you have simply a basic problem counter. The goal thing you can find at that memory location 22:25.020 --> 22:32.060 and what instruction it represents. At the end, you'll see a pass message to tell you that your 22:32.060 --> 22:39.740 test is passed, because this is what the binary does at the first hand. Now, back to the presentation. 22:40.700 --> 22:48.620 So, back to the presentation. We'll see just when more output, this is the RIS5 output output. 22:48.620 --> 22:55.020 So, what I'll show here is the Neville end of RIS5 outputs. The RIS5 output generates a JSON from which 22:55.020 --> 23:03.020 it arrives all its outputs, and its JSON looks like this, but this one is generated from the UDB as a source of 23:03.020 --> 23:08.780 information. It can also generate all the other outputs for different use cases. As I said, 23:08.780 --> 23:15.820 in coding.h is used by spike instructions. Go is used by the goal language, and well, 23:15.820 --> 23:21.820 there are many other use cases for these outputs. Now, how does the UDB relates to the current 23:21.820 --> 23:28.300 challenges that I started this talk with? So, it can see instances through all different documents 23:28.300 --> 23:34.140 that sometimes appeared. Well, all these documents that you just saw are built from the same source. 23:34.140 --> 23:39.980 So, you won't ever find an inconsistency, because they indeed are the same information represented 23:39.980 --> 23:47.340 in different ways. Information not being referenced, that also will not happen in the UDB, the 23:47.340 --> 23:52.620 built system, or else stagging, and you'll easily find your information inside those manuals. 23:53.580 --> 23:59.500 Then, creating CPU stock implementation requires copy-pasting DIS. Well, not anymore. If you use the 23:59.500 --> 24:06.540 UDB, you'll be able to just create a config of your CPU and from that, you'll have the documentation 24:06.540 --> 24:11.900 that you'll need. Again, the moreover, current information not being machine readable, as I 24:11.900 --> 24:17.100 showed you, UDB comes with a nice YAML format, and that is totally machine readable, and 24:17.100 --> 24:23.580 parts of all in many ways, you can try to do so. And no reliable solution to create a 24:23.660 --> 24:30.860 alert documentation. Well, I think I've clearly provided the answer for this as the UDB creates 24:30.860 --> 24:37.740 this alert documentation. Now, what does the UDB not solve? Because, well, the UDB is not here to solve 24:37.740 --> 24:43.900 every problems, although we'd like to. The UDB is not meant to describe full SOC, so not as the 24:43.900 --> 24:50.220 peripherals that you may see will not be available in the UDB, only CPU information. And current 24:50.300 --> 24:56.460 roadblocks, copy-pasting is a chicane and egg problem, so the UDB is copy-pasted, and information 24:56.460 --> 25:03.260 is not verified by a lot of people. And information is not verified by a lot of people due to the 25:03.260 --> 25:11.020 UDB team not being huge at this time. Well, I quickly rushed through this slide, because I thought 25:11.020 --> 25:18.300 I was out of time, but I'll go back to it. There is still pros, and that pros will not be verified, 25:18.380 --> 25:24.060 although all the rest of the information can be well, you can't really verify text in any way. 25:24.860 --> 25:28.940 And well, there are, if there is information missing, in some of the new outputs, the UDB 25:28.940 --> 25:32.780 generates, that's because we can't really fetch it from anywhere. I showed you on the index, 25:32.780 --> 25:41.660 there will some blank fields. Now, use cases. So, I've mentioned a few of these use cases, 25:41.660 --> 25:48.140 like the certifications to become a TSIG, is using it to create the CRDs. The welcome has created 25:48.140 --> 25:53.180 an extension, that is only described and available through the UDB as of now. 25:53.180 --> 25:59.260 So, nobts is using it to generate arc-5 processors documentation. It can substitute risk-5 25:59.260 --> 26:06.380 obcodes if at some point that is required. And it can provide content for all the new tools or 26:06.380 --> 26:13.340 documents that you may find with your creativity to use it for. Future work. Well, 26:13.500 --> 26:18.460 future steps are vendors and consumers relying on the UDB to create their documentation. 26:18.460 --> 26:23.260 Even if you have some issues, some CPUs that you don't have really good documentation for, 26:23.260 --> 26:27.580 you can do the test, you can go into the UDB and generate your own documentation. 26:27.580 --> 26:35.500 New tools can be live on the UDB and you can specify your eyes and peripherals there, 26:35.500 --> 26:41.980 maybe, in the future. So, the UDB and goal. The UDB and goal is to become the main source of 26:41.980 --> 26:48.620 information for the risk-5. We hope that happens, but currently we're working to do it. 26:50.780 --> 26:55.740 Call for help. So, before finishing this presentation, the UDB is already being developed 26:55.740 --> 27:00.620 collaboratively. There are several engineers from a whole different companies like 27:00.620 --> 27:08.700 Akiana, Qualcomm, Reval, SIF-5, Synopsis, and Ventania, but we need more help. We need a community 27:08.700 --> 27:15.180 to help us. If you're interested in this, please join us. Check our GitHub repository, 27:15.980 --> 27:21.260 check all the issues and discussions that are currently going on. You can also join our weekly meetings. 27:21.260 --> 27:29.820 Although there is no formal SIG yet, it might happen soon. So, yeah, for now, contact me and I'll 27:29.820 --> 27:35.020 invite you to this weekly meetings. Finally, if you're really really interested in Synopsis, 27:35.020 --> 27:41.340 hiring someone to work on the UDB. So, yeah, contact me if interested or check the QR code. 27:42.220 --> 27:45.340 Thank you.