Hi,
I’Am new to the forum here.
A nice idea is adding an simulator in the schematic editor.
GnuCap is an open source simulator.
There are some simulation schematics examples
Unfortunately they cannot make a pcb
qucs
qucs-s
https://ra3xdh.github.io/
SimulIDE
Real Time Electronic Circuit Simulator. With PIC, AVR and Arduino simulation.
Greatings,
Erik
www.myhdl.org is also something to look at. It makes it possible to simulate HDL designs that can generate Verilog and VHDL.
And when thinking about FPGA, https://symbiflow.github.io/ is good to also look at, as SymbiFlow is the standard for fully open source toolchain for FPGA’s.
MAME can also be something to look at, as it has a huge range of emulators for different CPU’s https://github.com/mamedev/mame/tree/master/src/devices/cpu
…that uses a common standard for communication.
@ubruhin Are there any plans to implement this?
Ps: Greetings from a former Sensirion Praktikant.
Hey @SebastianJL 
Unfortunately no, there are no plans to implement this in the near future (too many other things to do first)…
Not much has happened in this thread for a while, and little has happened elsewhere.
We are working on an IEEE 1364-2005 compliant interchange format for schematic/pcb/layout [1]. Supporting it will give access to simulation, timing analysis, signal integrity and other tools in a straightforward way without the emphasis on lock-in.
LibrePCB should support the format. Icarus-Verilog essentially does and Gnucap is very close. The Gnucap project has funding ready for an ambitious intern (thanks to NLnet).
Thanks for the hint @felix. Glad to hear you got funding from NLnet 
Unfortunately Simulation is still not a high priority for LibrePCB. Still a lot of other things to do… But of course I keep an eye on this and I really hope some day we can work on this topic.
Hi Urban.
This is not a feature request.
The tight integration into LibrePCB that you might have in mind can wait. Tools with lock-in already exist, and there is no need to compete and play catch-up.
The relevant goal is standardisation, because it will help decouple projects and developers time, simulation is just one application of many. I understand that you are busy, and we are, too.
For a start we’d need someone with the ability to understand the problem, willing to work in between projects, and accept help (and funding).
Best wishes
Ah maybe I misunderstood your previous post. I thought you are working on standardization by yourself, not asking for help on this.
To be honest, I have very very few experience and knowledge about simulation and especially about the technical aspects of it. I already read your page File format translation two times and I’m still confused. Thus I doubt to be the right person to help in standardization – I’d first need a lot of time to dive into this topic.
Maybe I could somehow contribute to this topic only from the EDA tool perspective. But for that I first need a clear idea what expectations you have on the EDA tool. What is the overall goal, how does the workflow look like, what are the interfaces between EDA tool & simulator etc.
Also note that I still struggle with the idea that simulation models are expected to be provided by the simulator (if I understood you correctly at FOSDEM). From the EDA tool perspective I expect that models are provided by the EDA tool (typically stored in the EDA project, like any schematic symbols, footprints etc.) and passed to the simulator. If the simulator provides the models, we have several problems:
i can’t estimate yet if it is feasible or not to store simulation models in our own libraries. If it’s not feasible or even impossible, maybe you need to explain me why 
But without knowing better, currently it would be my requirement for a standardized simulation exchange format that models need to be part of this format too.
Best regards
The standard already exists. We are working on a free implementation.
I’m still confused.
Everyone is, and this (together with lack of funding) has caused a lot of delay. Let me try and explain.
We describe how IEEE 1364-2005 can be used in free software tools to exchange schematics. (PCB and layout will be next, but this will fit into the framework without too much hassle.) Imagine two schematic editors that share a data format, just like gcc and clang share the C input language, and similar to how svn and git share the patch format. Use one or another or both in turns to do the work.
The question is how to get the schematic from one editor into the other. Simulating/analysing the circuit requires (at least) the information in the schematic, hence the exchange is the first problem to address.
At this stage, text editors share ASCII encoding, and more recently UTF8. But it works and opens new possibilities. Imagine it didn’t.
Also note that I still struggle with the idea that simulation models are expected to be provided by the simulator
Sadly, this is common practice and lock-in is the consequence. The IEEE standards (+ the AMS extenions to it) describe how simulation models need to be written, so they can be considered user input and no longer “part of a simulator”. And this is where we want to be. Basically you need not to worry about simulator provided models.
Remember Verilog has provided logic gate macros from the onset, the Verilog-AMS LRM defines “SPICE primitives”. Think of these as a standard library, but an optional one. You may want to use a C standard library when you write a C program, but circuits can be built purely with your own components.
But for that I first need a clear idea what expectations you have on the EDA tool.
Think “schematic editor” for now. The expectation on the schematic editor is, that it can read a schematic file, allows to edit a schematic, and save a schematic file. A schematic is not a component library. It is basically a list of parameterised device instances with connections between them (and some extra data to make the drawing).
Our data format leaves space for application-specific extensions. This way you could save the primary data in this format. Application-spefic means, it has no impact on the circuit model the schematic describes. E.g. “this wire is thick red”.
How can the EDA user provide a model for a component not provided by the simulator (yet)?
This is covered by the standard. In many existing tools, a component is a string that would instanciate a specific component of a specific architecture when using a specific simulator (much like embedded assembly code breaks portability of C code). Sometimes there is some mechanism baked into the schematic editor that produces such a string from the data available. Sure everyone does it in a different way.
The schematic editor we are looking for does not implement such a mechanism. A component should be instanciated following the standard rules, certainly not by the schematic editor or associated tools. Instanciation is something a simulator would have to do. Assigning responsibilities is important, because the desired electrical model behind an instance depends on the use case…
How can we control what version of models is used? For LibrePCB we claim projects to be 100% self-contained (not depending on any external data or tools) which should also be true for simulation to guarantee reproducible results.
This is very easy, but not the first step. It does not matter if you reference the device library (if it exists) or bundle the model source to improve self containedness. The relevant piece here is the standard. Whatever model you reference or ship has an implementation independent, simulator independent, unambiguous behaviour described by the modeller, and chosen by the circuit designer.
It is clear that you only get 100% reproducible results if you also fix the simulator and the hardware it runs on. You will find that correctness is more important than reproducibility.
my requirement for a standardized simulation exchange format that models need to be part of this format too.
Looks like we are on the same page here.
Hope this answers some of your questions.
Alright, thanks for the explanations.
OK that sounds great!
Hmm here I’m not sure what’s the goal. Somehow I think for simulation purposes a 1-way exchange format should be enough (export from EDA → import in simulator). I don’t see why the exchange also needs to work the other way around (which makes the whole thing much more complex). Re-importing exported data (like a backwards annotation) is one thing, but loading such an exchange file from scratch (e.g. new project → import) by an EDA tool is really not feasible. See also my statement about that in our FAQ Why introducing a new, non-standardized file format?.
It is like STEP files for mechanical CADs. It is an exchange format which basically every 3D CAD supports. It is extremely complex and flexible but still you always loose tons of information with every exchange. No CAD uses it as its storage file format, it is only usable for integrating the 3D model drawn in one tool into another tool, without the intention to continue editing there. The same applies to many other exchange formats like Gerber, IPC D-356, PDF, etc. They all work only one-way (for good reason) and contain only the data required for a very specific purpose.
So from a simulation exchange format I’d expect it to contain only the information necessary to perform the simulation. Of course the schematic drawing may be part of it for example to visualize the circuit in the simulator and allow attaching probes to wires. But I’d expect the circuit to be read-only in the simulator since the actual schematic from the EDA tool is the single source of truth.
Not sure whether I misunderstand your goal or we have different opinions on this topic.
Yes of course I don’t expect 100% reproducible results, as we only bundle data in projects, while tool versions and the underlying hardware differ from user to user.
Somehow I think for simulation purposes a 1-way exchange format should be enough (export from EDA → import in simulator). I don’t see why the exchange also needs to work the other way around (which makes the whole thing much more complex).
If it makes things more complex, then i am interested in how. Looking at your FAQ …
UUIDs for referencing objects, the file format has to reflect this
We already support UUIDs.
The need to go both ways will become more clear when we move on to PCB and layout. A simulator is not the only possible tool on the “receiving” end. It’s just the one I am working on now.
it would mean that the general concepts of these packages must be identical
And in fact they are. It’s all about circuit models.
and that’s only possible with a different file format.
If it’s just a matter of belief, indeed “export” would still be the first step. You may wish to import your data at a later stage. Maybe it does not matter yet.
How stable is your file format? Does it contain components, with parameters? Is connectivity explicit? For starters (and to simulate) we’d just have to read it in… (i.e. we are looking for help with this).
A LibrePCB project is much more than just a circuit model. It also contains component purchasing information, assembly variant definitions, 3D models, fonts, project settings, ERC/DRC settings, design rules, output jobs and more. It is a complete suite to design PCBs. The actual electrical circuit (i.e. the thing relevant for simulation) is just a rather small part of the whole project.
I think it should be clear that it makes no sense to export STEP models (dozens of megabytes of data irrelevant for simulation) to a simulator and even allow reading them back.
The purpose of exports of any kind is to filter out just the information relevant for a particular task (Gerber for PCB production, Pick&Place CSV for assembly, BOM CSV for parts ordering, PDF for printing, …). These formats are way simpler and completely decoupled from the underlying data structure, making it possible to get them implemented by multiple tools, no matter of their internal data structure.
We use semantic versioning. Within each major version of the application, no changes are made to the file format at all. Newer major versions automatically migrate the files to the newer file format. So far we had only one file format change (v0.1.x → v1.0.x) one year ago.
It may help to to understand our data structure by having a look at a real LibrePCB project:
Thanks for the helpful pointers.
A LibrePCB project is much more than just a circuit model.
Trying to do too much, we might end up with nothing. So lets focus on the schematic.
It may help to to understand our data structure by having a look at a real LibrePCB project:
Ok, I had a quick look.
At a distance the roundtrip schematic.lp => verilog schematic and back does not look very hard to do. For “=>” one might have to look up some UUIDs in other files, too. “<=” is trivial, if the schematic came from LibreEDA.
In Verilog, identifiers are usually chosen for human readability and recognition. But there is no reason not to basically use UUIDs in an exported schematic. Such UUIDs are (likely) useless for non-LibrePCB tools and the verbatim UUID will be stored in an attribute. This again leaves space for a human-readable type and instance name, which I think could be found in those other files.
To give a quick example, if component 12345-…-54321 is actually a resistor with name “R1”, that component would be represented by
(* lp_UUID=“12345-…-54321” […] *)
resistor […] R1([…ports]);
In a Verilog schematic. It may look like just a reversible change in syntax. And it’s close. Anyway, it should be clear how to obtain schematic.lp from such a Verilog dump. What to do in case there is no lp_UUID attribute provided is interesting, but not for now to worry about.
I will have a closer look when I find the time. Preferably someone else will, see above, funding etc.
My advice is just to focus on simulation. The more focused, the simpler and more reliable the exchange file format will be, and the more likely it gets implemented by EDA tools. An exchange file format which is invented to do everything will end up more complex, lead to more compatibility issues, and is harder to implement in EDA tools – probably not getting implemented at all in the end so we won nothing.
My advice is just to focus on simulation
We should focus on growing the team(s). For this, we need common ground, a common language. Sharing a circuit or a schematic drawing (in a suitable format) is only a start.
A file that contains an annotated circuit is not really “more complex”. The circuit is essential for simulation, and the annotation is optional. Even the Verilog syntax is optional – we chose it because of the track record, mainly to save time. Please have another look.
The background story is, nobody will use free tools for serious jobs (= where the money comes from) if everyone bakes their own bread. Industry can afford 10 developpers on converting data back and forth in order to run the simplest tool. We can’t, and it will stay like that.
That said, I wish I could focus on simulation, but I need to dig into the ways people organise their data, and time is short. I would like to see >=1 (free/libre) PCB tool with the ability to export a circuit in a comprehensible language/format. Our roadmap [1] reveals why.
Best wishes
felix
It’s getting off-topic here so I’d summarize the discussion that we agree on having a standardized exchange format for simulation, but it seems we have different opinions about how far this format should go, i.e. what’s the overall goal of it. Generally I’m open for discussing it further (maybe better in person) but to be honest, at the moment I’m not sure if we’ll ever end up sharing the same goal.
Thanks for sharing your thoughts so far.
Urban