pcb-rnd devlog

cschem

Some concepts cschem will try to follow (marking with * where there's major difference to geda):

• 1. design
  • 1.1. modularity, aka. toolkit approach
  • 1.2. flexibility (through attributes)
  • 1.3. one schematics file is one sheet
  • 1.4. multi page projects (hierarchic, flat)
  • 1.5. data is in structured text files (no builtin sql support in core)
  • 1.6. * the concept of a "project"; it's optional, tools can work on a set of schematics files _or_ on a complete project
  • 1.7. * nets and components are uniquely identifiable using the same identifiers by all projects
  • 1.8. * no excess "smartness" in the GUI editor: no slotting, no pin numbering, no auto renumbering, etc; these all should be done in the netlist layer and results fed back to the editor
  • 1.9. * direct, bidirectional communication between the editor (GUI) and the netlist layer without any integration of the two, through simple and clean API, keeping both parts replaceable; attributes cschem got back from the netlister are "volatile": not saved, do not override attributes provided by the user
  • 1.10. * less format-specific tricks built into the GUI code, more generic approaches (e.g. a search is a search, not a search-for-text-attribute and results on the result lists are any object of the design)
  • 1.11. * slotting, pin mapping, device mapping are in backends
  • 1.12. * back annotation should not be any harder than forward annotation
  • 1.13. * since a lot of info is invented in backends, not in the GUI (e.g. pin numbers, when slotting), the GUI needs to be able to switch between "views": what (combination of) backend(s) to get these info from; Note: this would also provide an interactive DRC on the GUI with the DRC still implemented in the netlister!
  • 1.14. * the scriptable plugin system is based on GPMI from the start to guarantee the tool is not tied to any one specific scripting engine or scripting language
• 2. implementation
  • 2.1. a core library that does common things like figuring what objects are connected with net lines
  • 2.2. the simple GUI editor should provide the frame; exotic functions should come from user plugins
  • 2.3. a simple netlister that provides only generic (* absolutely no backend specific) queries; actual backends are implemented as plugins
  • 2.4. * the core library and the netlister and the GUI core are all implemented in plain C:
    • 2.4.1. * no dependency on any specific scripting engine or scripting language; no core functionality implemented in anything else but C
    • 2.4.2. * no dependency on big "solves-everything" libraries (e.g. no glib or cairo dependency)
    • 2.4.3. * the actual GUI is behind the plugin system (like PCB's HIDs)
    • 2.4.4. * the first gui, in accordance with the no big libraries, will not be gtk or qt but sdl2 based; this would guarantee to have a front end that doesn't need to be rewritten every 5 years just for the sake of the rewrite
    • 2.4.5. * scconfig instead of autotools: smaller, easier to maintain, works better outside of the gnu-win32 world
• 3. project management
  • 3.1. automatic tests wherever possible, as early as possible
  • 3.2. * VCS: simple, centralized svn with straight linear development, actively trying to avoid branching
  • 3.3. * near-zero-administration releases with svn commits
  • 3.4. * users should be able to submit bug reports anonymously, without having to register, without having to run javascript, java applet, flash, etc.

There are a lot of open questions:

• q1. how buses should work
• q2. how slotting should work (but at least we can have alternatives here)
• q3. how hierarchical design should work
• q4. * how the GUI should display large amount of attributes without making the whole page an unreadable mess
• q5. flat vs. non-flat netlists - if turns out it's not just an implementation detail in a netlister backend
• q6. * whether project file format is a custom format or just a top sch page referencing other sch pages - pcb-rnd is leading here, there is an optional project file format already defined, so this is more or less decided
• q7. attribute conventions