Index: trunk/doc/design/09_buses.html =================================================================== --- trunk/doc/design/09_buses.html (nonexistent) +++ trunk/doc/design/09_buses.html (revision 326) @@ -0,0 +1,57 @@ + + +

9. Buses

+ +

{des9:0} +As described in chapter 2, bus-nets +are bundled networks, called channels within the bus. Channels +are identified by their chan attribute. + +

{des9:1} +When a connection is to be made at a hub or port or bus-port, each +channel is considered separately, by its chan attribute, applying +the chan rewrite rules (of the hub or +port or bus-port). + +

{des9:2} +Channel names are arbitrary. To exploit the chan rewrite rules, +a convention for hierarchic naming is introduced in this chapter. Users and +implementations shall respect this convention when creating new channel names. + +

9.1. pseudo-hierarchy

+ +

{des9:3} +A bus-net is a flat collection of channels. That is, there is no bus-in-bus +support. As per convention, a pseudo-hierarchy is encoded in channel names, +using the slash ("/") character. + +

{des9:4} +For example channels "bar" and "baz", are plain channel in the bus; +channel names "foo/bar" and "foo/baz", are considered to be "channels +bar and baz within the virtual sub-bus of foo". + +

{des9:5} +Technically all four +channels are equal bus channels, but it's particularly easy to use the +chan rewrite rules to connect networks or buses to a specific "sub-bus". + +

{des9:6} +There is no limit on how many slashes a channel name may contain, thus +how many levels of sub-buses a bus may contain - for example +"foo/bar/baz/ch1" is a valid channel name assuming a hierarchy +of 3 sub-buses within the main bus. However, if a given prefix is used +as a virtual "sub-bus", it can not be used as a channel name; this if +"foo/bar/baz/ch1" is a channel in the bus, "foo", "foo/bar" and "foo/bar/baz" +are all considered "names of virtual sub-buses" and shall not be used as +channel names. + +

{des9:7} +(Note: cschem, on the abstract level, does not understand sub-buses, +and handles all channel names equally. The above convention is only meaningful +for the user and to some GUI code.) + + + + + + Index: trunk/doc/design/09_buses_imp.html =================================================================== --- trunk/doc/design/09_buses_imp.html (nonexistent) +++ trunk/doc/design/09_buses_imp.html (revision 326) @@ -0,0 +1,5 @@ + + +

9. cschem implementation - Buses

+ +

{imp9:0} Index: trunk/doc/design/index.html =================================================================== --- trunk/doc/design/index.html (revision 325) +++ trunk/doc/design/index.html (revision 326) @@ -12,6 +12,7 @@

  • Hierarchal projects
    (rationale)
  • Device mapping
    (rationale)
  • Ripple annotation
    (rationale) +
  • Buses
    (rationale) Index: trunk/doc/state.html =================================================================== --- trunk/doc/state.html (revision 325) +++ trunk/doc/state.html (revision 326) @@ -38,13 +38,13 @@ 2017-09-08 discussion: attributes:
    spec
    implementation details and rationale 2017-09-22 discussion: netlist
    spec
    (no implementation details and rationale) 2017-10-10 discussion: hierarchic schematics
    spec
    implementation details and rationale - - Current events and open discussions 2017-11-02 discussion: device mapping - slotting, the transistor problem, heavy vs. light symbols
    spec
    implementation details and rationale 2017-11-27 discussion: ripple annotation
    spec
    implementation details and rationale + Current events and open discussions + 2018-02-19 discussion: bus support - conventions and pseudo-hierarchy (mostly already convered by chapter 2)
    spec
    implementation details and rationale + Plans for future events -   discussion: bus support - plugins and conventions (mostly already convered by chapter 2)   discussion: is anything left out, not addressed?   discussion: reference implementation: file format