-This is an user guide; the formal specificaiton of the feature is +This is an user guide; the formal specification of the feature is documented in the design doc as feature design and implementation notes . @@ -50,15 +50,15 @@ are called misc/shterm_* and they are not really symbols but terminals.)
The abstract model is produced by the compiler by compiling each root sheet -of the current project. Root sheets are all sharind the common namespace at +of the current project. Root sheets are all sharing the common namespace at the hierarchy root. When compiling a sheet, the sheet ref sym is detected and the compiler recurses into compiling the child sheet into a -new level of hirearchy. The terminals of the sheet ref sym are +new level of hierarchy. The terminals of the sheet ref sym are connected to the terminals of the child sheet.
Child sheets can contain sheet ref syms to further child sheets, making up a multi-level hierarchy. The only restriction is that the hierarchy needs to -be free of loops (circuilar references). +be free of loops (circular references).
A large CPU is not specified in a single symbol but is split up into a set -of different "slot" symbols by functional blocks (this is called heterogenous +of different "slot" symbols by functional blocks (this is called heterogeneous slotting). At the end all these slot symbols are merged into the same final abstract component referencing the whole CPU, because they all have the same name (U1). Global nets, such as gnd and Vcc are easy to @@ -96,7 +96,7 @@ name of the child sheet (with or without the .rs ending). The top sheet must be added to the project file as a root sheet and all child sheets must be added to the project file as an aux sheet. The project file needs to be -loaded when running sch-rnd. This ensures all sheets are availabel and can be +loaded when running sch-rnd. This ensures all sheets are available and can be found by name and the project is self-contained (if the directory is packed up and shared, it will load on anyone else's system as well).
@@ -107,9 +107,9 @@
-Hierarchy can also be used to produce repetitve parts. In this (oversimplified) +Hierarchy can also be used to produce repetitive parts. In this (oversimplified) 20_led example circuit -the root sheet cotnains a +the root sheet contains a microcontroller that is controlling two LEDs using PWM. The "power electronics" of driving the LED is the same on both channels so it makes sense to draw it only once and reference it twice from the root sheet by @@ -144,7 +144,7 @@ symbols are merged together into a single big CPU component. In case of the LED example, the same Q1 on different child sheet instances should be different FETs. This problem is the very same problem as with the networks, and the -soluiton is the same: name prefixing. In fact, components have the same +solution is the same: name prefixing. In fact, components have the same name prefixes and the same behavior as nets.
In the actual examples, this was achieved: @@ -174,7 +174,7 @@
Another modification of the original LED example is 24_led. -This introduces a common enable singal, controlled by the +This introduces a common enable signal, controlled by the microcontroller, that can cut off both LEDs at once. To avoid having to have an extra terminal on the both sheet ref syms and having to draw the enable signal to both syms, child sheets simply refer to the blink_enable @@ -210,11 +210,11 @@ accessible from all the module's sheets. However, using a true global net for this purpose is a bad idea, as it may unintentionally merge with the same named global net in the bigger design or with the same named global net of -a second instance of the same module thta should have been independent. +a second instance of the same module that should have been independent.
The solution is using subtree local objects (nets and components). This works by declaring the object (net or component) on the module's root sheet using -a v/ prefix to the name. The v/ prefix means this object is mergable ownly +a v/ prefix to the name. The v/ prefix means this object is mergable only downward in the hierarchy so only subsheets of this module, all somewhere under the module's root sheet will see the object, but it will not merge with anything above the module's subtree. @@ -221,7 +221,7 @@
In example 32_subtree an extension of the 24_led example: the whole led control section with the -microcontrolled and the two LEDs are packed into a subtree. The root of the +microcontroller and the two LEDs are packed into a subtree. The root of the subtree is led_ctrl.rs and is almost the same circuit as main.rs in 24_led. The change is that the 2-channel MCU controlled LED subtree is now commanded through SPI. @@ -275,7 +275,7 @@
-Note: on led_ctrl.rs it's possble to name the blink_enable net without any prefix +Note: on led_ctrl.rs it's possible to name the blink_enable net without any prefix and the example will still work. This is because of the search preference of the auto scope that is used when the name is not prefixed: it will first search sheet local nets to bind to then starts ascending level by level @@ -295,7 +295,7 @@
@@ -329,7 +329,7 @@
-A special use case fr hierarchic designs is "unslotting" a symbol +A special use case for hierarchic designs is "unslotting" a symbol that was drawn as monolithic symbol. E.g. a dual opamp drawn as a single symbol can be split up into two separate opamps This use case is described in