WEBVTT

00:00.000 --> 00:09.000
All right, my name is Mohammed Galu.

00:09.000 --> 00:13.000
I'm a embedded software consultant out in New York City.

00:13.000 --> 00:17.000
My company's map lab embedded solutions, and this is my talk.

00:17.000 --> 00:22.000
Essentially, you kind of follow up to last your stock and we'll go over what that means in a little bit.

00:22.000 --> 00:23.000
So this is just about me.

00:23.000 --> 00:27.000
Like I said, I'm an embedded software consultant in New York City in America.

00:27.000 --> 00:32.000
Mostly due design work focused on medical devices, scientific instruments,

00:32.000 --> 00:37.000
a light art project that I've been working on recently that involves FPGAs,

00:37.000 --> 00:42.000
and also this past year worked on writing embedded software

00:42.000 --> 00:47.000
implementing Zephyr on a custom ASIC that also had a risk, five core on it.

00:47.000 --> 00:53.000
So obviously my experience in expertise is in Zephyr embedded Linux,

00:53.000 --> 00:57.000
and also some gooey-based applications that are based on cute.

00:57.000 --> 00:59.000
You can sign up for my newsletter.

00:59.000 --> 01:02.000
I host a number of webinars and workshops throughout the year.

01:02.000 --> 01:07.000
This year, going to go into some more training events surrounding embedded Linux,

01:07.000 --> 01:10.000
Yaco, and Zephyr.

01:10.000 --> 01:14.000
So this is a quick rundown of the agenda for today.

01:14.000 --> 01:17.000
We're going to just go over some background.

01:17.000 --> 01:21.000
We're going to briefly go under the hood.

01:21.000 --> 01:26.000
And part of I just want to set the stage for this talk,

01:26.000 --> 01:30.000
because of my vicinity to FPGA engineers,

01:30.000 --> 01:32.000
like I pretend to be an FPGA engineer.

01:32.000 --> 01:34.000
So I like to do things that are with it,

01:34.000 --> 01:36.000
that are at the nexus of FPGA development,

01:36.000 --> 01:38.000
and embedded software engineers,

01:38.000 --> 01:43.000
but embedded software, but what you'll see is that eventually I stumble,

01:43.000 --> 01:44.000
and I need help.

01:44.000 --> 01:47.000
And so part of the motivation behind this talk is to reach out

01:47.000 --> 01:50.000
to hopefully the right community and get help,

01:50.000 --> 01:53.000
and we'll see where that goes.

01:53.000 --> 01:58.000
So under the hood, the plan, what I had envisioned when working on this project,

01:58.000 --> 02:02.000
how it went, it didn't go well, and what are the next steps, right?

02:02.000 --> 02:05.000
So understanding how to debug, like basically,

02:05.000 --> 02:07.000
teaching an embedded software engineer,

02:07.000 --> 02:12.000
like how do you debug FPGA code using open source tools?

02:12.000 --> 02:14.000
So like I said, some background last year,

02:14.000 --> 02:16.000
I gave the precursor to this talk.

02:16.000 --> 02:20.000
Which was essentially using an open source risk five,

02:20.000 --> 02:24.000
32 implementation on an FPGA.

02:24.000 --> 02:32.000
It was based on a really lattice ice 25 PK, like FPGA.

02:32.000 --> 02:34.000
Really inexpensive, so you know,

02:34.000 --> 02:37.000
didn't have to spend too much money getting the board.

02:37.000 --> 02:43.000
I was able to load hello world from Zeffer onto the FPGA,

02:44.000 --> 02:47.000
and you know, the exciting thing was it worked

02:47.000 --> 02:49.000
to a certain degree out of the box.

02:49.000 --> 02:52.000
I used not open source tools.

02:52.000 --> 02:54.000
I used the vendor like lattice tools,

02:54.000 --> 02:57.000
which you know, was fine for the moment.

02:57.000 --> 03:00.000
It was fine for the time.

03:00.000 --> 03:04.000
So the obvious next step,

03:04.000 --> 03:06.000
if you look at last year's presentation,

03:06.000 --> 03:09.000
was I wanted to kind of investigate the CFU,

03:09.000 --> 03:12.000
because the cool thing about the new RV 32 project

03:12.000 --> 03:15.000
is that it has the function.

