Alright, hello everyone. You can hear me in the back. I'm Peter Clifton. I've been working on the JEDA project for a little while now, and I'm going to give you a brief introduction to the talk. I'm going to try and make this a little bit interactive, so I'm going

to start by making you all do some work. I want a show of hands for who actually has tried the JEDA project, any of the tools within that suite. Okay, that's a good proportion of the room, and who actually tried it a second time after the first. That's fortunately most of the same hands, and I see someone working on a project right there

in the audience, so that's a good start. If the Wi-Fi is good enough, we can probably get you downloading it and starting on some projects while we're talking. So JEDA, I'm not sure who switched on. Okay, I'll speak louder. If you talk to

the Americans who founded the project, you would be calling it the JEDA project, and perhaps in keeping with KiCad, I'm going to call it JEDA, as it was intended by its founders. Now, JEDA represents a mature suite of electronic design tools. It's

been going around for a long time now. The project was founded back in 1996 and was developed according to the Unix philosophy, which is, depending on who you talk to, well, in this case, command line driven. Actually, no, it's not that. It is

having tools which are good at a particular task. So in this case, we're trying to keep each tool separate and good at one job. Found in 1998, so I wanted to address the lack of free and open source tools in the electronics

arena. So Alis Hvesda wanted to do some electronics, and he wanted to do that in a way which was on a Linux POSIX platform. And when he looked around, there wasn't a set of tools to do that, so he started about writing it. My first involvement actually writing code for the project was in 2006, some

years later, and that was funded through a project set up at the University of Cambridge, which was to improve the tools they were using at the time to run student robotics projects. And one of the academics there actually funded a couple of placements, myself and Peter Brett in the audience here, started

hacking on the tools we'd been previously using and trying to improve them. Jida Project is an umbrella. Various different code bases and projects would call themselves part of the Jida umbrella. But primarily when we talk Jida, we are referring to Jida GAF, which is G-Skim and Friends, so the

schematic capture, netlister, and associated pieces of software. And according to the Unix philosophy, and we've got these little tools which are separate and do individual things, we don't prescribe a particular workflow for our users, so the tools are quite versatile in the way you can actually

employ them. Which naturally means they're not particularly well integrated, so maybe as a downside, you've not got a single IDE where we can execute an entire design flow. Probably the most common workflow in use of Jida tools is producing circuit boards, and seeing people in the audience, I could have

probably picked on various different projects, and I know there are people in the audience who do use Jida to produce actual circuit boards, and if you look there, Bdell, yeah, actual proof that we can produce real hardware. So what kind of tools in the Jida suite are you going to be using?

G-Skim is our schematic capture package, and from there we also maybe need to enter some component data, some attributes, values, what sort of resistance you're fitting, part numbers, and we have a spreadsheet-like tool that allows you to edit that on a bulk basis, so I can draw my circuit, and then after the

fact I can go in and look at the part numbers I'm going to use and enter that data. We have a netlist tool. Schematic is only really very good if you're documenting a design, but if you're actually wanting to use it for simulation or to drive a PCB workflow, you're going to need a machine-readable

format, so you need to extract a netlist from that schematic, and we have a separate program which is command-line based, which can process the G-Skim schematic, and it will then allow us to write a netlist in various different formats, including some proprietary formats.

There's the tool GAF. GAF, as I said before, stands for G-Skim and Friends. GAF sort of encompasses a name for that code base, and that was a tool written by Preeta Brett here, and is used for command-line scripting of things like exports. So if you wanted to write a makefile that takes your schematics, turns them into PDFs,

concatenates those PDFs, you would use the GAF tool in order to generate the data you start with there. G-Skim to PCB. Okay, we need a bit of integration, all these separate tools. So we've got a command-line tool there, which has existed for a long time, and allows you some sort of automation

when you have a schematic and you want to take the components that are embodied in that schematic and ensure you have the correct footprints and netlists in your PCB editor that you can create the suitable board layout. X, G-Skim to PCB. One of the things that university has feedback from its students was,

ugh, command-line. So as part of the project we did in the summer with the project with the university, we developed a small PyGTK GUI that effectively wraps G-Skim to PCB,

and it gives you a few boxes. You can click and you can open your schematic editor and you can click and it runs the update process. I use it. I find it's actually quite a convenient way of remembering which schematics go into my project, and I can access all the tools from one kind of place. And we've got, of course, a board layout package now.

That's a different code base, and we'll move on to that shortly. Gerbvie. Gerbvie, obviously at the end of your PCB layout escapades you probably want to actually produce a circuit board, and to do that you need manufacturing data. But you'd be foolhardy to do that without at least checking the manufacturing data looks correct, especially

with some of our code branches. So looking at the tools, we've probably got at least four code bases there. There's the JEDA GAFT, he's given friends, there's only one repository, the blue tools at the top, and they're all built using auto tools in one hit.

