0. Intro: what's this abstract model thing? Before we start test, it's important to recap the terminology and basic mechanisms. The concrete model is the sheet, the drawing (including group attributes) you directly edit. The abstract model is the _meaning_ of it. Example: if you place two opamp symbols and call both of them U15, that is universally accepted to mean there would be a single physical package (dual or quad opamp) and your two U15 symbols are just slots in that package. The concrete model is the two _symbols_, on one sheet or on two different sheets. The abstract model is the resulting single U15 _component_. Then the netlist is a partial export of the abstract model into whatever format. Similar compilation happens to wirenets you draw or connect from attributes in your concrete model when they turn into nets of the abstract model. The process that translates concrete to abstract is called compilation: it compiles the concrete model of a project (which consists one or more sheets) into an abstract model of the project. Netlist export works from the abstract model and doesn't even look at the concrete model. Example from geda-gaf/gschem: geda/gaf has this thing too, it's just hidden deep inside libgeda and gnetlist. What happens there is: - you draw the concrete model in gschem - in the same time you build and maintain the abstract model in your head - you run gnetlist, which reads your concrete model and builds an invisible abstract model in memory - it writes a specific netlist format from that abstract model At the end you look at the netlist and compare it to the abstract model in your head. If they don't match (the netlist doesn't look what you think it should), you need to go back and figure what you need to change on the concrete model. The hard part is this: the netlist does not contain the full abstract model, it's only a small window through you really look at the abstract model. gEDA doesn't give you any tool to look at the abstract model. gschem doesn't give you anything that'd help tracing back a connection between a pin and a net to a drawing object or attribute. So the major differnces we have here are: - sch-rnd doesn't try to hide the idea of the abstract model but makes it explicit and exposes it - sch-rnd does provide UI so you can look at the abstract model directly, which means you no longer need to guess from a netlist output but can really just directly access it, from the GUI too - sch-rnd also helps you trace back things from the abstract model to the concrete model; if you see the the abstract U15 component is not doing what you wanted, sch-rnd helps you figure which drawing objects contributed to U15 and helps you navigate there - sch-rnd can display conclusions of the abstract model on screen; in geda terms it would be running gnetlist and feeding back the final nets/components/names/numbers to the GUI More info about the models and what compilation exactly does: http://repo.hu/projects/cschem/design/ 1. Compile Best way to try this is using an example sheet, psu.lht: cd trunk/src/sch-rnd ./sch-rnd ../examples/psu.lht This is a minimal linear regulator breakout board. When you first open it, you will see some of the "pin numbers" (terminal labels) are printed as empty boxes. This means sch-rnd doesn't yet know the final value. Click on the compile button which is located to the right of the menu bar on the top part of the main window. This will compile the sheet into an abstract model, filling in all the missing terminal labels. If you make modifications to attributes or the drawing, you need to click compile to get the new abstract model compiled. For example copy C1; the new instance will have unknown terminal labels initially. Later on we will have auto-compile (controlled by the checkbox next to the compile button), which will auto-run compile after sheet modifications. 2. views The compilation process is modular, some parts of it are implemented in plugins. This is because different output, or rather, different workflows will need different ways of translating or interpreting things. Taking the above U15 dual opamp example: this kind of slotting makes a lot of sense in a PCB workflow but is nonsense in spice context. Spice wants to see each opamp as a component of its own. Also "pin numbers" will differ, because for spice a BJT will always have the same C B E pinout while in a PCB workflow differet packages and models will have different mapping to pins 1-2-3. A view is a set of plugin and compiler configuration. Views are named and are typically confgured per project. The button under the compile button is the current view. Click it to get to the modal view selector. If you select a different view by double clicking the view name on the left side list, the new view is activated and the abstract model is recompiled. If you switch to the "raw" view, you will see C1 changes its terminal labels to show the original terminal names P and N. If you switch to the pcb view, it will display the physical pin numbers that would match your footprint's. If we had a spice view already, you'd see the spice pinouts using that. 3. abstract model browser You can also look at the abstract model directly by opening the abstract model window (window menu or {w a}). (Note: before the first compilation it's empty. It does refresh whenever you compile.) On the left side you find a tree representing the abstract model: usually components and nets. If you click on an object here, you get details of the object on the right side. Clicking attributes reveal their history (how different plugins of the view modified the given attribute until it reached its final value). When you have a port object selected on the left (e.g. comp/C1/N), the right side also prints where the given port is connected to (at the bottom). A very important button on the right side is "sources". This gives you a tree view listing concrete objects that contributed to the abstract object. This is how you can look up quickly where you need to make edits to change the abstract model. The sources button is an abstract -> concrete jump. 4. attribute editor, right side Now going back to the attribute editor a bit: we also have a concrete -> abstract jump. Right click over an empty area within U1 and select "edit symbol attributes". This will pop up the good old attribute editor. You are familiar with the left side from an earlier test request, but the right side is new: it's the same abstract model detail view that we had above. It's showing the U1 abstract component compiled from the U1 symbol. 5. compilation errors (and future DRC) There are two different levels of possible errors. There are fatal errors during compilation. These errors make it impossible to generate a consistent abstract model. A typical example is when you connect two differently named networks: - start sch-rnd with empty sheet - place vcc from lib - place gnd from lib - connect them with wire In the physical world this is a simple short circuit. In the cschem model, it's worse: when compiling, we need to decide what the resulting abstract net will be called. The vcc symbol says the net name is vcc, the gnd symbol says the net name is GND. The compiler can't decide and throws an error instead. If you have a compilation error, that's a fatal error: the resulting abstract model is incomplete and broken, so it shouldn't be used to run DRC or export netlists. At the moment compilation errors can be seen in the message log window. Later on I will probably make a dedicated window for this so it can help tracing back each error to abstract model and concrete model objects. We don't yet have a DRC and it's not part of the beta test plans. But later we will have a DRC. The DRC will be scriptable and will operate on the abstract model. It will be able to do things like catching missing "pin numbers" or footprints in a pcb workflow or detect nets with multiple push-pull drivers connected to it (if terminal attributes are filled in). However, these are not fatal errors: the abstract model can be compiled and makes sense even if you have DRC errors, it's just that the resulting circuit won't do what it should.