Using Mentor Questa® for pre-silicon validation of IEEE 1149.1-2013 based Silicon Instruments™


IEEE 1149.1-2013 is not your father’s JTAG. The new release in June of 2013 represents a major leap forward in standardizing how FPGAs, SoCs and 3D-SICs can be debugged and tested. The standard defines register level descriptions of on-chip IP with operational descriptions via the new 1149.1 Procedural Description Language.1,2,3 IEEE 1149.1-2013 adds support for TAP based access to on-chip IP, configuring I/O parameters such as differential voltage swing, crossing power domains and controlling on-chip power, segmented scan chains and interfacing into IEEE 1500 Wrapper Serial Ports and WIRs. The standard is architected to lower the cost of electronic products by enabling re-use of on-chip instruments through all phases of the IC life-cycle. The standard takes a ‘divide and conquer’ approach allowing IP (instrument) providers who have the most domain expertise of their IP to communicate the structure and operation of their IP in computer readable formats.

Figure 1. Example IEEE-1149.1-2013 IC

IC integrators can then plug-n-play this IP into a design and leverage pre-written and pre-verified operational scripts with low cost IEEE 1149.1 JTAG based tools. The end user does not need to read datasheets and develop Verilog or C/C++ code to operate the provided instrument. Figure 1 shows an example IC with a number of TAP accessible instruments such as Logic BIST, PRBS generator, Memory BIST, Voltage and temperature monitors, PLL, Analog-to-Digital converters, and Digital to Analog converters. Many other types of TAP (Test Access Port) accessible instrumentation exist, such as bus monitors, droop injectors, droop monitors, external DDR memory, SERDES BER testers and FPGA-based universal instruments.4 Intellitech refers to the many flavors of on-chip IP for test and debug as “Silicon Instruments™”.

The Problem

Test benches in Verilog have been the de facto approach to validating JTAG architectures since 1990 when some of the first ICs with on-chip instruments were created to take advantage of the new IEEE 1149.1 standard. Verilog test benches work, but in a limited way. The Verilog test bench may operate the JTAG interface in a way which is not as the interface is used with JTAG based debuggers or PCB testers. State transition dependencies in the home-brew Verilog test bench may not be discovered until tape-out. Verilog test benches may be cumbersome to work with especially when TDR (Test Data Register) lengths change on the fly. The Verilog test benches typically are not delivered to the customer and certainly not supplied to the IC end user, hence they lack the economic benefits of re-use. IC end users can benefit from TAP based access to the on-chip features to test the ecosystem around the IC, monitor on-chip IC parameters (voltage, temperature, etc.), and test the IC itself. An example is the OEM system designer who wants to characterize his FR4 design early on and needs access to a TAP based SERDES BER (Bit Error Rate Test) instrument.

The PDL (Procedure Definition Language) introduced in IEEE 1149.1-2013 changes the validation approach. The IP or silicon provider now needs to validate the PDL routines against the product being delivered. Ideally this is done during simulation rather than after tape-out. Pre-silicon validation ensures that the design’s instrumentation can be configured via the TAP and that the descriptions in BSDL and PDL will do their job correctly when first silicon is available. During first silicon bring up, linear time is critical. It’s not the time to be debugging PDL code or a time to have doubts if the on-chip instrument works as planned.

The major roadblock in developing pre-validated instrument control descriptions in PDL is that commercial simulators don’t know how to read IEEE 1149.1-2013 PDL or instrument package descriptions in BSDL.

The Approach

Questa® and ModelSim® customers can use a freely available software front-end from Intellitech called NEBULA™ to process the IEEE 1149.1-2013 file formats and drive the simulators.5 Figure 2 shows the integration which allows pre-silicon validation and post silicon use.

Figure 2: NEBULA to Questa® Interface and NEBULA to 1149.1 Pod Interface

To validate any Silicon Instrument™, the engineer uses Questa® to compile the Verilog of the instrument and then links in the Intellitech supplied ISIS (Intellitech Simulation Interface Server) DLL (Dynamic Link Library) or Linux SO (Shared Object) File. ISIS allows the Intellitech NEBULA client software to send and receive data to and from the design using the IEEE 1149.1 protocol. It performs a similar function as Intellitech’s iCableServer software does when a user has a USB based JTAG cable connected to an actual IC.

