We will be presenting the fend room, so we will be presenting the fend room, so
we will be presenting the fend room, so we will be presenting the fend room, so we will
be presenting the fend room, so we will be presenting the fend room, so we will be
presenting the fend room, so we will be presenting the fend room, so we will be
presenting the fend room, so we will be presenting the fend room, so we will be presenting the fend
room, so we will be presenting the fend room, so we will be presenting the fend
room, so we will be presenting the fend room, so we will be presenting the fend room,
so we will be presenting the fend room, so we will be presenting the fend room, so we
will be presenting the fend room, so we will be presenting the fend room, so we will
be presenting the fend room, so we will be presenting the fend room, so we will be
and then we will be getting into some more detail as much as possible in this short
time of the three main components that we are working on here, and then we will
have some outro in the end, so fend rooms is a research project funded by the
German government, it is part of a wider effort to secure the technological
sovereignty, the consortium working on this consists of Farouff
to the government, where I am working at T. Hakurne, the vast end of the
room, and the universities in FNW, we also have an industry partner, which is the
Koulon chip argument, and so the basic motivation behind the project was that
there are some issues with the way a proprietary FBGA designs software
works nowadays, so most of you probably know from the big vendors like
signings, letters, or they have their own software suite where everything is
funded together, and we identified the issues several, but the main ones
were for FBGA vendors, or potential vendors, the issue is that you cannot
just get into the market with your FBGA, you also need to deliver a software suite,
which is of course a very big hurdle, and from the user perspective,
they can run into the problem that if you have designed your workflows around
one vendor's software suite, you might find yourself in the difficult position
if you decide to change to somebody else's device. So the idea is that by having
an open source vendor independent design software, we can potentially support
anyone who would like to be supported by the software, and they can also
add this support themselves if they desire that, and from the user perspective
again, we have the idea of one software that can be used with any device.
So how that's supposed to be achieved, the first step here is to have an open source
IDE that has some helpful tools, which other IDEs also have, so we're focusing on
three aspects, one is the design of systems and programmable chip,
the other is visualization and simulation of designs, and then also the topic of AI
acceleration is relevant here, which we are exploring with a specific example.
We are also pretty early on in the project, we decided to cooperate with a
German startup company called OneWare, who are already working on a
free open source IDE for FPGA design, which is called OneWare Studio, and we thought
it was a really good fit because the general approach is based on implementing
third party tools together, and so we're just creating additional tools that
can be integrated into the software, and we're also working with them to
implement the whole system. So now I'll be getting into the system
builder, which is my primary responsibility. So the concept is pretty simple.
We want a GUI-based tool that can assist in system
programmable chip design, and the idea is that it is both an easy
starting point for beginners, but also convenient tool for experienced users, which
is not always easy to achieve, but we hope we can get there.
And so the main function of this is to create what we refer to as a base
policy, so the basic central piece of the SOC would be, of course, a
CPU, and bus, faster, and aberration logic on all that, and maybe
some simple peripherals. And what this system builder is supposed to allow you to
is to on one side configure that base system, and then define the interfaces
to any additional modules you have in very long.
And another aspect is that we, of course, want to automate as many
dam labor tasks as possible, so anything that can be easily
automated, we try to do that. So how we're going to going about this is
that we're basing this on the very useful open source framework for
light decks, which is already very powerful tool for a system on
programmable chip design. It's a Python tool kit, based around one of these
more high level hardware description languages called mygen, and it also
comes with a whole range of IP calls already prepared. So how we're doing this is
that we have a two parts software, so we have the GUI component, which is
made with the Evalonia framework in C-sharp, for integration into the
one-way studio, and then we have a Python interest script interface script, which
incorporates this configuration file, and then uses lightix to generate
the system based on that. And as I already said, the focus right now is
on interfaces between the base system and external components. So within
very lot, it's all within the same IPGA, but it's separated in that way.
So we also want to make as much of the lightix features available, because
it's not necessarily straightforward to access everything, especially in a
generic kind of fashion. And we want to keep the interface as simple as
possible, so we don't confuse anyone or waste resources. So this is
some screenshots of our prototype. It's very there, but once at this point,
so you have basically one main configuration where you configure your
system, you can choose which kind of CPU you want. You can tweak the
bus system, which then actually want to use the switchbone option,
there's the option to use Axi, and potentially even more
standards might be integrated in the future. And then we have this
other tab here called top modules, which is where you have your own
very long modules. You can read in the interfaces and the
parameters and all that, and then define how you want to connect everything.
And what the thing also does is that it generates the top level of
the very local wrapper for you. So the current status on that is that
we have this first functional prototype of which I just showed some
pictures, and we're working on extending and improving the
functionalities. So obviously there's a lot of, this is just working
progress already still. And we're trying to improve that and
also enable more of the lightx functionality. And what's now a
current topic is support for the open i accelerator, which will
also be presented in this top later. So with that I'll give
over to Sebastian, who will tell you about this thing.
Great. Thank you as a friend for the brief introduction.
I'm presenting, I'm with the University of Applied Science
Colone and the flagship plug-in for one of the studio from us.
It's the netless viewer. It shows module instances,
interconnections and hierarchy of entities from your designs from
VHGL or Barrylock. And it can also do a primitive visualization
after the synthesis. You can see a 16 bit processor at the
wide, at later, this light will be a bigger picture of it, but it's
very useful for debugging or understanding from
XSPCs and teaching and onboarding. Currently, we are using
this tool in basic module on our university. Here is the
16 bit processor. Again, a little bit bigger. We did not choose
to use. It was 5-1 because Benu can't see anything. It's
like a FPGA, 80% of the elements of the area, because for
the routing. You can see the standard OSS of
PGA to change the quality supporting in one studio or with
our plug-in. The standard simulation is way to
use it. It's with users or with a GL. Plug-in
itself with users. And then you go from GL to GL.
If you have VHGL code, you simulate the GL. And if you
have Barrylock, you can simulate it with each of those
very log. And show them in a way from where
you are already included in one studio. And now
our plug-in fills the gap where you can visualize the
your design from the different steps. It's like
very useful for debugging your own code.
The current features that are supported is it's
interactive so you can zoom in. You can zoom out. You can
zoom out and collect the entities itself. So if you
have a very large design, you have only the
top level elements that you can see. And you can also
jump back to your HDA code itself. So if you want to
see where your max is implemented, you can jump back in
the design code. This is only working if you use it
use it as the plug-in is intended in one of the studio
and currently under development is displaying
the simulation result in the latest view
so it can go from a simulation to the viewer itself
and then jump back in your code
if you want to fix some bugs or explain something.
Here, a brief overview about one of the studio.
Again, I've seen already mentioned open source plug-in
based for FPGA and the better design.
It's focused on lose integration
so if you want to integrate your own tool
or something else in this very good documentation
not quite, but a very useful guide
that you can integrate your tool in it
and this unified environment for a specific design,
tool to integration visualization and analysis
and tool to also be used as standard low
so you don't have to, you don't fix in the visual environment
so you can do it like the other shell.
And now we are coming to dance.
Thanks a lot, sir.
You can use it.
I know it's very good.
Well, we have now two projects I've featured about a simple problem
I'll leave it 100 but easily just 100 and a half x and a half x and a half x and a half x.
I'm muted.
So I'm muted the bug.
So, can you have muted the bug?
Let's just do an example.
We have more development and a half x and a half x and a half y.
Networks?
Because what's a prerequisite?
We need a scalable open source hardware accelerator
and the problem currently is there are no fully scalable open source hardware accelerators available.
So, if it was like the another problem, we have to develop our own.
We have given requirements and of course the support of multiple different newer network layers
like convolution, dance, pooling, everything in it.
And at the state of the art, we want also to support
the embedded AI concept that are currently researched.
So, use of sparsity, redundancy, reusability and also the SIMD flow.
Single-straction multiple data in one process element.
To realize the scalability, we used a higher-code structure
so to you can use maximize the utilization and a higher-code buff ring.
Also, we used the scalability to later on try test on a design space exploration
to explore on how good is our performance by using different operators
of maybe using more process elements or maybe using more RAM
and then of the routing process to connect them.
So, the question is, how good can we get the hardware for a given net?
To visualize it a bit more, understandingly, you have a problem
and for the problem, you have two versions, either you solve it
or you will get it solved, like using tens of flow on an NX model
from artificial intelligence.
And from there, you generate a neural net.
We call it just an NM.
After that, we will put it in in our
right-tune framework that will just try to optimize
and find good parameters.
If it finds a good parameter set, it will try out
on the synthesis and routing and simulation by giving the synthesis and routing
the hardware parameters and the simulation
have the parameters and the neural network.
From there, two things will be calculated.
On one side, the resource usage is giving how many
look-up tables do we need, how many block RAMs do we need
and on the other hand, we need a time and usage of post-element
so we can actually calculate what is the percentage of use hardware materials.
This will iterate about multiple iterations
and after that, the data is get saved and can be plotted.
So if you like that interest, okay, is there maybe a peak
and energy consumption somewhere?
Well, it would lay the peak or is there maybe
some value that you can utilize, some effects on.
If we look at the open-eye-hide structure,
it's mostly the structure that's given of the
Iris version two model, so it's also like the
stationery data flow and consists of a control
logic on the top left.
The parallel open-eye, which can be also used to perform
in an asic implementation and some configurable RAMs
that have like the current information of the whole layer
start, so it can be accessed.
Now another problem at the scalability is that you have
if you try to scale it up, that you're routing
costs increase increase increase exponentially.
We solved this problem on the Iris file two version
by only locally connecting each open-eye cluster
to another cluster and can be variable connected up.
So they can be connected and therefore the router
performance increases.
Looking ahead, the project is still in an early
and a voting stage and we invite you all to test
and challenge the software.
Currently, there is an open source project and you can
inspect and modify the code.
You can also contribute improvements and
your own ideas, or maybe your own nets, or
your own features you want.
Well, in this case, then join us in shaping an open
vendor independent FPGA ecosystem.
We are just in two slides come to the repositories.
But first we have always to display that this is a
Fentrums project.
So we are funded by the German Federation Ministry of Research
and we are currently in space, BMFTR,
and this given research number if someone can now
take a photo once, you can take a photo.
Otherwise, we have also the project and the
GitHub and we are currently now also starting on
CodeBurke.
So if you feel any questions, feel free to ask
if you have anything you want to know.
And I would like to ask about the routing
complexity specifically.
Is there any tools that allow me to take some of the
complexity on to yourself?
As in mining the rounds, the connections
in various logical elements.
Is there a commitment to the code itself
that in the total time of the year before you?
So, for my part, I just want to
know that there are a lot of parts.
So there is like the given complexity of that.
If you mean like something like an
LXP in our routing, I would give to my colleagues
with question.
If you feel something more like this.
I don't know either.
But you can place some parameters in
NXP.
So you have kind of handling.
What's the routing?
I was thinking about latency.
Reviews of latency between specific logical components
of the language.
You.
The question is about latency minimization
from different components.
I think you can flop land it.
But you can't root yourself.
You can't say which switch box you want to use
or something like this.
Actually, just for the case of our test study case,
we had the route test.
And also, we had like some delay elements in it
that you can freely enable and disable.
By using this elements, you can try to achieve
over learning the architecture.
To increase the maximum speed or maximum clock
we can see if you mean something like going
this on the very log face.
Can you repeat the question?
Oh.
Sorry.
He was just asking if we can choose some integers and switch
up.
We have like some attributes, some defined.
And we can also like have a specified defined
of putting every route to stage.
A separate flip flop.
So it gets like one clock cycle more storaged.
Yes?
Yeah.
So.
Correct.
Yeah.
Put that out of the platform.
We're putting all these tools together.
How to split up double these your system.
How to screen?
So if I want to drive this externally,
like by now, you visual work to help split
up.
It's very scripted because I'm using currently.
Okay.
I'm just being the question was asked.
How scripted by this is from a user experience.
If you want to script it without a GUI.
Is it your question?
So to answer this question, the part of your heart
accelerator is mostly done without a GUI.
So this is just you put on your very later or equals very
long.
And then you just put in the heart that parameters.
You start it and then it generates your version of the heart
accelerator for your points.
Maybe you want to answer the question.
It's scriptable too because we're the underlying tools.
All CLI tools.
So we are only building a visualization on top of the CLI tools.
So you can use them if you're professional.
But for educational use, it's easier to show new students in IDE instead
of the heartbreak with the fashion already included.
Oh, sorry.
Maybe I can expand on that.
I think if you're asking about the whole tool chain as a whole,
is that correct?
That's not really a primary target audience.
So because most of these tools that we're utilizing,
they already have that as was already mentioned.
So we're mostly focused on the essentially quality of life
for the people who have some issues with scripting everything.
That's more of a purpose here.
Mine was more of a certain amount of things.
Like, do you get more of a problem?
Do you have a lot of media interface,
but do you think what's more of a challenge?
Yeah.
So the question was about,
wait, what was the question?
Yeah.
It was about managing the whole tool flow as one.
We haven't really spent all too much thought on that at the moment.
This is certainly something we would take a look at.
So maybe if you could send us some information about what you're exactly thinking about,
we can certainly try to incorporate elements of that if that seems reasonable.
My question is about your netless gear.
That's the first one to follow up.
It sounds like it's just a really only type tool right from the netless.
You currently, the question is,
the question is, then your netless gear is a really only tool at the moment.
Is that right?
The question is, the netless gear has to reach out to it.
Yes, it's only, it aimed dozens of,
but did you expect to be a, it's a view?
This is an expectation that I have to mention here that they want to wipe that.
Yes, but they request that you be able to edit from that as well,
and it will put you in the there along.
Maybe that's a really like question.
I understand that it's not exactly right.
You're all totally.
But there is a art to the complexity of the top level of wire management.
And we have lots of wires to see if we get this or this busted, you know?
And so having a visual tool to see how that connects together in a schematic,
like that goes on people a lot.
So I'm wondering if you get that sort of question.
The question is to make the netless gear interactive,
so you can connect parts of the top level entities with a wagon drop tool.
With some kind of visualization.
Yeah, it's like something you can scroll around in or is it just a picture?
It's something you can scroll around with,
you can collapse the entities or you can hide them at all.
I think you can hide them.
Two bookbath.
It's only visual, but he is working on something.
No?
Okay.
Sorry.
He isn't.
So the answer is no one's ever requested that.
Well, maybe that was what I was going to talk about.
We have considered that.
And we found that it's not easy to do well.
So we haven't necessarily put it on the top of the priority list.
So we would be happy to, at some point, get there,
but it's not really something that we're prioritizing at the moment.
What difficulties did you run into there?
What?
Can you say a part of the answers?
So we have some things.
For example, we have different stages in the design.
Oh yeah.
The question was what specific difficulties we encountered.
So we have certain design stages.
So for example, if you just have a very low code that you're visualizing,
it's relatively straightforward to go back to the very low code.
It's a bit more difficult if you have, for example, synthesized or implemented design.
And you make a change there, then you also need to log that somehow.
And how do you get back to reflect that in the original source?
So that might be an issue.
And we haven't really found a good solution that really satisfied us.
And as I said, we didn't prioritize it necessarily.
So if anybody has a great idea, feel free to share.
So do we start from the net list or do we start from the very low?
Yes.
Because the net list viewer internal uses users to produce a hierarchy, the net list.
And this net list, we are using for the visualization.
So yes.
I could plan something by any visitor or something.
Some of the, some of the more complex.
We have, like, a lot of stuff you think of here.
And if I go ahead and stuff you have, for example, the developer and all this.
Since no one wants to use by hand.
And but maybe it was that much fun.
Especially if you are, you know, that is something.
So the question is, whether we are planning on adding some sort of IP wizard that allows configuration with a simple interface.
And you're the answer is yes.
We haven't gotten to that yet, but that is certainly on your agenda.
You mentioned we have a lot of work on buildup.
And is it somehow planned to make it possible to have design partitions and lot of these partitions and visualize a thing of different areas of the network here?
The question is, it's the plan to use a floor plan visualization tool to create one.
It isn't in this tool because this tool is only for the net list.
And the floor planning is something you can do in the later stage.
But it's an open feature.
I invite you to make this purpose.
So questions.
Thank you very much.