03:15.000 --> 03:18.000
It's easy for me as not an FPGA engineer

03:18.000 --> 03:20.000
to enable CFU support,

03:20.000 --> 03:23.000
and they have software examples on how to actually exercise it.

03:23.000 --> 03:27.000
They have their example code actually demonstrates

03:27.000 --> 03:30.000
the performance metrics that has a small function

03:30.000 --> 03:34.000
that you can execute to understand what the performance

03:34.000 --> 03:37.000
difference is between a simple kind of custom function

03:37.000 --> 03:39.000
and implementation in hardware,

03:39.000 --> 03:42.000
versus the equivalent implementation in software.

03:42.000 --> 03:45.000
But when I tried to do that,

03:45.000 --> 03:46.000
so here on this thing,

03:46.000 --> 03:49.000
it's basically the summary of the screenshot

03:49.000 --> 03:52.000
that you have is essentially what was the culmination

03:52.000 --> 03:53.000
of last year's presentation.

03:53.000 --> 03:56.000
We get hello world running on new RV 32.

03:56.000 --> 04:00.000
But the problem was when I tried to enable CFU last year,

04:00.000 --> 04:02.000
it didn't fit on the FPGA.

04:02.000 --> 04:04.000
The lattice tools basically complete,

04:04.000 --> 04:07.000
that oh, your FPGA doesn't have enough resources

04:07.000 --> 04:10.000
to be able to support the design that enables CFU.

04:10.000 --> 04:13.000
So that was the motivation behind this,

04:13.000 --> 04:15.000
this talk in this project.

04:15.000 --> 04:17.000
So just some precursor,

04:17.000 --> 04:20.000
again, maybe 90% of you are like,

04:20.000 --> 04:22.000
you know, why are you talking about this?

04:22.000 --> 04:23.000
This is, you know, we already know this,

04:23.000 --> 04:25.000
but you know, for the 10% like me,

04:25.000 --> 04:27.000
it's useful to understand some of these

04:27.000 --> 04:29.000
some of this background material.

04:29.000 --> 04:33.000
So what is the custom function unit in risk five?

04:33.000 --> 04:36.000
Essentially it allows us to offload functionality

04:36.000 --> 04:40.000
to hardware that you can implement outside of the extension

04:40.000 --> 04:42.000
outside of the risk five.

04:42.000 --> 04:46.000
I say, right, that's your own custom implementation,

04:46.000 --> 04:48.000
but there's infrastructure surrounding it

04:48.000 --> 04:52.000
to allow essentially software to talk to the hardware

04:52.000 --> 04:55.000
to be able to execute certain functions in hardware

04:55.000 --> 04:58.000
and you can retrieve those results.

04:59.000 --> 05:03.000
There are useful for operations that are not,

05:03.000 --> 05:06.000
that it's not optimal to implement in hardware.

05:06.000 --> 05:08.000
So if you're concerned about performance,

05:08.000 --> 05:10.000
if you're concerned about latency,

05:10.000 --> 05:12.000
energy consumption and program memory,

05:12.000 --> 05:14.000
it may be useful to investigate

05:14.000 --> 05:17.000
your implementation of your function in hardware

05:17.000 --> 05:19.000
and then leverage the CFU extension

05:19.000 --> 05:23.000
to be able to allow software to call into hardware

05:23.000 --> 05:27.000
to implement to actually exercise that function that you want.

05:27.000 --> 05:31.000
So some examples of why you would want to use

05:31.000 --> 05:33.000
as CFU AI, right?

05:33.000 --> 05:35.000
So now we're seeing a lot of days.

05:35.000 --> 05:38.000
There's a lot of advancements that are enhancement

05:38.000 --> 05:40.000
that you can make in terms of your implementation in hardware

05:40.000 --> 05:42.000
that are relevant to AI.

05:42.000 --> 05:46.000
So you may be beneficial to leverage the CFU extension

05:46.000 --> 05:49.000
to implement some of these function calls

05:49.000 --> 05:52.000
or in hardware and then essentially leverage that extension

05:52.000 --> 05:55.000
to make that call in from the software side.

05:55.000 --> 05:59.000
Crypto obviously communications arithmetic and image processing.

05:59.000 --> 06:03.000
So one of the restrictions that I learned about the CFU is

06:03.000 --> 06:05.000
that it requires CPU dependency.