XGCIM to PCB, it sits in its own repository, it also hosts on the project website. PCB, its own code base, and Gerbvie hosts on SourceForge. JEDA GAFT is also used though for other workflows than PCB design. We've got guys who use it

for making ASICs, flying in space missions. We use it, I use it for driving netlists for producing simulations, so we can target either a spice based format or a structural Verilog type format if we have Verilog simulation models. And basically I'm documenting

a schematic format that drives my netlist, and if I get really diving into the details we write the netlist by hand, but you can use the schematic tool for drawing almost anything. Cable harness design, I know people use it for hydraulic systems in oil installations, and some people use it for general drawing, it's not a bad drawing package, it's not Inkscape, but

it kind of does what it does. And numerous applications we don't know about, we have no way to really know exactly what people use this for, because a lot of the time it's used in situations where people aren't publicizing what they're doing because they're using it within corporate entities. G-SKIM, our schematic editor, is effectively a drawing package.

It draws lines and has a little feature for putting macros in, which we call symbols, which is your representations of resistors, capacitors, IC chips. It has a few little tricks that helps you draw schematics in a way we can process, for example it has a concept

of attributes, name equals value, they're text objects which are attached to instantiations of components, but at the end of the day these are text on the schematic page. Probably ought to have had a picture by now. Here is what G-SKIM looks like, I think that reflects what you would

find if you downloaded Git Head. It's rendered with Cairo, so the font rendering is nicer than it originally was, and mostly you'll find that on Linux platforms. You can build it for Windows, and I think there was some work to have a nightly build of the tools, whether that's still current or not I'm slightly less familiar with. Some specialist EDA primitives though, aside from the

lines we have a special type of line which is net, and that is a line which the netlister will go and look at and try and track connectivity for, and we look at where the nets connect and land on schematic ends, so on symbol ends we have pins, and that's how we look at extracting

a netlist from the tools. Buses, another type of specialist line, although in fact the case of bus is more a graphical line, we don't actually at the current state of JEDA process the connectivity of a bus in terms of the signals within it, it's more a construct that you draw on

the schematic and you actually name the individual signals when you pull them out of the bus. In addition to having some EDA specific primitives like nets and buses, there are also some attributes you might find attached to components that G-SKIM understands, for example a source equals

attribute attached to a schematic symbol will tell that tool that the symbol represents a sub-circuit and we can descend into that from within the GUI, but effectively the actual elaboration of the circuit and the netlist is done at netlist time. So G-SKIM is a drawing

package, now some would argue that is a design choice and is a strength of the project, and some, I think myself included, would say it leads to certain weaknesses at the end of the sort of development we've got to where we'd like to start adding features which require the schematic editor to understand that the thing your mouse is pointing out in fact connects

to a particular net and when we're cross probing from a PCB tool we can track back connectivity between the two packages. So strength or weakness or deliberate design decision, well jury may be out on that one. Geotrib tool I'll touch on briefly is a tool for editing of bulk

attributes, anyone's used any proprietary tools you'll find probably the workflow involves click on a component, right click properties, edit something, modal dialogue usually, okay, and that repeats for every component you have to edit. Now a lot of the work we've done on the user interface in G-SKIM has made dialogues non-modal and our attributes pane can operate

on any sort of components you've got selected and Geotrib goes a step further as you can view all of the attributes and properties for all of the components in your schematic in one hit and it looks a little like a spreadsheet and an old spreadsheet at that. G-NET list is

obviously a critical part of the tool, up to this point we've got pretty graphics in a file format that you won't read in Inkscape. G-NET list is a tool for extracting useful information from our schematics. It's written in a mixture of C and guile scheme to make sure no one can contribute to it

and netlist in over 20 different formats with a lot of other backends that target things like design rule checking and utilities like dependency generation. So for example you can run a G-NET list backend that effectively emits a make depends so I can find out that my master level dot schematic also depends on level two dot schematic and

resistor dot symbol. Worth probably mentioning there are netlist formats backends for commercial tools as well as open source tools. I think we're missing a keycard one which would be

something which we could easily implement. Simulation targets I mentioned before I personally use Jetta as a front end for simulation more often than not. There are backends which try and elaborate the schematic in a way that can be fed to SPICE. Now

a lot of people were in the SPICE talks and the simulation talks earlier touched upon the fact that SPICE syntax is a little bit obscure and has certain requirements like a resistor needs to begin with the letter R and a capacitor needs to begin with the letter C. So the SPICE backend does a little bit of mapping behind the scenes to make sure your component names try and match

legal SPICE syntax and you might have a fighting chance of getting a netlist out that will simulate without too much hand editing. If you're targeting GnuCAP what you want is Verilog, structural subset of Verilog which is used to connect up the different models. GnuCAP has the inbuilt models, the behavioral models that you'll actually be using for the simulation