This validation process of the instrument and any data/control paths from the IEEE 1149.1 I/O pins saves valuable time during the testing of initial silicon. The validation identifies all peripheral signals, such as system clocks and resets, which are required for TAP-based control and proper operation of the instrument.

While there are many useful instruments with various level of complexity, this article uses a simple SRAM Built-In Self-Test (BIST) as a test instrument to demonstrate the value of using Questa® to validate the IP description and PDL. The complete sources are supplied with NEBULA so the reader can use them as a tutorial. Figure 3 shows a block diagram of the instrument that includes an IEEE 1149.1-2013 compliant wrapper. IEEE 1149.1-2013 is designed to allow instruments to plug-and-play by connecting compatible TDRs together; it also reduces the support burden for the IP provider as the complete instrument with mission mode control paths can be delivered to the instrument customer.


Figure 3. SRAM Test Instrument with 1149.1-2013 interface

The mission mode interface is shown in the shaded green. Access to the SRAM is performed through the SRAM_BIST_Controller block by the mission interface. A mux (not shown) internal to the SRAM_BIST_Controller arbitrates between test and mission access. A CPU interface is provided which enables the on-chip CPU to access the instrument in exactly the same way as the 1149.1-2013 interface accesses the instrument. The blue shaded section provides the control and status of the SRAM_BIST capabilities via an 1149.1-2013 TDR (Test Data Register) segment. IEEE 1149.1-2013 has standardized on using TDRs compatible with IEEE 1500, that is, using the capture, shift and update states with synchronous TCK rather than the original specification which used a gated TCK and clockDR signal. For FPGA compatibility, we also developed the SRAM instrument interface to support FPGA-style gated TCK operation. While IEEE 1500 style is preferred, the TAP controller in some FPGAs uses a gated clock interface. If you are an IP provider developing instruments for both ASICs and FPGAs, the TDR interface should be configurable for both approaches.

Note that the Enable signal which starts the SRAM BIST must have an update register on it such that it does not toggle during shift operations and it also must reset to the ‘disabled’ state. The portion of the BSDL description from Figure 4 which describes the Enable is shown below.

” (Enable[1] IS (0) ResetVal(EnableGroup(No)) Captures(EnableGroup(-)) )” &

The Enable register is one bit wide and is positioned at bit zero of the TDR segment (bit zero is closest to the scan out). It is assigned the group of mnemonics “EnableGroup” via the ResetVal keyword and the mnemonic value specified at reset is ‘No’. A tool such as NEBULA, which is capable of reading instrument definitions in IEEE 1149.1-2013 format, would know to initialize the software representation of the Enable register bit to zero or “No” when the test logic reset state is entered. It’s another good reason why standalone instruments must be wrapped with a TDR prior to delivery to a customer.

In order to optimize the number of scan operations required to communicate to the SRAM BIST, race free practices in the test data register design are used. It’s possible to write PDL code which uses multiple scans to avoid race conditions but it is better to build wrappers which are glitch free by construction. That way the end user doesn’t supply code which is ignorant of the TDR dependencies or the user is interactively accessing the TDRs through an instrument GUI. The MuxSel signal which switches control from the CPU interface to the 1149.1 interface has an update register and a full TCK cycle delay (as indicated by the D box). This is a new IEEE 1149.1-2013 construct designed to prevent race conditions. The BSDL description for this construct is DELAYPO and it is a useful construct when changing multiple signal edges in a single scan operation while avoiding a race condition. In the diagram, the SRAM BIST mode can be set via the Mode, the controller enabled via the Enable, and control taken from the CPU via the MuxSel all in one scan operation. If the DELAYPO construct was not implemented, the race and resulting glitch could be detected by using Questa® simulation. It’s another good reason to move from Verilog test benches to BSDL and PDL validation.

[fig 4]

