All right, hello all. I am going to talk a bit about edacore, which hopefully means less work for everybody. So an introduction, who I am,

something about the idea of this, what the scope of the project is, that's very open. What I imagine are some deliverables for the first version. The concept of parameterization, which I think is an important part of this project. A bit about developer resources,

my plans for the future, and perhaps others, and some thanks. So my name is Peter Stölger. I started taking things apart when I was four, and a little bit later I managed to put some things back together, and a little bit later still I managed to build some things of my own.

And I've kept going ever since, because it's a lot of fun. I do software as well as hardware on many different levels. I have lots of register programming experience on machines from eight to 64 bits. I've also done web backend things.

I make PCBs and schematics every now and then. Nothing too fancy, but what's needed. You might have seen some, might have seen me in or around the coreboot project, libusb, osmocom, open source, gsm things,

libssh2, or perhaps gprog, lesser known but still interesting project. I'll mention that at the end if we have time. So the AdaCore idea is really simple, and I think anyone who is or has done something in this domain has already had it.

The point is we have a lot of duplicated information, a lot of duplicated data where we don't really need to. In lots of different tools, well in different tool suites to start with,

but even within a single tool suite we have perhaps different data formats for things that could actually be sharing a single data format. I want to make a part library that can do anything that the open source tools need,

and also ideally serves the industry. So anything perhaps before and after, well mostly after the design tools. I think that the AdaCore data should be usable also by the fabs.

So I'll get back to that in a bit. The killer feature of open source is really reuse. So we need to do this, I think. And I also, I mean, so show of hands, how many people have created a footprint based on a data sheet? How many of you thought that that was a bad idea

and that you shouldn't actually be, it shouldn't be necessary to do this? Yes, okay. So let's fix that and I would like to have the vendors input their information because they are producing these data sheets anyway, right? So they have this information structured somewhere. I want to import this into AdaCore

and use it and stop making these footprints on my own. This ties into, so but sometimes you don't want to use exactly what they recommend and this ties into the parameterization, which I'll get back to. Already now, so this is the first time I ever publicly mentioned this project

and it's, as it says on the bottom, this is completely vaporware at the moment, but we'll see. Still, there is one major component vendor who has said that they are willing to convert their internal data. So that's awesome. And I also got an email day before yesterday

from a tool vendor who's here and who wants to talk to me and maybe use this or maybe help work on it. I don't know. I hope we can have a chance to talk still later. A benefit of AdaCore as I see it is also that it's going to be more up to date. It is more up to date. You can do online updates and I suppose that the commercial tools do that as well,

but the open source ones don't yet so much. And versioning of the libraries, also I think important feature to keep track of what you have in your design, what you use and how things change. But yes, vaporware so far, let's see.

A question that we have to think about is what is the scope of this going to be? And my quite ambitious goal is really to go from right from the beginning to all the way to the finished product, but maybe steps, right?

So I think the first step is somewhere schematic PCB boundary or perhaps going into both of them a little bit. So something like symbols and perhaps net lists as well. But if we're doing net lists, then as we heard before, or as we know,

then this is also important for simulation. So then we suddenly have to consider one more set of requirements or specifications, needs. So far, they're all flat text, which is good in flat text in the open source tools, this is good. Verilog seems to be popular for the net list. So maybe that will simply solve itself

and Edicor won't need to deal with net lists and that will all be Verilog. It seems to be going that direction. Footprints aren't shared, aren't common. And then there's what I call parts. So that's so far my highest level concept

for the data model. So grouping symbols and footprints and lots of other things also, 3D models for a part. And so what is a, and parameterized parts. So different kinds of packages for a particular part perhaps is needed. If you have in the schematic, you want to say I'm using this circuit, this IC,

but at that point you don't care what package it is in the board layout. You do still, this needs to be the same. It is the same circuit. So for simulation, you don't want to have two different ones. You want to still have just one and the vendor will also probably only have one model for this.

So yes, need to keep this in mind and for board files and Gerber files and as it says on the end game, they're going to foundries and so on. There's a lot of geometry to consider and yes, this is also still open.