but you hook them up with structural Verilog. And the final one is one I've not had a chance to try but one of our users, one of our long-standing users, has written a Mathematica backend which allows him to turn a circuit into a mathematical definition and then work from there

to extract both symbolic and analytical analysis of his designs and perform numerical simulation in Mathematica. I think that's a very powerful tool when he's designing ASICs. Combine line tool, I'm afraid this is a little bit out of date, I haven't updated

for the modern way of doing it but there was a project that Jetta and PCB undertook with the Linux fund where we raised some cash and funded a developer to improve the translation between the schematic side and the PCB tool. And PCB now has the capability of directly reading in a

netlist emitted by a gnetlist backend that's targeting that particular workflow. So gskim2 PCB you might be familiar with if you use the Jetta tools, consists of a command line program you run on your schematic and it will cross check against your layout and look for any components that

have changed value or that you've added to the schematic or you've removed from the schematic and then just need updating in the PCB. And the GUI, everyone likes a GUI right? It's a little box, lists all the files that you're going to process to create your netlist and it notices when you hover over the window if you've touched one of those schematics and the PCB file date is older.

So it's a poor man's make but we did find it was quite a useful step in encouraging new users who perhaps weren't so familiar with the command line and if no one tries your product because they're put off initially, you don't get very many users. If you can at least entice people in they learn the benefits and maybe eventually will be weaned onto the more advanced ways of

using tools then you keep users in the user base. PCB, it features a DRC check gridless auto router as an experimental topological auto router which I probably wouldn't recommend using for anything other than small one two layer boards. One thing which perhaps keeps it distinct from

commercial packages I've used is you can basically draw things similar to gskim. It is a drawing package. You draw lines on layers and connectivity is then checked after the fact. Some tools I've used commercially will insist that you can't draw a line unless

you're clicking on a pin and it knows there should be a net which can be quite constraining if you're used to a package which is able to let you draw what you mean and then check up the connectivity afterwards. This is what PCB looks like. Again, should

reflect what is in the upstream repository Git head, 2D view and the little sphere underneath that. That's a 3D sort of trackball type control. Doesn't particularly give you a 3D view at the moment but does let you put some perspective on the board and a lot of people whilst they

say that yeah that's a toy feature and we haven't got proper 3D there I personally find that by rotating the board around I can really visualize what I'm going to end up with as a product even if that is just a flat circuit board and the later talk on 3D shows where that may be heading and what we will do with 3D if we get the time and developer input to achieve that.

PCB has multiple front ends. It's a separate code base to Gita and has a completely different internal structure. Front ends we have, we've got a Lestif front end which was written by DJ Delorey and works

upon the older X11 based front ends that use the Motive toolkit I think and probably before that the Athena Widgets toolkit and is a very traditional sort of Unix-y high performance, no frills, no GTK front end and a lot of people quite like that. Our standard build uses GTK which is what I would tend to use and that is built with

either a GL renderer which I wrote or a legacy GTK renderer if you haven't got GL support on your machine and whilst we're saying GUI's batch GUI is the command line GUI which would just make PCB a command line program and from within that you can load boards and export

to the various manufacturing formats we support. GTK GUI can be compiled for Windows and I use that from time to time at work. Using the same APIs as the GUI front ends we also have a series of exporter plugins and obviously the usual suspects are there. We can do Gerber RS-274X,

we can emit PNG graphics either of the individual layer, geometries rendered as lines or a more photorealistic output which can be useful for again visualising what you're going to end up with when you've found your board. We have postscript output for documentation,

EPS again more an image format like PNG in that case but there are some specialist backends there which are some targeting CAM workflows so G-code. One of our users wrote a back end which actually targets routers so if you've got a XY table and a router bit you can either

do isolation milling or perhaps just use it for milling holes. Experimental code there exists for exporting 3D models of the board at the moment just the board so we've got an interesting shape rectangular board you'll get a rectangle out in a 3D world or cuboid but when you start putting cutouts in your boards you start using complicated shapes that need to fit into a

board. In case works the ability to export a 3D model is critical nowadays if you're trying to do product design and development. GERBVY I believe is quite extensively used it's got

complete support for the RS-274X standard and I believe it's faithful to that standard so if GERBVY says it looks like this particular picture on screen that should be what your manufacturer produces and you have a reasonable degree of confidence that's going to be the case. Again separate code base from PCB and JITA potentially it would be something that we

would like to integrate parts of GERBVY which is actually coded as a library libGERBVY and would allow us perhaps to import GERBVY data into PCB for use in a sort of editing workflow where you might choose to panelize a board. That's future pie in the sky

sort of talk but occasionally you come across the requirement where you say oh I've got this existing data it came from ORCAD Altium I want to move on from there but what I really like to do is for example export import sorry the outline layer from that old design and make sure

