Virtual System

Hardware Architectures Document
Please debate the content of Volume 3 here!
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 152
Joined: Fri Nov 16, 2007 2:06 pm
Location: VT Enterprises Consulting Services, USA

Virtual System

Post by Bradford Van Treuren »

POSTArch.jpeg
The POST Architecture represent the building block elements used to apply boundary-scan tests during power-up.
  • Board Manager represents the entity that must be operational on the board to be able to register the board in the system as well as coordinate when local resources are allowed to power-on.
  • Test Manager represents the entity that coordinates what test is to be run when.
  • Vector Sequencer/Player represents the entity that is responsible for applying the vector information through the TAP Controller. Typically, it understands and maintains the order of the vectors to be applied as well as ordering the response information from the TAP Controller.
  • TAP Controller identifies the enity that converts the vector data into IEEE 1149.1 operations that manipulate the TAP State Machine in the UUT.
  • Vector Storage represents a resource on the board where the vector data and test data reside locally on the board. Typically, this resource is a FLASH device in most current implementations.
  • Diagnostic Result Storage represents a resource on the board where the outcome of the test is preserved for later processing. This may be the entire response vector data, a signature, a GO/NO-GO status of the test, and/or pin and net level failure information.
  • Temporary Storage represents a resource that may be used as a scratch storage used by the Test Manager and Vector Sequencer/Player.
  • Local chain represents the scan chain residing on the board.
RemoteTestArch.jpeg
The Remote Testing diagram represents the use case of performing a test on the remote board that is requested to be applied by the diagnostic technician/operator.
  • Remote Console represents the linkage to the remote system by the technician.
  • The System Diagnostic Manager (SDM) handles the requests made by the operator and transforms them into commands for the targeted Board Diagnostic Agent (BDA). It is also responsible for translating the responses from each of the BDAs into messages the operator will understand. This application typically resides on one circuit board at a time in the system (typically the system controller) and may be supported by a standby board and application in the event of a system controller failure. The SDM is also responsible for ensuring the board to be tested is in the appropriate state for the test as the SDM is responsible for interacting with the system services to change the state of resources within a system. Examples of these states are: On-line, Off-line, Standby, Initializing, Unknown.
  • System Messaging represents the communication interface between the SDM and the BDA. This may be ethernet over the backplane, SERDES lanes of PCIe or SRIO, I2C, or some other means of transmitting formatted packets of information (e.g., the messages) between these two applications.
  • The Board Diagnostic Agent (BDA) represents the application running on each board which interfaces with the SDM. The BDA is responsible for translating the commands issued by the SDM into real operations on the board, such as, applying a test. The BDA is also responsible for translating the responses from the other entities on the board that are involved with a test into messages that are unified in a format the SDM will understand. NOTE: The BDA is able to treat boundary-scan tests the same way as it does for functional tests. Thus, the SDM may call a test by name as it does for functional tests.
  • The remainder of the elements of this architecture are similar to those defined for this POST architecture above.
RemoteUpdateArch.jpeg
The Remote Update Architecture represents the use case for performing an update of the FPGA programming information that resides in a configuration PROM from a remote location.
  • Remote Storage represents a resource located remotely from the system where the target data initially resides. It is from this storage that an operator would pass the data to the system being tested.
  • The Remote Data Transfer Link represents the communications channel between the remote site and the system being tested. Typically, this is the same communications channel the Remote Console interface is using.
  • Optional Local Storage specifies a local resource in the system which can be used to store information to be used by the system managment facility or used as a landing zone for information to be used elsewhere in the system. This storage may be used to temporarily store the data sent from the Remote Storage resource to be distributed to each board under test. Having a single copy of the data locally may be beneficial to perform concurrent updates to boards of the same design as they can share the same storage resource as the source of the data.
  • The Temporary Vector And Test Storage resource represents the storage facility on the board being updated. It is in this resource where the test data and vectors required to perform the update ultimately reside for application to the UUT. Typically, this resource is implemented as RAM and not FLASH because it is considered temporary information. Reworking the storage of a FLASH device is considered to be difficult to accomplish as changes require erasure of sectors of information while data in these sectors that must be preserved must be backed up during erasure. The time to perform a FLASH modification (e.g., FLASH file system) is considered to be too slow for this operation.
  • The remainder of the elements in this architecture are similar to what has already been described in the previous architectures posted.