06:05.000 --> 06:08.000
So it's not something that you can just tell the hardware

06:08.000 --> 06:11.000
okay go and the CPU kind of comes back and says,

06:11.000 --> 06:12.000
okay, fetch me the result.

06:12.000 --> 06:15.000
It's something that the CPU needs to be involved

06:15.000 --> 06:18.000
in terms of producing that result.

06:18.000 --> 06:22.000
So the CFU from mind your standing is that it requires

06:22.000 --> 06:27.000
the CPU to be a part of the operation when you're doing it.

06:27.000 --> 06:34.000
So the CFU actually leverages these custom kind of

06:34.000 --> 06:37.000
op codes in the ISA.

06:37.000 --> 06:42.000
So like I said, the CFU is a specific implementation

06:42.000 --> 06:44.000
of an extension of the ISA.

06:44.000 --> 06:49.000
So that's the CFU extension and that is specific.

06:49.000 --> 06:54.000
This particular extension is specific to the NIORV32 implementation.

06:54.000 --> 06:58.000
And the cool thing like I said is they have a sample implementation

06:58.000 --> 07:02.000
of a block cipher called XDA in the RTL, right,

07:02.000 --> 07:06.000
which is a really simple implementation

07:06.000 --> 07:09.000
or of that's useful for embedded systems.

07:09.000 --> 07:14.000
And so like right here you can see the bottom table

07:14.000 --> 07:17.000
essentially shows how the op codes are mapped

07:17.000 --> 07:21.000
and that you can leverage those to give you a particular kind of

07:21.000 --> 07:23.000
CFU implementation.

07:23.000 --> 07:29.000
So this is basically kind of showing again the mapping

07:29.000 --> 07:33.000
between the actual RTL in the NIORV implementation

07:33.000 --> 07:36.000
and then from the software side how their demo code kind of

07:36.000 --> 07:37.000
implements.

07:37.000 --> 07:41.000
So essentially what they're doing is they're using the

07:41.000 --> 07:45.000
extrinsic inside the compiler to call functions

07:45.000 --> 07:46.000
in the CFU, right.

07:46.000 --> 07:51.000
So essentially they have a particular set of op codes

07:51.000 --> 07:56.000
that are extended using the CFU extension and then in

07:56.000 --> 07:59.000
the software they essentially have these extrinsic

07:59.000 --> 08:03.000
that are defined that essentially just call the the

08:03.000 --> 08:07.000
compiler to basically implement a particular op code and then

08:07.000 --> 08:10.000
the compiler essentially sets up the appropriate

08:10.000 --> 08:13.000
instructions to make calls into the RTL.

08:14.000 --> 08:17.000
And then here's you can see essentially like more

08:17.000 --> 08:20.000
more macros that essentially convert

08:20.000 --> 08:23.000
calling into this CFU particular instruction.

08:23.000 --> 08:28.000
And then we can see here like if you map what's on the

08:28.000 --> 08:32.000
the last set of bits in the bottom macro they map

08:32.000 --> 08:36.000
essentially to like the op codes for a particular kind of CFU

08:36.000 --> 08:39.000
in the table down here.

08:39.000 --> 08:42.000
And then if you write if you actually again like

08:42.000 --> 08:46.000
just just go into macros again you can see that this is

08:46.000 --> 08:50.000
finally the assembler call that actually makes that that

08:50.000 --> 08:54.000
is invoked by essentially setting the appropriate

08:54.000 --> 08:58.000
op codes and then making the calls into the RTL essentially

08:58.000 --> 09:01.000
and then the compiler basically handles the magic of

09:01.000 --> 09:04.000
you know making the calls into the RTL for the

09:04.000 --> 09:07.000
particular implementation that you want.

09:07.000 --> 09:11.000
So just just kind of like an overview of the background

09:11.000 --> 09:16.000
on you know what what the CFU means understanding how

09:16.000 --> 09:19.000
the software essentially ties into the hardware and how

09:19.000 --> 09:21.000
we can kind of leverage those calls.

09:21.000 --> 09:22.000
So now the plan right.

09:22.000 --> 09:26.000
So last time when we try to run the design with the CFU

09:26.000 --> 09:29.000
enabled the tools complain that okay you know your your

09:29.000 --> 09:32.000
FPJ doesn't support doesn't have enough room to

