Each subset is headed with a list describing which transactions it may initiate, which packets (in addition to replies to its requests) it should receive, and what replies it may emit as a result of reception or snooping. Real devices use a combination of subsets.

The following table indicates the use of subsets by the chips designed for the June87 machine.

The following table indicates the use of subsets by possible future chips.

Interrupt processing is supported through I/O locations in the Small Cache. A Small Cache contains a 32-bit register InterruptStatus containing the current interrupt status. DynaBus devices may OR any value into this register. The corresponding processor will receive an interrupt if this word is non-zero. Each bit is assumed to represent a different "source" of interrupt (i.e. device or group of devices). The processor will read this register and treat each bit set as representing a device requiring some form of service. The reader is referred to [2] for more details.

The support provided by the Small cache is thus minimal: it only collects information supplied by DynaBus devices. There is no support on the DynaBus to acknowledge that an interrupt has been processed by the processor. All the processor can do is remove (ANDing into) bits from the cache's InterruptStatus register.

Interrupts have two parameters:

Devices sending interrupts must have internal register(s) specifying these parameters. The preferred implementation is to have a 16-bit register InterruptAction writable from the DynaBus containing (MSB first) a 5 bit reason code (encoding one bit position among the 32 of the InterruptStatus register), a 1-bit Broadcast flag (1 if all processors must receive the interrupt, 0 if a single processor must receive it), and a 10-bit DynaBus DeviceID of the processor that must receive the interrupt (must be all 1's when broadcast). Devices may choose to have a second 32-bit register to represent the value to be ORed into the InterruptStatus register instead of the encoded 5 bit reason code. Devices should try to use only one bit in InterruptStatus if possible. If multiple bits need to be used (to represent very different interrupts sources), all of them should be independently programmable.

To send an interrupt, a device must generate an IOWrite (BIOWrite if the Broadcast bit is set). The address for the IOWrite must be of the form (32 LSB, other bits must be 0):

Each device needs to have an InterruptSource register containing information on the source of the interrupt. The preferred implementation is to use one bit per possible source. When a processor receives an interrupt, it will search for posted interrupt reasons in the InterruptStatus register, and will read the InterruptSource registers of the interrupting devices (the mapping between interrupt reason number and devices is under software control, thanks to the InterruptAction registers). It will then try to do whatever is needed to remove the source of interrupt (for example reading some data that has been received by the device). The processor must be able to clear individual bits in the device's InterruptSource register either explicitly or by performing some other action on the device.

It is recommended that a device send a new interrupt transaction each time a new interrupt source requires service. Sending one interrupt only for multiple sources is also possible, but some care must be exercised so that no interrupts are lost.

The reader is once again referred to [2] for more details on how the software manages interrupts and what impact this may have on the interrupting device.

IO requests are not checked by the cache for protection. The solution that has been chosen is to defer protection to the device that will reply to the IO request. DynaBus requests carry a Mode/Error bit in the header. This bit will be set to 0 if the request originated from a non-privileged requester (typically a processor running in user mode), to 1 if the request originated from a privileged requester (typically a processor running in kernel mode or a non-processor device).

Each device must decide what IO locations need to be protected against non-privileged requesters. The protection may further be different for IORead and IOWrite (it is expected, but not required, that IOWrite permitted implies IORead permitted for the same address). If the IO access is protected, the device must set the Mode/Error bit to 1 in the reply packet (c.f. section 4) to deny access to the requester, and should not perform any action on the addresses IO location. The second word of the reply packet must indicate the error reason as explained in section 4.3.

It must be noticed that BIOWrites will never result in protection error, since the reply is sent by the DynaBus terminator instead of the addressed device(s). Such requests will just be ineffective for all addressed devices. This peculiar behavior of BIOWrites is not specific to protection, but is a side effect of the fact that devices may never reply directly to broadcasted requests.

When a non-processor makes a DynaBus request, it should always set the Mode/Error to 1 to acquire kernel privilege, unless it is working as a result of some action initiated by a processor running in user mode (there is no such case in the current June87 design). It is safe for non-processor devices to just hardwire the Mode/Error bit to 1 for all request packets on the DynaBus.

The action to be taken by non-processors when they receive a reply packet with the Mode/Error bit set is further detailed in section 4.

The DynaBus offers three different types of error signals:

A device may want to signal an error for various causes, such as:

In any case, the device should provide some information on the error, either in some internal register for ErrorOut or interrupt, or in the reply packet for reply in error as outlined below.

All devices sending DynaBus requests should have a time-out mechanism for the reply. If the timeout expires before the reply arrives, the device should signal an error. The method used depends on the device. Using ErrorOut is not recommended, unless the lack of reply endangers system survival (such as no reply when sending an interrupt...). Most often, an interrupt should be posted. The timeout mechanism does not need to be precise as to the time the error is caught, but all requests that do not get their reply within some time must result in an error.

To signal an error directly linked to a request, a device should set the Mode/Error bit to 1 in the reply header (the most usual case is protection as explained in section 3). The following word of the reply packet contains information on the error. It should be encoded in the following way (upper 32 bits of data are 0):

The action to be taken by a device receiving a reply with Mode/Error=1 depends on the device. Processors (in fact small caches) will store the 32-bit explanation, take a vectored trap indexed by the FaultCode, and provide the full 32-bit explanation word to the software trap handler that will process the error. Non-processor devices may either raise an interrupt if receiving an error is a reasonable possibility (for example, a sophisticated IO device might use the map cache to work with virtual addresses and subcontract mapping faults to a processor), or raise ErrorOut if such an error is unexpected.

As mentioned in 3.2, non-processor requesters should probably hardwire the Mode/Error bit to 1 in request headers to get kernel privileges.

As mentioned in the DynaBus specification, IO addresses consist of a DevType, DevNum and DevOffset field. Each device should be selected by full decoding of the (DevType, DevNum) fields for IORead and IOWrite and by decoding of DevType only for BIOWrite. Devices may (but should avoid) require that BIOWrite also have a specific DevNum (such as all 1's). The DevNum should be derived from the DynaBus DeviceID in a non-ambiguous manner: devices using only a small address space should use exactly the full DynaBus DeviceID. Devices using medium and/or large address spaces should use the low-order bits of their DeviceID. It will be the responsibility of the maintenance processor to assign DeviceIDs at bootstrap time in such a way that the DevNum are non-ambiguous within a device type.

It is strongly recommended that IO registers that may be written from the DynaBus may also be read from the DynaBus. Although it is possible to maintain shadow copies in software, it usually makes debugging and fault analysis more difficult.

Registers accessible through DynaBus IOWrite should also be accessible through DynaBus BIOWrite. If the decoding strategy outlined in the previous section is used, this is no problem.

Since there are multiple processors, multiple IO requests may be sent simultaneously (i.e. in between request and reply) to a given device. It is recommended that devices have an internal IO request queue to support such cases. An alternate possibility is to trust a software lock and just drop on the floor any IO request that comes in the middle of another one (thus causing the requester to end up in timeout). This solution should only be used sparingly for devices that expect a very low rate of IO, such as the display controller.

Most of the DBus functionality for standard cell designs will be provided through pre-defined blocks of logic in the DBusLogic design file [5]. This will include the DBus interface and control logic, chip identification and DynaBus DeviceID. Standard flip-flops and memory arrays of the Logic library [4] will support LSSD automatically, and special flip-flops will be available to support special logic that need to be kept out of the scan path.

A design may be part standard cell, part custom logic. In that case, the designer should use the signals generated by the DBus interface to provide some LSSD facility for the custom logic blocks.

At initialization, the DBus is used to read the chip identification of each device in the system, from which it derives the system configuration and/or checks it against a presumed configuration. Chips using the standard-cell approach will contain a predefined block of logic implementing this function (details are yet to be defined). The chip identification is specific to each implementation (set of VLSI masks). Refer to [3] for more detailed information.

The DBus is also used to setup the DynaBus DeviceID of all DynaBus devices. In order to simplify the bootstrap process, the DeviceID register should be at the same location in the scan path for all devices (e.g. the first 10 bits, excluding chip identification). This should also be supported more or less automatically for standard-cell designs. This constraint permits to minimize the amount of information that must be known at bootstrap time by the debug processor (only a chip identification to scan-path length table).

Normally, devices should start full operation as soon as the DBus nDFreeze signal is rescinded. Some devices may find it necessary to keep certain parts of the chip inoperative until some software action has been performed (delayed reset), such as caches to prevent processors from starting too early in the bootstrap process, or the display controller to prevent display generation before proper initialization. In that case, this delayed reset should be obtained by an internal flip-flop.

The DBus implementation suggested in [3] provides all the functionality necessary to debug standard-cell designs. The design should such that storage elements that are not part of the scan path, such as RAM and FIFO, are nevertheless accessible indirectly through the DBus using the Execute function to single-step the chip. It may be necessary to remove certain flip-flops from the scan path if modifying them would result in undesirable side-effects, but this should be exceptional.