What exactly, so how much to try to do, how much can be done by a single data model. What I think should be in 1.0 is the, well, the start of a data model.

So abstracting the formats that are there so far and some kind of database implementation for this model. I envision a C library for accessing the data. So this is what application developers can use, should use to work with this data.

Nicely versioned and easy to use and with a permissive license so that it can be used really everywhere without any problems and we just get it out there. A web application I think is important for crowdsourcing data so that people on the web and at home can put their things in and we want to know if they did that so that I keep track of what I've done

and I know that that's good or bad. Parameterization, so there are a few use cases where I've, that I've come across where I'd like this to be possible. So maybe I want to adjust some drill sizes across the whole board. That's easy to do in GDA, not so easy perhaps

or less easy in KiCad, I don't know, I haven't tried it. More difficult is the second one. I want to hand solder this board so please extend all the pads outward for the packages so that I have a bit more space to work with but this is only applying to the footprint and I don't want to make a whole copy of the footprint

and mess around with that and keep two of them. It should be all associated to this one part and simulation and other use cases will add just more requirements but also more possibilities. About developers, it was said before

there are a few engineers who do both, electrical engineering and computer science. It's more and more locked into the industry, the knowledge I think, so I've heard from several academics here, please push your students to do cross-discipline things. I think this is hugely important. I also know that we have some great developers

in this room and we've already heard about two instances of sort of overlapping work with the netlists in Quacks and ngspice and gday. There are the netlists that seems to be converging on Verilog which is great. There are the board files and there's footprints

which are at the moment different in KiCad and Jida and I propose to let's do these things just once and do them right and do them together. So the project exists only with the name.

I have a bunch of domains registered and I'm setting up a track and I get there and starting to write some code. Until that's done, please come to free node and if nobody else is going to help, then I will slowly start to do this for footprints and try to use libe.core in both PCB and PCB new.

So I'd love to speak with Wayne about the footprint, what the footprint data model is in KiCad and learn about that while we're here. And that's what I have to say. So thanks for listening and thanks to the volunteers and Javier for arranging this.

C, you can, let's talk. So yes, I think metadata such as licensing, right.

Question is, will the data model include licensing information? And the answer is yes, I think that is a very important thing to include. You also asked about models, right, yes.

So this is, yeah, so some comments about licensing, how many proprietary libraries contain models

and symbols which are difficult to reuse and a comment about many JITA symbols and footprints which are licensed under GPL with an exception for commercial use or any use,

just like GCC can compile proprietary programs, right. Question?

So a comment is that many crowdsourced footprints, many people are worried about quality of crowdsourced footprints. And yes, and I'm worried about the quality

of my own footprints even. But it is a key thing to get the vendors involved in this and have them provide their footprints. And it seems like they might want to, yes.

That's a great point and a good input to consider that there are sometimes very specific requirements on footprint standards or symbol standards for that matter which need to at least be documented in the metadata so that the tools can find them

and decide whether, and the user can decide whether this is a usable piece of data or not. Why not? I think some kind of authentication of the source of,

so the question is about signing vendor data, if the vendors would be able to sign their data. And I think that's important. I think it's yes, there's some kind of certification or yes, makes sense.

So question about how to deal with many different versions of essentially the same footprint, for example, or symbol. The important thing, and the comment that it's a user interface problem, yes. The important thing is that these are all,

these should all at the very least belong to the particular circuit, the particular chip that they are for. Let's start there because at the moment they don't. At the moment it's just a flat namespace of lots of different parts and baby steps

and associating different footprints with one particular part so that at least the symbol stays the same or there are two variations of the symbol and four variations of the footprint. And I can choose which combinations I like but it's still the same logical part

is something I'm looking for. Time for one more.

I think that's a really good idea. So a comment that there's previous work and ISO standards. Certainly let's see what they've done and if it makes sense. And if it's enough,

possibly it isn't really enough for what we want to do or it's too complicated for what we want to do, then maybe we don't do that in version one. Or maybe we do. Thanks.