09:32.000 --> 09:34.000
essentially support the functionality or support your

09:34.000 --> 09:35.000
design.

09:35.000 --> 09:38.000
So step one is get an FPJ that does fit this design.

09:38.000 --> 09:43.000
Enable to see a few in the top level board file in the

09:43.000 --> 09:44.000
RTL.

09:44.000 --> 09:46.000
Build in flash design.

09:46.000 --> 09:48.000
You know let's start simple let's just load

09:48.000 --> 09:50.000
Zefer, Blinky or hello world.

09:50.000 --> 09:52.000
Make sure that's working.

09:52.000 --> 09:54.000
And then okay now we need to add what the

09:54.000 --> 09:57.000
macros that you saw in their demo example we need to add

09:57.000 --> 10:01.000
those into Zefer compile those in our demo example

10:01.000 --> 10:04.000
that runs essentially the same XCA blocks

10:05.000 --> 10:08.000
I for and then do the same comparison in the reference

10:08.000 --> 10:11.000
design that they have in their software repo.

10:11.000 --> 10:14.000
And you see if we can do the same thing on Zefer right.

10:14.000 --> 10:16.000
And and essentially like we have a reference

10:16.000 --> 10:20.000
implementation of the non Zefer application right

10:20.000 --> 10:23.000
and we have a reference and we have an implementation of

10:23.000 --> 10:26.000
the Zefer XDA just confirmed that actually the

10:26.000 --> 10:29.000
operations in terms of performance they actually match

10:29.000 --> 10:30.000
the reference design.

10:30.000 --> 10:33.000
Right and so for the first step right this is the the

10:33.000 --> 10:36.000
report that I just decided to use because it was

10:36.000 --> 10:38.000
reference in their repository.

10:38.000 --> 10:40.000
It's an orange crab FPGA.

10:40.000 --> 10:42.000
It's also relatively cheap.

10:42.000 --> 10:45.000
I think it costs like $30 or so.

10:45.000 --> 10:48.000
And you know it was just small.

10:48.000 --> 10:54.000
The problem was that the orange crab that exist today

10:54.000 --> 10:56.000
is actually a much bigger.

10:56.000 --> 10:58.000
It's both good in that right it's good because it's a

10:58.000 --> 11:01.000
bigger FPGA than the board I was using last year.

11:01.000 --> 11:05.000
So I was expecting that would support CFU support.

11:05.000 --> 11:06.000
The CFU extension.

11:06.000 --> 11:08.000
So that shouldn't be a problem.

11:08.000 --> 11:11.000
The problem is again like there's as we're going to see

11:11.000 --> 11:15.000
there's a lot of infrastructure when you're using FPGA tools

11:15.000 --> 11:18.000
that are open source that you need to set up to make sure

11:18.000 --> 11:20.000
that it actually builds for the right thing.

11:20.000 --> 11:23.000
So so it boots right.

11:23.000 --> 11:26.000
And yeah so like I said like the current orange crab

11:26.000 --> 11:29.000
implementation the setup that they're using uses the

11:29.000 --> 11:31.000
smaller FPGA.

11:31.000 --> 11:37.000
So it wasn't going to work obviously in the board that I purchased.

11:37.000 --> 11:41.000
So the first step forget forget even just you know building the

11:41.000 --> 11:47.000
RTL loading it onto the FPGA and just seeing if it works.

11:47.000 --> 11:51.000
I couldn't even just get the tools to install correctly right.

11:51.000 --> 11:54.000
So what I did was you know again software engineer.

11:54.000 --> 11:57.000
Okay let me just see the tools that they're using and just install

11:57.000 --> 11:59.000
it on my local machine.

11:59.000 --> 12:01.000
Nope that one just terribly wrong all sorts of ours.

12:01.000 --> 12:03.000
No idea what's going on.

12:03.000 --> 12:05.000
So I took an easier route.

12:05.000 --> 12:07.000
I said well they have to build the somehow right.

12:07.000 --> 12:10.000
So let me see what they did and just copy whatever they're doing.

12:10.000 --> 12:15.000
So I noticed that in their GitHub actions their workflow.

12:15.000 --> 12:18.000
They're essentially just using a container that they pulled from

12:18.000 --> 12:21.000
somewhere that has a necessary tools has a necessary set up.

12:21.000 --> 12:23.000
So I did the same thing right.