my new board matches that same physical footprint so that's a potential future project for some contributor who either wants to work with GERBVY and export PCB files or wants to work with PCB and integrate libGERBVY and we have a whole host of other tools if you install JITA your bin folder

if you have a separate one as I do you'll find quite a handful of little binary tools for reading obsolete formats that no one's used for 10 years mostly for renumbering schematics again separate tools there exist for refactoring your schematics and saying I want to duplicate this page and I want everything I've got on my master page to be plus 100 on the ref desk

plus 200 on the ref desk and we can make duplicate schematics that way and some of the projects I've done with circuits where I've used hierarchical blocks I've actually used a renumbering system there so we start with a master schematic and you repeat that layout eight times in a

makefile with updated ref desk a little bit of makefile knowledge goes a long way if you're one of the core choices that the GEDA project made is that we're not trying to force you to do something a particular way that may be a off-putting feature to some people but

hey there are other tools out there and one of the comments I'll sometimes make to people if they're complaining too much is oh hey there are other great open source tools out there and we point them in the direction of KiCad and for some people that's a better fit for what they want and for us you know sometimes if you're targeting multiple workflows or you want to hit simulation as well as board layout then just having a schematic capture package which

targets schematic capture and necklace extraction might be the better choice for you file formats again another fairly core feature that people regard in the GEDA project as a design feature was our file formats are ASCII based UTF-8 mainly because I can say that probably weren't UTF-8 when

they were intended but it allows people to to then adopt things like sed and grep as part of their tool chain perhaps in some respects it weakens the position we have in terms of representing embedded graphics we tend to base64 encode any embedded graphics we put in the files

but it does give us some some flexibility when people actually go into the schematics and say well I want to put that via or the track at some exact location downsides again as I said embedding of graphics and sometimes you might for example value being able to say this is my

schematic file here you go it's one file in which case a container-based format might be more flexible and you can you can say this is my schematic file inside is a zip full of full of folders so potentially in the future I would like to see an extension to gskim support where we can actually say you've got an alternative here's a zip file which is a schematic or here's

a folder structure which is your schematic and associated files but that's all in the future future for gda is kind of unknown at the moment we've got a couple of developers working on gdaaf I haven't been really actively involved in development of the project for a couple of years now and that's based on the fact that it really kind of does what I need

and you know life gets in the way you mature and you find you know things like working for a living get in the way when you're a phd student you know you've got all the time in the world yeah not that I ever finished my phd but uh maybe maybe gda had something to do with that I blame gda so I'd like to see us refactor a few things in the future and possibly split

out some libraries so that we can we can use the the core netlisting functionality from from more projects and from what I'm seeing with the simulation guys I think a netlist library that supports common netlist formats would be a good thing for the community to have and to have as a core library some of the things I would perhaps envisage in my ideal package

wouldn't fit with the gda philosophy so either would be a separate project or maybe the stewardship of the project in the future just takes it in a different direction we really don't know at this stage thank you and as someone pointed out where do I get gda take a look at our website www.gda-project.org and if the site seems to be down you could probably bet there's been a

hurricane in new hampshire excellent apparently there are packages that are really current in

Debian and all of its derivatives this is kind of one of the things we've had an issue with in the past is that the limited amount of developer effort we've had means that we try and spend our

time writing code and less time making releases and packaging code which is probably detrimental to the project if you want the latest feature set you're gonna have to build that from the git repository because we haven't got our backsides and actually released a tarball that is probably one of our weaknesses as a project we don't release often enough that that's probably a good

thing to do and I think I think for a while the reason for that is we reached 1.99 as a version number and no one really knew where we were going to go next okay so the question the question

was where is the source code actually hosted if you go to www.gda-project.org you have a now gda-gaf and pcb and xgskim to pcb are in three git repositories which are hosted on the

same server that hosts that website which is up in new hampshire gerbv hosted source code on sourceforge and all of the projects there in git are there any plans for linking I was

paraphrasing the question but are there any questions are there any plans to link the schematic tool and the pcb tool in with view to sort of cross probing between them I think the plans exist in that we all agree it's a very nice thing we would like to do at one point there

was a gskim plugin written in scheme that would allow you to sort of get a net name from something you clicked on and to poke that at pcb and say please highlight that net but fundamentally it relies on maybe having one schematic and the net name that is in that

schematic being the correct net name by the time it got to pcb which is not necessarily the case in the in general because you might have a hierarchy of schematics and the schematic you're actually working on in the schematic editor could be three levels deep into into a hierarchy and the net name within that may well be not be unique within the design so in order to do

it properly I think we need a concept of connectivity that is that is kind of live so a live database that understands this design is open and it starts at this root schematic so if I'm within the hierarchy I know where I am within that hierarchy