| ID: | 5649 |
| From: | rn...@igor2.repo.hu |
| Date: | Mon, 16 May 2022 13:32:55 +0200 (CEST) |
| Subject: | Re: [pcb-rnd] RFC: multi-sheet netlist |
| in-reply-to: | 5647 from pc...@cuvoodoo.info |
| replies: | 5650 from ka...@aspodata.se |
On Mon, 16 May 2022, pcb-rnd@cuvoodoo.info wrote: >gEDA/gschem and lepton-eda/schematic support hierarchical design (with multiple/sub-sheets). >this is explained in http://wiki.geda-project.org/geda:faq-gschem?s[]=gtag&s[]=sch#can_gschem_do_hierarchical_designs_with_sub_sheets and an example is shipped with these software in gTAG.sch. > >I tried for the first time this feature because may schematic became too large, unreadable (on one sheet), and parts are just repeated (e.g. multiple ports). >but I have an issue with how netlist are handled with subsheets. >I attached a basic example. Thanks, good example! >In the tEDAx netlist, components have a unique refdes, using the "_sheet-refdes_/" prefix/path. >pcb-rnd treats the name as a string, and does not have the concept of hierarchical design/name. In this specific case hierarchic support in pcb-rnd wouldn't help you. Your problem is potential mixing of local and global scopes - somehting that needs to be decided on schematics level. When pcb-rnd will support hierarchic design, it will most probably support it only one way, and that seems to be the other way you want to get here. >thus when I reuse a component (with the same refdes) on multiple sheets (because the connection of one of the pins only makes sense in this sheet), then pcb-rnd imports multiple times the footprint (one for each name, which includes the path). >this component re-use also applies to multi-part symbols (e.g. dual-opamp). > >the same prefixing is applied to netnames. >thus the GND symbols (using the GND netname) are not interconnected across sheets (this also applies to the provided gTAG.sch example). > >a kind of solution is to use pins on the symbol for the subsheet, and use and INPUT/OUTPUT symbols in the subsheet. >but doing it for all nets (e.g. VCC/GND) just clutters the sheet symbol, and kind of goes against the concept of defining/using netnames. >plus, this does not solve the refdes reuse issue. > Ok, this is a purely gschem/lepton hierarchical question. For simplicity I will refer to it all as "gschem" because letpon uses the same data model. By nature, PCB-targeted netlists are typically flat. Which means the netlister will take your hierarchical netlist and do the necessary conversion from a tree layout to a flat layout then exports the flat layout in the given netlist format. Both the old pcb native netlist format and tEDAx requires this. Your real problem seems to be about scopes, and I think you are trying to use gschem netlists the way they were not meant to be (but I am no expert on hierarchical design in gschem). There are basically 3 approaches: 1. non-hierarchical, multi-sheet design You, and most readers, are probably most familiar with this setup. A single sheet project is the same thing, just with one sheet instead of multiple. In this setup all pages of a project are put in a flat list. If you think in hierarchies, you can imagine a virtual empty top sheet that implicitly refers to all your sheets in your project. Or in other words, if gschem had a project file that simply listed all your sheets so all tools could understand what sheets your project consists of.... Anyway, these are totally equal sheets without any explicit inter-connection (symbols or other means), relying on _project global namespace_. And that's the key to your problem: a "project global namespace" means if you have two symbols, both called U15 on two different sheets within the same project, no matter what the hierarchical layout is, they are compiled into the same abstract component (also called U15). Same happens to nets: if you have GND (or Vbat) on one sheet and then GND (or Vbat) on another sheet, that's the same and only one GND (or Vbat) because of the name match in the project global namespace. (I emphasised Vbat beause GND is no special case.) In this model a limitation of reuse is unwanted name collisions. Imagine you draw a dc/dc PSU sheet that you are going to use in 10 different projects. This PSU sheet has U518 for the controller chip. Works most of the time. Then in a 11th project you happen to have an MCU called U518, and boom, the netlister silently merges your MCU and dc/dc chip into one component. Maybe there's some drc that can tell, but it's usually non-trivial to tell whether you are intentionally doing "inhomogenous slotting" or accidentally had two symbols contribute to the same abstract component. Another limitation is when you want to have 2 copies of the same dc/dc sheet: simply making 2 copies of the file or otherwise giving gnetlist the same content twice won't really work because it will create the very same unique (abstract) components. And this leads to: 2. hierarchical design with namespaces Imagine you want to design a stereo audio amplifier, using discrete components. Since you have two identical channels, you basically need to draw (and then maintain) the same thing twice. Or you can use hierarchy: design the amplifier channel once, then have some top level sheet maybe with the PSU and connectors that then references the sub-sheet twice through symbols. In this setup you do NOT want to have a global namespace, because you have referenced the very same amp channel twice, so it will have the same net names and symbol names. You want a per sheet local namespace so your amp copies are independent. Then you do the necessary communication/connection through symbol pins on the top sheet and in/out symbols in the amp sheet. And yes, this means connecting gnd too - which does make sense if you think it over: what if you want to do something wierd, like add a shunt resistor and measure power consumption, or add a fuse there? If you have to explicitly connect those gnds on the top sheet, you have all the flexibility, if they are somehow magically connect from whithin the sheet, you can't intervene. See also: how default gschem 74xxx symbols have GND and Vcc pins connected from attributes.... Looks like a good idea first, no need to manually connect gnd and vcc all the time... Until your first design where you have a 3V, 3.3V and 5V section and you have to be super careful what you power from where and a careless "this is power, just vcc..." thing brings out the smoke. 3. mixed I am not sure gschem supports this, but in theory it is possible to combine the above two, and the cschem data model allows that. The idea that your hierarchic design normally workds like 2., but then in some rare cases you may want to have a GND or other connection "global". So there's extra syntax for letting you do that. But just "global" is not a good idea for reuse, especially if your hierarchy goes deeper than 2 levels. So what cschem really has is a subtree scope. Using the above stereo amp example, your amp channel may become so complicated that a single stage becomes a multi-sheet flat project, or even a hierarchical project. Whatever you said "global" within that amp stage project is not "global to the whole final project, including both amp channels and the PSU", but only "global within a channel". Which means "take a subtree, and mark some name at the top of that subtree which becomes global downward, but not upward." Conclusion: So far I am not aware there's a 4th use case. I think the gschem model supports only 1 and 2. The cschem model supports 1, 2 and 3. pcb-rnd at the moment supports 1 only. When pcb-rnd becomes hierarchy-aware, it will support 1 for non-hierarchucal netlists and 2 for hierarchical netlists. Still, your netlist generator will need to decide which one of the two to export, because they will look different! And if your schematics uses the mixed model, 3, then your netlist export will need to convert it to 1 or 2, exactly because your schematics-side software needs to know what becomes "global" and what remains in quarantine. The hierarchic netlist support in pcb-rnd will mean you can draw your amplifier channel once, save it as a subcircuit (that contains subcircuits), and when you are drawing the top level board, the whole thing is placed. But as pcb-rnd will support subc-in-subc, it will understand the hierarchy. However, it won't try figure whether you had a global GND or passed GND down with in/out symbols in your hierarchy, that's something the netlister needs to decide and implement. HTH, Igor2
Reply subtree:
5649 Re: [pcb-rnd] RFC: multi-sheet netlist from rn...@igor2.repo.hu
5650 Re: [pcb-rnd] RFC: multi-sheet netlist from ka...@aspodata.se
5652 Re: [pcb-rnd] RFC: multi-sheet netlist from Nicklas SB Karlsson <nk...@nksb.eu>
5653 [pcb-rnd] gEDA "NET" attribute and subc-subc, really tool suite plans (was: Re: RFC: multi-sheet netlist) from rn...@igor2.repo.hu
5654 Re: [pcb-rnd] gEDA "NET" attribute and subc-subc, really tool suite from rn...@igor2.repo.hu