12:23.000 --> 12:26.000
So I just copy to essentially their container their doctor file.

12:26.000 --> 12:29.000
And I stripped it down to essentially whatever I need it.

12:29.000 --> 12:34.000
And you know just essentially ran that as a container on my PC.

12:34.000 --> 12:39.000
So this was exactly the doctor file that I have that I use on my machine

12:39.000 --> 12:40.000
to build these things.

12:40.000 --> 12:44.000
And then on the bottom here you can essentially see the container

12:44.000 --> 12:48.000
and vacation that I have which essentially just runs make

12:48.000 --> 12:53.000
specific to this particular board and then runs a target that essentially just

12:53.000 --> 12:55.000
creates an image which is a bootloader.

12:55.000 --> 12:58.000
Which is the only thing I care about.

12:58.000 --> 13:03.000
So once I had the tools running right did a basic compilation of the

13:03.000 --> 13:04.000
actual design.

13:04.000 --> 13:08.000
So like okay the next step is to actually enable CFU support.

13:08.000 --> 13:09.000
So that was simple enough.

13:09.000 --> 13:13.000
I just looked at the top level design file.

13:13.000 --> 13:16.000
And I just set the flag for CFU to true.

13:16.000 --> 13:18.000
So simple enough.

13:18.000 --> 13:22.000
The other problem is again.

13:22.000 --> 13:26.000
Because the existing design assumes that the orange crab board

13:26.000 --> 13:29.000
supports up the older smaller FPGA.

13:29.000 --> 13:33.000
I needed to modify it to be able to support the newer one right.

13:33.000 --> 13:35.000
And so I learned this the hard way.

13:35.000 --> 13:37.000
I essentially didn't know about this.

13:37.000 --> 13:40.000
I just built it and built fine flashed it like nothing happened right.

13:40.000 --> 13:41.000
I didn't get any bootloader.

13:41.000 --> 13:42.000
I didn't get anything.

13:42.000 --> 13:44.000
Look on the forums they're like yeah.

13:44.000 --> 13:51.000
Yeah because you didn't actually tell the tools to build for an 85 series FPGA.

13:51.000 --> 13:54.000
You still told it to build for 25 series FPGA.

13:54.000 --> 13:59.000
So okay the easiest thing for me to do after kind of digging around the

13:59.000 --> 14:01.000
help files for the tools that I was using.

14:01.000 --> 14:06.000
Let me just replace this 25 with the 85 and then see how it goes.

14:06.000 --> 14:11.000
Ideally the orange crab like initially what I did you know the proper way

14:11.000 --> 14:12.000
of doing things was okay.

14:12.000 --> 14:18.000
Let me just change this variable that they're using in their make files to an 85F instead of

14:18.000 --> 14:20.000
using 25F.

14:20.000 --> 14:22.000
That just was disastrous like that didn't work.

14:22.000 --> 14:26.000
It's all because all sorts of issues so I said okay let me just try the easy way out

14:26.000 --> 14:32.000
and just I know this flag is used for the FP that's used to the that's specified

14:32.000 --> 14:36.000
to the FPGA tools to indicate which FPGA they want to use.

14:36.000 --> 14:40.000
So I'll just change that for now and then leave all the rest for later.

14:41.000 --> 14:46.000
So after I did all those changes got my container running with the tools.

14:46.000 --> 14:51.000
Made the changes of the make files to use the larger FPGA and able CFU support

14:51.000 --> 14:54.000
successfully built the FPGA.

14:54.000 --> 15:01.000
They used the suggest using the FPGA to flash the FPGA essentially just hold down the power button

15:01.000 --> 15:05.000
while you're plugging it in and it's just going to enter program mode.

15:05.000 --> 15:14.000
And I needed to do some do some mechanics with DFU to basically attach the FPGA information

15:14.000 --> 15:19.000
or the hardware information to this DFU file and then once that was up and running

15:19.000 --> 15:23.000
I was able to just get bootloader output from the UR.

15:23.000 --> 15:30.000
So so that's great right at least I confirm that I can get something running on my FPGA

15:30.000 --> 15:33.000
that is based on risk five.

15:33.000 --> 15:36.000
It kind of you know at least something is working right.

15:36.000 --> 15:40.000
So the next step was okay let me just take the upstream Zephyr repo,