You do not have the required permissions to view the files attached to this post.
Bradford Van Treuren
Distinguished Member of Technical Staff
VT Enterprises Consulting Services
User avatar
Ian McIntosh
SJTAG Chair
Posts: 504
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: Virtual System

Post by Ian McIntosh »

I've deliberately taken a different view from Brad, in that I've gone for an externally controlled arrangement. The point here is that the boundaries between some of the architectural elements are a bit "grey", so in the external view you can simplify and merge some of constituent elements as they (often) basically amount to a lump of software tooling that the end user doesn't really need to decompose. The other side is that because your boards are not now managing their own tests, you need a bit more visibility of the internal structure of the UUT, in order to know what and how to test.
EST_VS_Diag_01s.JPG
  • The EST Test Manager is the over-arching test executive, providing co-ordination between the BSCAN testing and the application of the stress environment.
  • The Environmental Controller is the thermal chamber or vibration controller, and is often a stand-alone contoller with limited communication capabilities.
  • The results storage holds the BSCAN results for assessment by the EST Test Manager. Whether this contains "raw" results or diagnostics largely depends on wether you decide that diagnostics is a role of the EST Test Manager or the BSCAN Test Manager (bearing in mind that BSCAN TM has no awareness of the influence of the applied environment)
  • I've chosen to keep this simple and assume a basic 5-wire TAP into the UUT, so the TAP Controller here is pretty conventional
  • I've also chosen to illustrate the UUT as comprising a simple multidrop into boards, each with a gateway/switch to one or more local scan paths, which seems fairly typical to me.
EDIT: I wonder if I'm over-simplifying the external aspects in my view, and should have dug a bit deeper into what the BSCAN Test Manager was?
You do not have the required permissions to view the files attached to this post.
Ian McIntosh
Testability Lead
Leonardo UK
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 152
Joined: Fri Nov 16, 2007 2:06 pm
Location: VT Enterprises Consulting Services, USA

Re: Virtual System

Post by Bradford Van Treuren »

Ian McIntosh wrote:I've deliberately taken a different view from Brad, in that I've gone for an externally controlled arrangement. The point here is that the boundaries between some of the architectural elements are a bit "grey", so in the external view you can simplify and merge some of constituent elements as they (often) basically amount to a lump of software tooling that the end user doesn't really need to decompose. The other side is that because your boards are not now managing their own tests, you need a bit more visibility of the internal structure of the UUT, in order to know what and how to test.

EDIT: I wonder if I'm over-simplifying the external aspects in my view, and should have dug a bit deeper into what the BSCAN Test Manager was?
I think it is good to show both the embedded and external perspectives. I have seen a similar implementation using an architecture like my Remote Test Architecture for EST purposes just as Ian indicated the boundary is a bit grey. In my case, the link to the system is the same ethernet link as used for the console and for functional test. The only difference is the EST Manager leverages the Diagnostic Manager in the system the same way an operator would. This reduces the number of electrical interfaces between the outside world and the chamber. However, as Ian points out, the system would have to then manage the tests to be applied.

I think it would be beneficial to gain more insight into the Boundary-Scan Test Manager so we can get a decomposition and see if there are similarities in building blocks to those used in the embedded environment or not. I would request that this decomposition be added by the tool vendors in the working group as they are the owners of that box in the real world.

To reiterate our need for this activity, we are looking for virtual systems that are representative to the functional aspects of a boundary-scan test system as a black box model and not wanting to get bogged down in the details of how systems work as we refine Volume 3 of the white paper.
Bradford Van Treuren
Distinguished Member of Technical Staff
VT Enterprises Consulting Services