Abstract
Chapter 12 of IEEE/ANSI Standard 1149.1–1990 [IEEE90], titled “Conformance and Documentation Requirements,” gives a list of items a designer of an 1149.1 component must document. This information must be provided to users of the component so they may effectively use the Boundary-Scan features. While this list is necessary, it is not sufficient in the practical sense that in nearly all cases software will be utilizing this data. Software cannot read specification documents generated by randomly chosen designers, each with a unique interpretation of Chapter 12. On top of this, the propensity of humans to overlook an item or two, or to make mistakes, is high.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsPreview
Unable to display preview. Download preview PDF.
References
Even within the VHDL world, there are full and partial implementations of the VHDL language.
Though not mentioned in the original paper [Park90], it may be necessary to use “x” characters to specify don’t care locations in an opcode. When this is done, software that consumes BSDL must check that ambiguous decodes have not been erroneously specified. In this example, the line defining EXTEST could read “EXTEST (x0000000),”
These attributes that can identify HIGHZ and CLAMP exist because at the time BSDL was created, these new instructions did not exist. To “grandfather” such components as the 74BCT8374, these attributes should remain in the language. If Supplement A (P1149.1A) passes ballot and introduces HIGHZ and CLAMP, then these mnemonics can become reserved words within BSDL.
The Standard states that designers may add new data registers, or they may access existing registers, in whole or in part. Further, they may take a collection of registers (whole or in part) and concatenate them. If an existing register is subsetted or concatenated in any way, the Standard requires that it be given a new name and treated as a unique new register.
This attribute was defined in the original BSDL paper [Park90]. It was justified as a “declaration” of what resources will be used in the Boundary Register. However, this information can be derived from the description of the register itself. This attribute is thus redundant, but remains to “grandfather” existing BSDL descriptions.
If the port uses a “bit vector” to denote a group of signals, then a subscripted port name must be used here. In the example, see that the D and Q ports are shown in Boundary Register attribute as subscripted signals, like D(3) or Q(5).
See chapter 14 of [Maun90l for cases where System Logic consisting of an inverter can be subsumed into a Boundary Register cell. Having done this, if the logic left is a wire, then cell merging can again be done.
It is a BSDL standard practice that these fields be defined positionally (as shown) rather than by VHDL field tagging. The order of the fields is significant.
This cell design will not support cell merging with an input cell.
Upon completion of P1149.1A (Supplement A) the HIGHZ and CLAMP instructions may become part of the Standard. Sometime after that, 1149.1 software should recognize these instruction names. If the software lags the introduction of these instructions, then the attributes Instruction Disable and Instruction Guard can be used to identify these special features.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 1992 Springer Science+Business Media New York
About this chapter
Cite this chapter
Parker, K.P. (1992). Boundary-Scan Description Language (BSDL). In: The Boundary-Scan Handbook. Springer, Boston, MA. https://doi.org/10.1007/978-1-4757-2142-3_2
Download citation
DOI: https://doi.org/10.1007/978-1-4757-2142-3_2
Publisher Name: Springer, Boston, MA
Print ISBN: 978-1-4757-2144-7
Online ISBN: 978-1-4757-2142-3
eBook Packages: Springer Book Archive