Yeah, I think I can start now.
Hi, I'm E-min, and I'll be talking about open source
two trends for things that I'm in as a system today.
First of all, myself, I'm a PhD student and I'm a amateur
FPG programmer. I'm doing things like risk file and the
design and also like things and attending microfares.
These are some boards of view, I've built.
There are the 8936XSDR for the pig set one board.
I've talked about it on the first time 2020 online.
I've also built boards like this.
Eight layers, the U15EG.
A well, it's still being debugged right now.
There are also some other things and I've added support for
a no-AMAMU Linux for 32-bit risk-5, but it's kind of something else.
So I think our first start from ordinary open source FPGA
two trends is relatively a new thing.
The first support was came in 2015, which is project
I-storm, is for the ethics as the 40 series,
like in this board showing here.
Largerist FPGA in this family is the I-C-40HSATK.
It has 8,000 element logic elements.
Then during the years, there can project failures for the
Latest ECP-5 series and there are quite large ships and ships
with transceivers.
Recently, there are project arpecula for
GoVFUGS. It's kind of a low-cost board.
You may know the GoVin terminal is quite cheap and easy to use with this
function, and for the maybe most widely used FPGA series,
the AMD or Zelling 7 series, there is a single flow and then
it's renamed to F4PGA, and it supports like
RTX chips up to 200,000 of logic elements, which is already quite a lot.
And now around two or three years ago,
there can open actually 7.
It's also for the 7 series FPGA, but it supports
like most ships like a Spartan.
There are RTX and also Kingtex, like shown here.
Well, maybe a reason that Kingtex support came is,
at that time there is a very cheap Kingtex board being released.
This QMTack, Kingtex 7, a 325T.
This cheap requires a Zelling license.
It's not free, so maybe many people's thoughts
or we'll just do the two-chain for this, and it came.
And now we can use Kingtex FPGA series,
which is open source purchase.
So, no, no, we'll add only open source months.
And here are some projects that are supported by open access
7 right now.
The green text are already supported part,
like the famous PICO RB32, and like King with 5,
or my SOC, or recently there's Uber DDR3,
the very nice open source DDR3 controller.
Of course, SD card or FDIM ad drivers will just work,
and about the prime teams or hard-easy blocks
inside the FPGA,
we can expect like KLL, clock modules,
and MMCM's just work.
The IOS 3D is on ordinary RL pins, just works,
and block RAM will also work.
And the IO bank, both 3.3 volt and 1.8 volt IO will work.
And now like, accept vertex,
or Delling 7 series, cheap source supported,
and the Zing 7 series program,
will launch across the supported.
The yellow text are projects that are being worked on,
but it haven't come to a full support yet.
It's mostly about like high speed transceivers.
They are cellular controller being worked on.
They are thinking about if the net being worked on,
and they are using the GTP and GTX transceivers.
And also there are PCI hot blocks in high end dynamics FPGA,
and recently I'm also working on like,
the support for the PCI hot block.
So if it's lucky after a few months,
maybe it will work as well, but particularly,
since it's an open source,
software can use it whatever ways we want.
Like, ordinary VW,
we only run on Windows and Linux on X6886 machines.
But this one can run on arm machines like this M1 laptop,
and we can also dockrize it,
so users don't need to install them locally.
Like, here are some of open source proteins stockrized,
so you can just pull this one and start developing right now.
And we can even use this for online services,
because why not?
There's no restrictions,
and the size of the two chain is not so small,
but also not so large.
The open axis 7 may be a 5-6 GB,
it's not that bad.
And now, how about zinc?
Well, things are complex devices with this kind of unique processing system
plus programmable logic structure.
The processing system, or PS,
is actually a dual core arm processor.
It has on DDR3 connected to it.
There are ordinary arm peripherals like,
it's a net in USB,
and it's interesting like,
the pins for those kind of high-speed peripherals
can also be customized.
It usually runs on runs, Linux, or autos.
And on the FPG inside,
it's a standard 7 series FPG fabric,
but since there are not so many pins available,
having DDR3 on these low-end things are not so popular,
but we can still use it to do whatever thing we can with FPG,
like, draw some HDMI or another Ethernet file,
or like LEDs or buttons,
and then we can also put custom logic,
like a co-processor or accelerator to this PR part.
So it can connect with the PS, with the high-speed interfaces
in the between their axis and the GPIOs.
And the thing is to start this device up,
this can only be done from the PS part.
So unlike ordinary FPG,
we just have a flash attached to it,
and it can start from the B-stream.
Here we need the arm part to start up,
and load the FPG as content,
and set up, for example,
clocks going from PS to the PL.
Well, now there's a question that,
are you confident building a thing put from our bioself?
One, two, three, five, maybe?
Well, my answer is actually no.
Yeah, and if the answer is yes,
then the question is how long does it take?
Well, traditionally we'll be using this,
the Vado flow, we'll begin from Vado.
We'll use the block design to design our FPG fabric,
and on the block design, there will be a special,
like IP call called the GPS,
and when we double click this,
we will see this interface,
and we will configure all our arm parameters,
like the DDR3 parameters,
like what IO pins we are using,
like the PSPR interconnect,
right down here.
This may bring an illusion
that this information are stored in the B-stream,
but actually it's not the case.
It's totally separated, and for example, you can try,
like setting, changing some parameters,
and generally the B-stream again,
you'll find the B-stream is exactly the same.
And actually this is a start externally,
like when we export hardware from Vado,
this board package will be generated.
It will contain the B-stream,
and the PS in it does see is
the register rise to bring up the arm core,
and a small export hardware storage is
more like a minimum configuration for software.
And then we will export this to Zarynx SDK,
and in the SDK we will build the first stage bootloader
or FSPL,
and like your user app running on the uncourse.
Like for Linux, this user app will be your boot,
but here I'm just talking about the most simple case.
And then after this, the bootloader
can be generated and put down to your boot device.
Well, all of these flows can be automated,
like for Vado, there are TCL scripts,
but for most use cases,
it's still a flow heavily based on,
like GUI and most clicks,
there are maybe hundreds of most clicks,
and it cannot be done in a very short time.
But now we have an open source version,
the Open Access 7 plus the new Gen Z.
And with this flow, we can build this bootloader
in less than five minutes.
Like here, the PL configuration,
the B-stream and the PS configuration are separated,
and this Gen Z is specially designed
to generate this PSP files from a text based configuration.
And then we use the open source settings
in various software library and your ordinary switching
to build the EF files.
Then there can be a small tool called
from a macro, is the tick-unkay boot image
to generate this bootload bin.
So it's all like text and online based flow.
Like what Gen Z is actually doing
is to set up all those registers
to correctly bring up the ARM course.
There are maybe hundreds of registered rights.
And well, I would say it's simpler than reverse engineering
the FUGA itself,
because we have these technical reference manual available.
As mostly those file files,
there are PLLs,
three of them for the ARM course and then DDR
and then the IO peripherals.
And then these PLLs will be used
to derive all the clock frequencies.
There are also DDR,
not the party ran out, it's been worked out.
And there are pins on the PSI.
It's interesting that the flexibility of the PSP
is achieved by a custody layer of maxis.
So like high speed peripherals,
we'll go through only one layer of max.
And the lowest speed peripherals
will go through all those maxis.
And there are peripherals like specific registers,
the URs, border rate, or whatever.
And there are some debug entries,
which maybe no one knows what they are doing.
And I can demonstrate the brand now.
Sorry.
So here is already a gen Z crown here,
and the open access 7 is in Docker containers.
I have modified this slightly for this ARM machine.
So we will use this, no DDR SD boot example.
And that there's already me to read.
And for the FPGA part,
we have a very minimum PSP out configuration example
in this FPGA.
There is a minimum actually device,
actually GPIO.
And then there is this instantiation of this PS7 hard block.
There are no parameters here,
because our parameters are set by ARM.
In FPGA, it's just like a placeholder.
And we can just call this Dockerize the two chain.
I'll run uses.
And then next point in root.
And then this print generation.
So now the print print have been built.
And we can prepare the PS part.
I have cloned this embedded software library here.
And we can first
create a new folder in this PSP.
And then we launch a gen Z to generate
our specific PSP files.
We'll just be using this file.
On top of it is a huge array.
It's kind of similar to the device configuration.
But of course, this time we handled by text.
The most entries are not used.
And only some are selected.
Like this UART.
Like there's SD card,
labeled by one here.
And we'll specify like bought rate and frequency.
And like bank voltages.
And then we'll just run it.
And you can see the PRL parameters are calculated.
And the ML pins are set.
And if you look at the file, we generated.
We can see in this PRL server in it.
There are quite a lot of values to write.
And this xprimus.h contains some parameters like the arm frequency.
I like what was the UART address.
And then we can copy this generated file into this embedded software library.
And then run the mix.
This is FSBL.
And then this is the hollow world.
We can find those.
Yeah, I've started generated.
And now it's time to generate the puto bin.
It is the same as on ZANX SDK.
We'll use a small PR file to specify what's inside.
So then generate using this empty puto bin.
And here, we can see the puto bin already generated.
We can then copy it to ask card connected here.
This is the SD card and the file is there.
Now I'll plug it into this thingboard.
And they'll connect the power with my power bank.
I hope it works.
Yeah, it works.
You can see this is the power LED.
And those two blinking LED are driven by the arm force.
Sending commands.
They're the X interface.
And then the XTG panel in the FUGA is blinking this LED.
Thank you.
No, thank you.
I'll continue this.
So now we have open source quotient.
What does this mean?
Well, maybe one interesting thing to look at is this RP2040.
Which is famous as this Raspberry Pi pickle.
I know it's far away from a fair comparison.
But this RP2040 also has a similar structure.
Like, it's PLS is a dual-core quotient zero.
And the PLS is a six-programbo logic Iowa modules or PIO modules.
And these are quite popular among the emters and developers.
On the things side, of course, we have an ordinary thing.
By the two-chain, the RP2040 has a standard open source quotient.
You can just download this pickle as you can from GitHub.
It's only two megabytes.
It can run everywhere.
But previously, on the outside, we have a very proprietary two-chain.
It's maybe 20 gigabytes large.
And we'll need to agree and fill out this government support approval.
It's causing problems sometimes.
But now with this open source quotient,
it's as free as the RP2040, I would say.
And we can just talk real cool and get long.
And like I've showed this very easy to use.
And the body hardware, things are complex hardware.
But I think it's mostly about the two-chain.
The two-chain is too hard to use.
So maybe that's why not so many people are using it for beginners projects.
There are quite some boards available.
We have a trust electronics, Zinc Barabai Zero.
There's this D41.
It's also has no DDR.
And this is the famous E-BAS 403.
It's a up-cycle mining rigs controller board.
So after the mining firm error have retired,
this controller board came to market at a very low price.
So maybe only 10 euro.
And many amateurs have this.
But previously, the two-chain is kind of very hard to use.
So maybe that's why many people have it.
But maybe there are a few people really use most of it.
And the body in the middle is the one I've showed just now.
And actually this PCB have only two layers.
But still have this 400-pin BGA.
It's very interesting that the signal integrity is very, very bad.
But it can still drive a BGA and like,
as to ram at over 100 negatives.
So that's the hardware part.
And about the software part actually,
I found there are some interesting things to do.
Like, when we are using the proprietary pushing,
we will just like follow the instructions.
And if they say this is impossible, maybe I'm going to try that.
Like, the Zinc boot without DDR.
I don't know how many people have done this.
But the official document said it's only possible,
like to boot from QRSPSF.
Because by loading this train to the FPGA,
we will need one single DDR mill request from like a certain memory,
holding the hobby stream through this 0x AFF address.
And if there's no DDR, then the single place we can map the whole
this premium to memory is by execution in place by QRSPSF.
But actually I found it's not really the case.
And this DDR mill request can actually be divided into many,
minus more part, like 20 kilobyte at a time.
So by this way, we can just easily load this from SD card,
using a very small amount of like buffer memory.
So of course, on this board is also this case.
The feature here is like another board is the similar thing.
And it also has no DDR.
And I can also demonstrate that if I plug in the power supply,
the build stream can be loaded and it begins blinking.
And the speed is really fast.
It's many small segments.
But there's not so much speed penalty.
And also we can overclock the zinc core.
Previously, it's done by in Libra, as the R.
But manually passing this map ready to rise.
But now in Gen Z, since these parameters are calculated from scratch,
it's just a set in one parameter and you're done.
So if you need some margin performance, it's very interesting to try.
And well, we can have more flexibility.
So like, there's a cool demo.
I put it on the YouTube.
That can be kind built a PRB stream on the zinc's arm core.
Because the pushing is very software.
It runs on arm and it requires maybe one gigabytes of memory.
And on this pink Z1 is half a gigabytes of memory.
And so I did half gigabytes of swap.
It's kind of slow, but it works.
And you can program the PR from the TS like on the fly.
And previously, it's mostly about small zinc devices.
And now, since the zinc is a kinesthetic, also supported.
In principle, the broads like this will also be supported as well.
So far, I only did blinking on this, but maybe in the future,
there can be more interesting scenes happening.
So about the future, I think it will be more free.
We have STR devices, like PLOT STR and like Open Wi-Fi.
There are STRs with zinc running in the satellites.
And I think now, this from our compiled by STU withado.
But in the future, I think maybe some of you are proud of this,
to open source pushing.
And we will have a more open infrastructure.
And of course, the pedal index is kind of a tool
for like a generator in the whole file system.
But maybe it's not so easy to use.
So it's also my plan to support this kind of generation.
So to have open source tool to replace this pedal index.
I finally, I would like to thank our net foundation and GIS zero.
And for forming this project, I would also like to thank SIMBOT.DDA
and the Open Compute project and OCP time applicant project.
And also the next user group and VLAB in the University of San San Technology of China.
So that's all of them.
Thanks.
Thank you very much.
Did you have any questions?
Yeah.
Do we have any questions?
Why didn't you use Open FPGA loader instead of a SD card
you can refresh your FPGA with FTDI?
I think the reason is, FPGA loader is used
to program the FPGA from a computer,
about to make it both from itself.
The only way is to use open FPGA loader
is to have a external MCU to beat down the jet height.
So in this case, having an SD card
is something like most traffic all the way, isn't it?
There are some SD card features
where you could say switch from this to this.
This is used by Lava.
So it would be a way to automate that.
OK, thank you.
The name is called this SD Marks.
It's there in the gun to support the ZNKB or the ZNKB.
Well, about ZNKMP, I believe the PS configuration
might be doable, but since it's also stable and so far,
as far as I know, there's no open source tool change
for office-scale fabric here,
so maybe you need to weigh some time.
OK, thank you.
As far as I know, we were to also include
debunking tools like ILA, for example, for custom logic,
and debunking custom hardware in the programming logic
by connecting the Amphrocessor via special debunking
world, so you can trigger an ILA for from the software
in the program, program-able logic, sorry.
Does do some open source tool exist to replace
that component from the Vado?
I'm sorry, but I haven't used a servicing
and probably not because when we are using open source
tool change, there will no longer be ILA.
We will be able to like hook up some custom code and monitor.
But since the tool change is being developed itself,
if something went wrong, you don't know if it's the debugger or the design
itself, so it is kind of complicated.
Thank you.
Thank you, unfortunately, year out of time for questions.