In my last two blogs, I first explained the fundamentals of the IJTAG ICL and PDL languages, and secondly illustrated a flow whereby the ScanWorks product takes BSDL and Verilog input and outputs ICL and PDL. Two of my colleagues, John Akin and Larry Osborn, made a tutorial video on how this all fits together.
In the article IEEE 1687 (IJTAG): ICL and PDL Explained, I described the IEEE 1687 (IJTAG) Instrument Connectivity Language (ICL) and Procedural Description Language (PDL). Chip designers use EDA tools, such as Siemens EDA’s Tessent IJTAG, to create standardized access to embedded instrumentation via these ICL and PDL languages. Although ratified and approved as far back as 2014, it is only now that IJTAG has emerged as a disruptive force in the industry – and this originating from the confluence of heterogeneous integration, chiplet-based designs, and planetary-scale defects such as silent data corruption. The need to standardize access and control of on-chip instrumentation to facilitate the emergence of powerful third-party tools for validation, test and debug is now more compelling than ever. This tutorial article explained some of the complexities behind ICL and PDL in what I hope was an easy-to-understand way.
In the second article, IEEE 1687 (IJTAG): Creating the IJTAG Network and Instruments within an IC, I used our ScanWorks IJTAG product to provide an introductory tutorial on how a design flow using IJTAG works. Specifically, we have a demonstration ScanWorks project that uses an older Opal Kelly evaluation board with a Xilinx (AMD) Spartan-6 FPGA as a platform to illustrate some of the things a chip designer would do to create an IJTAG network, insert on-chip instruments, and then run them. It’s very simple – the instruments are just boundary scan cells that turn on/off LEDs, and the IJTAG network is itself trivial – but I thought it was a good way to introduce those new to IJTAG to the basic principles.
All of this was done as a way to demonstrate some of the underlying technology – by using an FPGA-based design, we can quickly add/change the IJTAG network and attached instruments. In the chip design world, if you’re creating an ASIC, some things are different: for example, you might use the Tessent MemoryBIST tool to insert memory built-in self test controllers, and run STIL vectors against them on an ATE, instead of lighting LEDs; but the underlying technology is the same.
Perhaps inspired by my two articles, two of my colleagues, Larry Osborn and John Akin, went ahead and created a tutorial video that does an even better job of displaying the overall flow. It starts from the beginning of the creation of a ScanWorks project, and assumes no prior knowledge. In the video, you’ll see them:
– Upload the Spartan-6 BSDL file to describe its Test Access Port (TAP) and boundary scan access
– Define the board’s Scan Path
– Input the ICL file to describe the FPGA’s inserted IJTAG network
– Upload the PDL to provide the instrument control
– Run the ScanWorks Actions created from the ICL and PDL to turn on/off the board LEDs.
It’s about a 19-minute video in length, but if you’re new to IJTAG or just want a refresher on how it works under the hood, it’s worthwhile watching.
And if you want a preview without committing to the full 19 minutes, below is the transcript of the tutorial:
John Akin (00:10):
Hello, I’m John Akin, development engineer for ASSET InterTech, and I’m going to go through the process of creating a ScanWorks IJTAG Project. We’ll begin assuming no familiarity with the generation of a basic ScanWorks Project, and create the Project from the beginning. To start with, ScanWorks is invoked, and under Projects, select Create and give the Project a name. In this case I’m just going to call it LED_Demo. Save it in the location ScanWorks\Projects. And with the Project created, we now have to create the fundamental unit of a Project, a Design. To do so, with the Designs tab selected, I select the Create button.
(01:05):
Give the Design a name as well. In this case I’ll call it LED_Demo_Design. Select OK. And the first step in creating our Design is to define the Scan Path. We find the option for doing this under Define the Design, select the Define the Scan Path. Under Define the Scan Path, we find the following tabs including: Scan Paths, which is where we will upload our BSDL files; Packages, which is for secondary libraries or third party files; Instrument Descriptions, which is used to import one of the core elements of IJTAG, the ICL files, or Instrument Connectivity Language files. Then we have the Instrument Operations, which is for uploading PDL files or Procedural Description Language files, the second core element of IJTAG. And then finally Reports for verifying the results of what we’ve generated.
(02:15):
Going back to Scan Paths, we’ll begin by importing a BSDL file. In this folder I have a BSDL file which I’ve set aside for this Project. In this case a Xilinx or AMD Spartan-6 device. With it selected, select Open. Now we use Make to recognize the BSDL file that we’ve added to the Project. We can see from the Reports tab that the Build was a success and we can review the Build Log File for details on the import of the BSDL file.
(03:14):
Now we’ll return to the Scan Paths tab and we want to Create a New Scan Path. The HGL file can be given any name, call it LEDDemoHGL. And that takes us to the Describe Scan Path screen where we find under design directory the name of the FPGA that we’re using for this device. This can be dragged by the arrow into the primary window. Once there, we can give this a name. In this case we can call this device U1. Let’s rename the top level entity; in this case we’ll call it ET_0. Save. And now we see we have both the BSDL and this generated HGL file; we can Make it this level and verify that the build is successful and it says ET_0 is complete and the build is a success.
(04:36):
So taking a look inside the ICL file, we can see several modules declared. Some of these represent elements of the scan chain or the scan chain network such as instruments which connect to the scan chain network to provide information via the network and segment insertion bits, which are elements in the scan chain network, which are used to allow access to the TDRs associated with the instruments. The test data register, or TDR, information will be maintained regardless of whether or not it is applied to the network by way of opening or closing the segment insertion bit. So we don’t have to worry about losing information. It will only be modifiable, however, by either a global reset to the network or by opening the SIB and writing new information to it.
(05:34):
The first module we see here is an example of a very simple instrument inside this design, which is used to illuminate an LED. Taking a look at it by name, we can see that it’s instantiated inside this other module. This module with the wrapper designation also contains two Scan Registers and a ScanMux. These elements collectively define the segment insertion bit, or SIB, that’s used to allow or prevent access by the TDR associated with instrument to the scan chain network. Throughout the design we see more pairs of such modules. Eventually we see the IJTAG Network module, which defines how the SIBs are interconnected within the network. And then finally we have a top level module which connects the LED pins defined here and the TDI and TDO elements of the scan chain network to the AccessLink.
(07:00):
With the ICL file imported into the design, you may now perform another Make to verify that the design builds. And after issuing the make with the ICL file added, we see the Reports tab shows that the build of the design thus far is completed. Now we come to the Instrument Operations tab to import procedural description language file, or PDL. And again, we will make at this level and we see that the effort is completed. This completes adding all the elements we need for our design. Now once all the elements are added, we can also perform the Build from the Designs tab, by selecting Build.
(07:55):
We select Build. We see this window which gives us an option of building just the Design, the Actions, or both the Designs and the Actions. At this stage we’ve only built the Design, not yet added the Actions, so we’ll just build the Design. The amount of time required will vary depending upon the size of the ICL and PDL files being supplied. Now with the Design completed, we can go on to generating Actions, selecting the Actions tab. The first Action we’ll create will be a Scan Path Verify action. We’ll go into Create, select Scan Path Verify. What this action does is simply verify the scan path within the device. Generating this is a simple process. For the most part, the selected options should be fine for most devices targeted. So we’ll take the defaults as they are, select Build, and Save. We’ll come back and run the Actions later.
(09:04):
The next action we create will be an action to configure the FPGA. So under Actions we select Create. And under the list of program actions, we’ll select SVF. To program the FPGA, we’ll need an SVF file. The SVF file, incidentally, for this project was generated based on a Verilog design created for this FPGA. In this case, specifically, Xilinx’s ISE tool was used for the Spartan device to generate a bit file and then convert the bit file to an SVF file. So we’ll select this SVF file, Open, and Build the Action. The Action is built, and we’ll save.
(09:52):
Now we’ll generate two more Actions. In this case, these will the actual IJTAG actions, which are the target of this demonstration. We’ll make a simpler Action, and then one that’s slightly more complicated. Under Create, and under Assembly and Test, we select IJTAG Instruments. Give this one modified name, we’ll say LED0 as our intention will be to target one of eight LEDs numbered 0 – 7 on the target board. Under devices, we’ll select the device. We can see the FPGA’s identification here. And upon selecting it we see a list of instruments that may be accessed, made available to us by way of the PDL file. So in this case we’ll select this LD1 bit instrument zero, which is associated with LED0 on the board.
(11:02):
Upon selecting it, we see Instrument Operations made available below. We’ll select a Write and a Read to start. With these Operations selected, we can now assign values to be written to and values to be expected when read from. Using the pencil icon, we can add a value to the right input operation. The input can be entered in hex to binary. Since it’s a single bit, I’ll just use binary in this case, 0B, representing a binary. Now note, when the board is configured, the LEDs will come up on. The logic is inverse for this particular design. So writing a one to the bit will actually turn the LED off. So we’ll begin by writing a one to turn it off.
(12:00):
Now for the read operation, since we wrote a one, we’ll expect a one back. So what we’ve done so far should turn off LED0 in the list of LEDs on this target board. We’ll add a couple more rights and read pairs. So we can turn the LED back on and then off again. In this case, I’ve inadvertently added a second read, but this gives me an opportunity to demonstrate the deletion feature and now it’s gone. So now we’ll write a zero to this LED to turn it back on and we’ll expect a zero back.
(12:56):
And once again, write a one to turn it off again and of course expect a one back. So now we’ve created a simple test that turns off an LED, turns it back on, and then off again. So now with the Operations set up, we’ll build the action, and it’s built successfully, and save. Then we’ll create a slightly more complicated Action. This one, another IJTAG Instruments Action, which I’ll call LED 4-7. That’s going to impact LED’s four through seven on the target board. And I select the device of being the FPGA. And in this case I’m going to select instrument three as that is the instrument that’s connected to LED’s four through seven. Instrument selected, I now see the Operations available to it, which are: write input, read output, and puts read output. So I’ll stick with write and read, creating, in this case, a pair. For this write, I’ll assign a value of 1010. For the read, again, I’ll expect to see back what was written. Create another write and read pair in this case, swapping the bits 0101, and expecting to see the swap. Now I’ll do one more write and read pair. This time signing a value of 0011 and expecting a value of 0011. Those values added, I’ll Build the Action, and Save.
(15:44):
Before moving on to running the Actions, I wanted to bring attention to the View Map. When we invoke the View Map, it brings up a block diagram which shows the elements of the network. In this case, this top element we have is what, in this design, is called an AccessLink, which creates the connection between the 1149.1 TAP signaling and the network in the device. The next block below is the network level segment insertion bit, which makes available when open all the segment insertion bits below it. When closed, those segment insertion bits below it are not accessible. Underneath the network level segment insertion bit, we have four other segment insertion bits, each of which has an instrument TDR, or test data register, associated with it. When each of these segment insertion bits is open, the data associated with the test data register is accessible. When it’s closed, it’s not. However, it should be noted that that test data register data will not change while the segment insertion bit is closed. So it remains, it can only be modified when reopened.
(17:09):
Now we’ll Save and move on to running the Actions. First, we’ll run the Scan Path Verify Action to make sure our network is accessible. Selecting the Play button we see the action is running past. Next, we’ll move on to the SVF Action to configure the device. Hitting the Play button, we can see the configuration has also passed. And looking down in the target window, we should see that the LEDs on the device have illuminated. Note that at any time, this arrow by the Run Log can be used to open a window, which shows the status of the run.
(18:05):
Now as the IJTAG Instrument Actions are run, keep an eye on the LEDs visible in the target window as they’re modified per our IJTAG Actions. Notice one LED is flickering off, on, off, and then back on. Now we’ll run the LED 4-7 Action and take note in the target window of LED’s four through seven. And the action is running past, and this concludes the demonstration. Please know what we’ve demonstrated here is the ability to dynamically influence the instruments in real time using the assigned operations associated with the PDL files. There’s no need to reconfigure the device with an SVF file to change the behavior. The behavior can be changed in real time through these actions. I hope you’ve enjoyed this presentation. Please note that ASSET contact information will be provided at the end. Thank you.
(Exit):
And with that, the transcript ended. If you’d like to connect or have any questions, reach out to me on LinkedIn, or DM me on Twitter: @AlanSguigna.