Figure 4. Register definitions for SRAM Test Instrument

The pastel red shaded area in Figure 3 is used to deliver detailed diagnostics about what specifically in the SRAM failed. This section adds 29 bits of additional shift cells which can impact test time. Since it is only necessary to scan this TDR when a failure occurs, the instrument IP is provided with two separate TDRs interfaces. The integrator can access the two TDR segments with different instructions or the integrator can implement a SEGSEL mux inline TDR selector to keep the diagnostic scan chain out of the path. If an unwrapped IP was supplied to the customer and was left for the customer to create the TDR interface, it would potentially be problematic if such particulars about the IP were not known. The instrument provider knows how the instrument works so it would be wise in all cases to wrap the instrument with a TDR specifically designed for the instrument.

The IEEE 1149.1-2013 standard now includes robust behavioral descriptions of many register cells used in common Design-for-Test practice. Any IEEE 1500 compliant WSP (Wrapper Serial Port) as well as any IEEE 1149.1-2013 power domain segmentation can be described. TDRs are no longer fixed in length and the register descriptions are no longer flat. They have hierarchy and instruments can be defined stand-alone without the need for an IC level BSDL. Figure 4 depicts a code snippet of the BSDL language which describes the register mnemonics and fields of the instrument design in Figure 3.

[fig 5]

Figure 5. Instrument Development Windows

Figure 5 shows the NEBULA PDL single stepper with hierarchy and register view created automatically from the instrument description and its instantiation as S1 in the design. When PDL routines are executed or single-stepped, each iApply statement causes NEBULA to send scan-in data to the Questa simulator. The response scan-out data from Questa’s simulation of the instrument is used to update the internal register representations in the NEBULA software. The NEBULA user can single step the PDL routines and monitor in real-time the TDR bit fields. Early in development of this PDL, Questa® assisted in identifying (See Figure 5) a missing “iRead Result_Data” command necessary to make sure the Result_Data and Result_Address registers are enabled and in the path prior to any iGet command on their contents. The instrument was designed to allow the registers to be on different segments, so the iRead command guarantees that the Result registers were properly scanned prior to the iGet command. A complete source listing of the instrument PDL is available here. (All the files used in this article, including the Questa® make file, are included in the NEBULA download.) The PDL shows the advantage of the instrument provider pre-wrapping their instrument as the MuxSel, Mode, and Enable can be set in a single iApply (scan operation) saving test time.

[fig 6]

Figure 6. Questa 1149.1-2013 Instrument Simulation

Any PDL iProc procedure that needs to be debugged can be from the NEBULA GUI with Questa® operating on the back end. However, when debugging functional problems of your instrument, the Questa® instrument simulation graphical timing diagram (See Figure 6) provides needed insight. All instrument internal signals are available for inspection in response to the PDL routines being applied.

A key feature for the 1149.1-2013 PDL developer is the Questa® fault coverage capability. The engineer uses this to validate that the PDL routines are adequately testing the instrument. The coverage report contains valuable information about unused states or modes as shown in Figure 7. Coverage is improved by adding PDL or removing state machines or logic in the design which may not be necessary.


Figure 7. Questa Coverage Report


Both Mentor Questa® and Intellitech NEBULA on their own are valuable productivity tools for engineers. Combined they offer a new critical capability that enable pre-silicon validation of silicon instruments for IEEE 1149.1-2013 compliance. NEBULA provides the front-end client, processing the instrument package descriptions and PDL operational code. Questa® provides the simulation back end, providing scan responses and code coverage. As with IEEE 1500 wrapped cores, pre-wrapped IEEE 1149.1-2013 instruments offer the best approach to success and low support costs. Leaving the register creation to the integrator requires the integrator to be aware of race conditions created by the TDR update state and knowledge of how the interface to the instrument works. Designing the 1149.1/1500 wrapper as an integral part of the Silicon Instrument™ appears the best way to optimize PDL and guarantee customer success. Customers specifying on-chip instruments can now include requirements for a pre-verified wrapper with pre-verified BSDL register descriptions and validated PDL.

Contact Information

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis