I can try this with high school, because of why?
Not to anything?
Are you press a five?
Second screen?
No, it doesn't work on my laptop.
I don't know why.
This is not on the screen, you say?
You are looping it?
Yes, so it's better when I use your laptop for presenting the slides.
And then switch when I'm at the end.
Because I want to start now.
So in the last few years I have been working on the Libre Sock FPGA prototype.
Using the orange crap and what I did is porting the existing LS2 to the orange crap
and began investigating why DRAM doesn't work.
Both the ECP5 and the IS-40 FPGAs have Libre toolshelves
and I have various FPGA ports including the orange crap which I use for Libre Sock prototyping.
And there is also a micro-word which already supports the Libre Sock.
So at the end of my presentations I might be able to do a live demo.
And like DRAM that uses the original mig but we have switched to N-mig.
So the next generation of the Milky Misc generator in that one doesn't fit into LS2.
So I was unable to rebuild the original from the micro-word
and decided that I would continue working on N-mig based DRAM.
And I found some very good bugs here.
ECP5 is big enough for prototyping the Libre Sock core
and when I started I was already able to run cold boot but there was no DRAM
so I began modifying N-mig boards and the clerser pins needed to connect.
And the reason why I am doing this is I wanted to design a GPU that is even ready for VR.
That is my motivation I have with LS2 and its current GPU needs non-free firmware
and on the long term I wanted to avoid this.
And I also mentioned that the i40 FPGA is used by Valve and Bitgrace for example in the Valve Index.
Now the question is why do we use N-mig in DRAM?
What we are using with DRAM itself is an N-mig port of Lambda Sock
and N-mig is already used by Libre Sock project and we don't want to have multiple toolkits
so everything gets ported to N-mig and we took parts of micro-word and ported them to N-mig
and the same goes for most of the other things that we want to port them to N-mig.
And the old mig which had some design weaknesses we want to avoid
and we also want to avoid LightX which provides a huge collection of libraries and even software.
And in N-mig we don't have all those features at the moment.
N-mig is much more powerful than Varylock and VHDL. Actually it is a Varylock generator
and it is much easier to use for anyone who knows Python so you don't have to learn another VHDL
if you want to contribute to Libre Sock.
And N-mig of course it works nice with Yosos, Next, PNR and GCC and all those things.
And it is also used by DRAM. DRAM is a simplified RAM controller.
It currently only supports ECP-5 but in the future we might want to support I-40 and those heavier Xilinx models
which provide even more cells so you can design more complex designs.
And I wanted to learn how to use a DRAM file that comes with the ECP-5.
I found that there was already some software hardware designs,
MicroVot that support booting Linux using the MicroVot and I wanted to do the same with the Libre Sock Core
but I didn't get there because the DRAM isn't currently working.
There are multiple generations of DRAM, for example DDR.
As DRAM interfaces DDR4 for the Power 9, DDR5 for the Power 10
and on the OrangeCrab we only have DDR3 and it is small but large enough to boot Linux.
And for the OrangeCrab pins we have Migen boards. I made the changes myself.
And the controllers that we can use are found in both DRAM and in LiteDRAM so I have compared those controllers.
They are very similar but there are changes that might be important.
And I also compared software that comes with both.
And if it does not work debugging is hard so I am going to look for ways to connect this to a host computer
and for example run software from an external emulated memory.
And here we have the ECP-5 DRAM controller.
It has high speed I.O. interfaces with many built-in blocks and one of them is the data Q-throop.
Buffer manager is a very complex module and it handles all the timings that you need for DRAM and those modules are FPGA specific.
And we have Python implementations of both files so for DRAM and for DDR and those modules are very similar.
Here is a typical module so you have to connect data lines, address lines and few address lines and clocks.
And then we have a burst-dead signal that is used for read leveling so our software checks whether this burst-dead signal is asserted.
And the data valid signal controls the DFI phases.
And on the input size we have a pause signal which we have to assert if we change the delay.
And then we use the read clock cell to set up the delay.
So only with a certain kind of delay we can get everything working properly and we have to brute force which delay is the best one.
Then we have a library called libgiram which we use to initialize this DRAM.
And here we have to provide a context and we give it some base addresses and the profile for example includes the delays.
And first we set the FITO software control then perform some init sequence.
I think that it hasn't changed.
Then we load the calibration and then we turn it back again and ideally it should work but I found out that it doesn't work that way.
The MAM test doesn't pass or it sometimes only passes for some addresses and for some addresses it doesn't pass.
So it seems that the data that I read back is corrupted.
And that is a problem related to read leveling only.
Read leveling on the ECP5 we only use read leveling and that has to be done for each file module.
And there is an inner loop for the bitflip so we do tests for different combinations.
We do a test for each read window and then try and use that returns a score and then we try to find the minimum and maximum delays.
And then we take the bitflip with the best score and in this example only one of the bitflip values works.
And the whole bitflip thing that isn't currently implemented in DRAM only in lite DRAM.
And here we can see the read leveling for both files and we see that only the first bitflip works that we have the same settings for each file and that there are three working delays.
And then we use the delay that is in the middle and once the delay is set we do a speed test that is currently not implemented but I'm going to implement that zone and then it copies the Linux kernel to the flash and then it puts into Linux.
That takes longer time because it has to be decompressed.
And then everything Linux kernel in a DRAM FS comes from the flash module that also holds the bit string for the FPGAs.
First of all the FPGAs configured.
Then I log in as root of course we don't have network that's one of the things I plan to share the BeagleBone Blacks network and then theoretically being able to SCP files to the orange grab.
But I think that will be much more work but I have a Beagle wire, a small FPGAs so one of them will be used as a debugging aid and the other one will run Leprechaun.
And I think it might be a good idea combining those because I have both boards and if I can use both for my work that seems to be a better option.
And of course if I enter arch it shows that it is a power PC architecture and so now.