15:40.000 --> 15:45.000
latest LTS for.0 and see what happened later certainly it's not LTS.

15:45.000 --> 15:53.000
So built it, create, try to you know just load the application using the bootloader.

15:53.000 --> 15:58.000
They have a script that allows you to like just essentially do the same thing

15:58.000 --> 16:01.000
more scripted in a more scripted way.

16:01.000 --> 16:06.000
The problem ended up being that when I tried to actually upload it the bootloader complaint right

16:06.000 --> 16:08.000
through this error.

16:08.000 --> 16:13.000
Instead of reading the source code for the bootloader their documentation for the repository is really great.

16:13.000 --> 16:18.000
So it's essentially said that the application image you're trying to flash is too large.

16:18.000 --> 16:23.000
So you know you need to essentially increase the particular parameter in your RTL

16:23.000 --> 16:26.000
and then that should work hopefully.

16:26.000 --> 16:33.000
Based on their recommendation I increase this instruction memory size from 16k to 32k.

16:33.000 --> 16:35.000
Recompiled the design again.

16:35.000 --> 16:41.000
This time the bootloader didn't complain but I still wasn't getting any hello world right.

16:41.000 --> 16:46.000
No blanky, no hello world from the basic kind of Zephyr build.

16:46.000 --> 16:49.000
And so I said okay let me take a step back.

16:49.000 --> 16:54.000
Let me see whether it's a problem with maybe it's a Zephyr problem right.

16:54.000 --> 16:55.000
Let me just go back.

16:55.000 --> 17:01.000
Let me go to the reference implementation on the software side and see like okay if I can I just load a blanky example.

17:01.000 --> 17:05.000
I tried to write building it still same issue.

17:05.000 --> 17:09.000
I couldn't get their application to run one loading through the bootloader.

17:09.000 --> 17:12.000
There's no indication of any error.

17:12.000 --> 17:13.000
The bootloader just is there.

17:13.000 --> 17:17.000
So it seems to me that the bootloader is actually jumping to the application.

17:17.000 --> 17:23.000
But when it goes to when the application goes to load there's clearly something wrong.

17:23.000 --> 17:30.000
So the question is right and you know this is hopefully this is why I'm here right asking for help.

17:30.000 --> 17:33.000
So I need to understand like what tools.

17:33.000 --> 17:41.000
What resources that I can use to understand like okay once I'm in the bootloader you know like what's going on right.

17:41.000 --> 17:44.000
So clearly something is working in the design right I can get you right output.

17:44.000 --> 17:52.000
The bootloader is actually doing something right it's actually receiving the image and it's saying okay right you know the image looks good.

17:52.000 --> 17:58.000
But then when I try to execute that image right that's where the bootloader is complaining so the question is is it.

17:58.000 --> 18:04.000
Is it an FPGA problem or is it still a software problem right do I need to debug the bootloader to understand.

18:04.000 --> 18:15.000
What the problem is or do I need to debug the FPGA size to understand what problem is now one thought that did occur to me today was that one of the features of.

18:15.000 --> 18:27.000
This implementation is that you can actually generate VHDL of the application that you're trying to build and actually embed it into your actual design so that you know if that works.

18:27.000 --> 18:33.000
So I don't know like if that's a better way to debug something or a worse way does that would that tell me anything.

18:33.000 --> 18:43.000
But you know again you know from from an embedded software perspective point of view like what are the types of tools that I can use to and it's not just.

18:43.000 --> 18:54.000
The tools right so in this in this project I used like truly open source tools because again the the platform that they supported was like you know somebody had used open source tools.

18:54.000 --> 18:58.000
To be able to like build a design and and load them.

18:58.000 --> 19:10.000
But what can I do in terms of debugging right so you know as an embedded software engineer I know J tag I know SWD I know GDB I know how can I know what you do in those cases right how to debug software.

19:10.000 --> 19:21.000
But what are the equivalent tools that I can use from an FPGA point of view right I've done the Ziling's ILA and I've used an opposite identifying micrachip.

19:21.000 --> 19:29.000
Platform so what are the equivalent of of open source tools right like what software tools do I need what hardware tools do I need.

19:29.000 --> 19:34.000
To be able to kind of perform these troubleshooting steps so.

19:35.000 --> 19:37.000
So what are the next steps right so.

19:37.000 --> 19:41.000
Obviously right the first step is just to get the application to load.

