I think presently the only methods to connect nets between two subcircuits are:
1) add an additional single net (i.e., non-bus) port to each subcircuit and wire between subcircuits
2) Add a bus port to each subcircuit and wire betwen subcircuits.
(1) requires adding a new set of ports and connections for each additonal net that is bridged between subciruits and then going back to fix the size, etc. to make the additional ports(s) fit. So this is NOT ideal!
(2) doesn't force you to make any changes to the the ports or size of the subcircuits being bridged and you can expand the nets by just increasing the bus width by changing a few names: bus terminal in child sheet (automatically synched across all child sheets) and bus port name on the bus port (must be manually changed for each instance of the subcircuit used). The issue needing to manually change the bus port name on EVERY instance of the subcircuit used is the subject of my feature request on "Synchronizing Subcircuits"
The issue with (2) when trying to use the method to share nets between subcircuits for non-bus like nets is that it seems only number suffixed nets can be connected this way (i.e., D0, D1,...Dn). Therefore it is not very readable if you start using this method to connect nets with varied function.
It does seem at my first try that if on each child sheet of the subcircuits you additionally place a terminal with the name "D0" connected to a terminal with a meaningful name like "ENABLE" that this might get the job done; given you need to do this for every net being bridge (D0<->ENABLE, D1<->READ, D2<->DATA, etc.). At first try it seems like the more meaningful net name(i.e., "ENABLE") is shown when routing in layout (which is good!).
Unfortunately putting these extra terminal connections on the child sheet does do one thing I want to avoid...take up more space on the child sheet.
Is there another efficient method to bridge nets between subcircuits that I'm missing ?
Would there be any problem with a feature that allowed buses to have names like "[ENABLE READ DATA]" instead of just "D[0..n]" so that nets of a bus are explicitly listed in order as opposed to being implied by the expansion of the prefix "D" and the bus width "[0..n]where the bus width is implied in terms of numbers?
Darrell
Methods of Connecting Nets between Subcircuits
Re: Methods of Connecting Nets between Subcircuits
Ignoring power nets (which are global unless specified otherwise) nets are sheet local. Connecting the nets together is then done by terminals on the child sheet having the same name as ports on the parent sub-circuit.
The only alternative to running the connectivity up and down the sub-circuit hierarchy is to make the nets global. You do this by prefixing the net name with an exclamation mark. Note that this makes the net global to the entire design, not just the hierarchy in question; if you have multiple sub-circuits on root sheets then the net is global to everything. It's a simple solution but much like global variables in code is not considered best practise and risks unexpected connectivity. For example, if you miss it from one instance you'll create a sheet local net which isn't connected to the global one.
If you do use this make doubly sure to verify your connectivity in design explorer. You'll see global nets identified with a different icon and selecting one will show connections on the right hand pane. You can right click on any connection to navigate.
On balance, I'd recommend that it's safer and neater to move signals through the hierarchy on ports and terminals. I find the DXP view of the design then easier to follow.
I agree that the placement and naming of port terminals is a bit tedious but each step is necessary. One thing I've seen before is designs where sub-circuits have been created at the beginning with extra height and a bunch of blank port terminals attached so the job during design iteration is simplified to naming one of the terminals on each circuit. You can then either delete/tidy once at the end or just stub them with an NC terminal to show designer intent.
The only alternative to running the connectivity up and down the sub-circuit hierarchy is to make the nets global. You do this by prefixing the net name with an exclamation mark. Note that this makes the net global to the entire design, not just the hierarchy in question; if you have multiple sub-circuits on root sheets then the net is global to everything. It's a simple solution but much like global variables in code is not considered best practise and risks unexpected connectivity. For example, if you miss it from one instance you'll create a sheet local net which isn't connected to the global one.
If you do use this make doubly sure to verify your connectivity in design explorer. You'll see global nets identified with a different icon and selecting one will show connections on the right hand pane. You can right click on any connection to navigate.
- dexp.png (17.21 KiB) Viewed 717 times
- dxp2.png (24.29 KiB) Viewed 717 times
- ncPort.png (1.9 KiB) Viewed 717 times
Re: Methods of Connecting Nets between Subcircuits
Ian, thanks for the great explanation of the global method!...but I do agree with that for a multi "channel" design using subcircuits that doesn't really help much, well unless you want to connect a whole lot of things that shouldn't be interconnected 
I agree, adding some extra ports to subcircuits before doing the copy and paste thing could make things a tad easier to expand...still need to go back and rename those ports across everything pasted (or just leave them names ambiguous, i.e., extra1, extra2, ...).
I do think having a synching method for subcircuits would be welcomed by anyone doing more complex designs (i.e. lots of identical subcircuits).
I've noticed at least some other schematic packages for HDL type schamatic capture SW have the concept buses that are both ordered and un-ordered. Ordered buses follow essentially what Proteus seems to allow now (net names Q0, Q1, Q2, ..). Un-ordered busses allow a list of net names corresponding to identical net names found in the child sheets the busses connect. Think this kind of thing would be a nice feature that would be better than a pure global net approach, but less effort than explicitly showing each subcircuit connection (especially when other types of signal groups other than pure bus data lines makes sense). Know I've seen another post here where someone wanted to group nets like RD, WR, EN with data nets D0, D1, D2, .etc. into a single bus.
Darrell
I agree, adding some extra ports to subcircuits before doing the copy and paste thing could make things a tad easier to expand...still need to go back and rename those ports across everything pasted (or just leave them names ambiguous, i.e., extra1, extra2, ...).
I do think having a synching method for subcircuits would be welcomed by anyone doing more complex designs (i.e. lots of identical subcircuits).
I've noticed at least some other schematic packages for HDL type schamatic capture SW have the concept buses that are both ordered and un-ordered. Ordered buses follow essentially what Proteus seems to allow now (net names Q0, Q1, Q2, ..). Un-ordered busses allow a list of net names corresponding to identical net names found in the child sheets the busses connect. Think this kind of thing would be a nice feature that would be better than a pure global net approach, but less effort than explicitly showing each subcircuit connection (especially when other types of signal groups other than pure bus data lines makes sense). Know I've seen another post here where someone wanted to group nets like RD, WR, EN with data nets D0, D1, D2, .etc. into a single bus.
Darrell