19:41.000 --> 19:47.000
And then just do what I'd originally planned out to do right get these comparison metrics and zephyr.

19:47.000 --> 19:51.000
Hopefully you know if it's successful I can present it next year.

19:51.000 --> 20:02.000
And then again integrate the see a few this is the whole plan of this into zephyr right add those necessary calls and try to upstream the libraries or the modifications that I make disaster.

20:02.000 --> 20:09.000
I try to get it in zephyr as part of the architecture implementation and then the next thing that I want to investigate is.

20:09.000 --> 20:22.000
What I a new feature that I learned of the risk five is is and it's it's an extension or enhancement of CFU which is a custom function subsystem and it allows from for my understanding it allows essentially.

20:22.000 --> 20:30.000
The hardware to and perform operations that are completely independent of the CPU and that doesn't need any CPU dependencies.

20:30.000 --> 20:37.000
So hopefully those are the next steps and hopefully you know somebody out there can help me figure out what I did wrong so far.

20:37.000 --> 20:39.000
Yep, so thank you.

20:39.000 --> 20:48.000
All right, well time for questions.

20:48.000 --> 20:59.000
Any questions?

20:59.000 --> 21:13.000
Yeah, so what I understand is that you enable something first in digital design right and everything rest of the software let's say was same and now it's not booting in application right.

21:13.000 --> 21:24.000
So first thing would be if you change anything in digital design right you would have to run it against some basic verification right with very later or something.

21:24.000 --> 21:29.000
That's some messages in the system where you log in see what happens.

21:29.000 --> 21:31.000
That's the basic thing.

21:31.000 --> 21:41.000
Again, and if you come on the software side then so you have let's say directly accessing physical memory right to load the loads.

21:41.000 --> 21:51.000
So there are other software also right not just the boot loader that you can run on a physical application and try to access that but for the address that you have added in the digital design.

21:51.000 --> 21:54.000
There are things like mayor box or something else.

21:54.000 --> 21:59.000
By saying that you can use to access that but the thing that you have added in the design.

21:59.000 --> 22:01.000
Are you able to access it or are you pretty.

22:01.000 --> 22:08.000
So you're saying even instead of the boot loader or remove the boot loader what does boot loader do is that it writes some.

22:08.000 --> 22:12.000
This is some basic physical address.

22:12.000 --> 22:15.000
You can do it yourself jump there and try to do yourself.

22:15.000 --> 22:19.000
I see right not don't try to jump to application land and try to go from.

22:19.000 --> 22:27.000
And you're also just suggesting to remove the like just remove the enablement of the see see a few and then just.

22:27.000 --> 22:33.000
I would first enable the see a few and do some verification before I go on the software side.

22:33.000 --> 22:37.000
And and for verf like would and can you elaborate more on the verification.

22:37.000 --> 22:41.000
I use very later but who have money they use model same.

22:41.000 --> 22:42.000
Got it.

22:42.000 --> 22:43.000
So many things right.

22:43.000 --> 22:44.000
Got it.

22:44.000 --> 22:46.000
So it depends how much you know.

22:47.000 --> 22:49.000
Can you spend on that right.

23:06.000 --> 23:12.000
Yeah, maybe also to expand on the like available back in features.

23:13.000 --> 23:18.000
I just looked at it and the new RV32 also supports like on ship debugging.

23:18.000 --> 23:22.000
So another feature you can enable and then you get jetac access to it.

23:22.000 --> 23:28.000
You'll probably have to add some pin definitions because right you need for wires for jetac.

23:28.000 --> 23:32.000
You need to tell the FPGA better out those.

23:32.000 --> 23:33.000
Got it.

23:33.000 --> 23:36.000
And then you just have jetac for the CPU course.

23:36.000 --> 23:40.000
So that's maybe also another avenue you can look at.

23:41.000 --> 23:42.000
I see.

23:46.000 --> 23:52.000
You ask for the debugging tool for which let is providing you this is called reveal.

23:52.000 --> 23:55.000
You can just check with.

23:55.000 --> 23:59.000
But then you have to go through those with a tool flow and right.

23:59.000 --> 24:04.000
To localize or you have to go in and stuff to get.

24:04.000 --> 24:06.000
At the instrumentation, but this is working.

24:06.000 --> 24:09.000
As you are used to everything.

24:09.000 --> 24:13.000
Do I do I need to use to I need to use their.

24:13.000 --> 24:18.000
Kind of debugging tool with their entire work because this design was implemented.

24:18.000 --> 24:27.000
I'm not aware of any open source tool yet to do the same things that will be identified with open source.

24:27.000 --> 24:28.000
I have not seen that.

24:28.000 --> 24:31.000
I would be very glad to see that.

24:31.000 --> 24:37.000
There was a really really really all to providing some kind of that features.

24:37.000 --> 24:42.000
But it's so all that it was using them parallel port to.

24:42.000 --> 24:44.000
Collect to the GUI and things.

24:44.000 --> 24:46.000
So this is a missing piece.

24:46.000 --> 24:49.000
And as I saw you are using.

24:49.000 --> 24:52.000
Your reference implementation is in VH.

24:52.000 --> 24:55.000
So you are using G.

24:55.000 --> 24:56.000
G.

24:56.000 --> 24:57.000
Right.

24:57.000 --> 24:58.000
Yeah.

24:58.000 --> 25:01.000
So.

25:01.000 --> 25:06.000
Try to to simulate your whole design in G.

25:06.000 --> 25:09.000
Go get it working there without the hardware.

25:09.000 --> 25:10.000
Get the inside.

25:10.000 --> 25:12.000
To each year and get gt.

25:12.000 --> 25:14.000
Keywave.

25:14.000 --> 25:22.000
And you can also think about using more elaborate tools around ght to get your serial port running.

25:22.000 --> 25:23.000
As it would.

25:23.000 --> 25:24.000
Oh I see.

25:24.000 --> 25:25.000
Interesting.

25:25.000 --> 25:29.000
From my head I don't know if co code TB supports actually you are.

25:29.000 --> 25:31.000
Communication things like that.

25:31.000 --> 25:36.680
co-co-TV is wrapping around your simulator so you can put stuff inside your simulator

25:36.680 --> 25:45.160
and getting things out and to cause emulation or additional test cases or you do not describe

25:45.160 --> 25:51.960
your test cases in VHD or wherever you lock anymore but you do the whole control of your inputs

25:51.960 --> 26:00.280
and outputs in pipes and so this would be a modern way for verification of this kind of

26:01.080 --> 26:08.920
if let's say I try lattices tool flow right to build the design with let's say ccfu enabled

26:08.920 --> 26:14.120
and it works and let's say with the open source tools it doesn't like well I'm just I'm just

26:14.120 --> 26:20.040
kind of speculating if that if that were to happen then like would you would you have any suggestions

26:20.040 --> 26:25.960
on okay like on the open source workflow it's not working right do do I still go down the route of

26:26.040 --> 26:30.760
verification and you know doing test benches to make sure what's going on if that happens

26:30.760 --> 26:37.880
open a bug report on cmbflow okay because this should not happen it's the cpu is described in

26:37.880 --> 26:45.080
plane vh here so it should not matter okay cool cool god thank you your problem you see somewhere else god

26:45.880 --> 26:48.280
from my copy god thank you yeah

26:58.040 --> 27:04.680
actually if you have something that is working with latice tool not working with the open source

27:04.680 --> 27:10.440
tool it could be also maybe some timing issue sorry was a last part timing issue timing

27:10.440 --> 27:23.400
god but then wouldn't if it's but wouldn't I see like a failure in the implementation

27:23.400 --> 27:34.760
if it's failing timing god because I thought like timing timing validation is like a

27:34.760 --> 27:39.960
is binary if it passes then your design should work if it fails and like there's no gray area

27:39.960 --> 27:45.640
if it fails you get the binary but it won't work god okay and the open source tools like

27:45.640 --> 27:50.440
would you expect them to still generate a binary even if timing fails yeah that does oh they do okay

27:50.440 --> 27:59.480
like so we're already once yeah god okay thanks because because in the latest tools

27:59.480 --> 28:05.160
it didn't even let me build a binary like the the the bitstream wasn't generated

28:05.160 --> 28:11.480
if timing fails essentially so I just assume that if timing fails like it just doesn't

28:11.480 --> 28:19.960
generate a bitstream for it god it okay but but but the blue loader still boots though right so

28:20.920 --> 28:24.840
I don't know

28:39.160 --> 28:41.240
Thank you