Progress Report
Title:
Automating HDL processing for the integration of hardware test and remote
FPGA laboratory.
Student:
David Newell (08648476)
Project Supervisor:
Dr. Fearghal Morgan
1
Table of Contents
Progress Report .......................................................................................................................... 1
Title: ........................................................................................................................................... 1
Table of Contents ....................................................................................................................... 2
Table of Figures .......................................................................................................................... 2
1
INTRODUCTION .................................................................................................................. 3
1.1
2
Introduction................................................................................................................. 3
Remote FPGA Laboratory .................................................................................................. 3
2.1 Introduction: .................................................................................................................... 3
2.2 Software Tools: ................................................................................................................ 5
2.3 Extracting signals: ............................................................................................................ 5
2.4 Display signals on GUI: ..................................................................................................... 6
2.5 Database: ......................................................................................................................... 6
2.6 Modifying VHDL files: ....................................................................................................... 7
2.7 Automate bit generation: ................................................................................................ 7
2.8 Tasks Completed ............................................................................................................. 8
3
IEEE Standards ................................................................................................................... 8
3.1 Introduction: .................................................................................................................... 8
3.2 IEEE 1149.1:...................................................................................................................... 8
3.3 IEEE 1450.6:.................................................................................................................... 10
3.4 IEEE 1500:....................................................................................................................... 11
3.5 Task Completed:………………………………………………………………………………………………………12
4
References: ...................................................................................................................... 12
Table of Figures
Figure 1: Remote FPGA .............................................................................................................. 4
Figure 2:Process flow of program. ............................................................................................. 5
Figure 3: Example of Java Regex function. ................................................................................ 6
Figure 4: Code from DataAccess Class. ...................................................................................... 7
Figure 5: Example of multiple chips connected in a scan chain [4]. .......................................... 9
Figure 6: Example of TAP controller [5]. .................................................................................. 10
Figure 7: Example of wrapper core featuring WBR, WBY and WIR [9]. .................................. 12
2
1 INTRODUCTION
1.1 Introduction:
The aim of my Final Year Project is to automate the integration of Hardware Description
Language (HDL) for hardware test of System on Chips (SoCs) and for the remote FPGA
laboratory. The remote FPGA laboratory is a website that allows users to upload VHDL
projects, which have been created and simulated, to Field Programmable Gate Arrays
(FPGA) boards that are located in NUIG. This is a very useful system as it allows user that
don’t have access to these boards, which can be very expense to purchase, to verify that
their VHDL projects operate correctly. Currently to upload the projects to the remote FPGA
laboratory website it can be tedious to do as the assignment of registers must be done
manual. The aim of my project will be to automate the integration of the design on the
website.
Expanding on the concept above another aim of the project will be to automate the
Design for Test (DFT) of SoCs, which is outlined in the IEEE 1500 Standard. Many of the
features used in the section above, will be utilised in this section of the project as well.
Currently to include DFT measure a digital designers must follow the IEEE 1500 Standard to
wrap each core of SoCs and repeat the process for each SoC. This process could be
automated and thus reducing Time to Market (MTT).
2 Remote FPGA Laboratory
2.1 Introduction: ‘The Remote Field Programmable Gate Array (FPGA) Laboratory (RFL)
has been developed by Dr Fearghal Morgan as a resource for teaching of Digital systems and
FPGA applications.
RFL is a scalable and extendable, used to enhance the learning of digital systems and FPGA
applications. The RFL system provides always on, remote access to an array of FPGAs. The
web-based remote console provides a real-time, interactive control and visualisation
interface to/from the remote FPGAs, including user clock control. A Xilinx ISE RFL project
template enables integration of user HDL designs for implementation on the RFL. Instructors
and users can create real-time demonstrators of digital systems components, implemented
and executing on the remote FPGA.’[1]
3
Figure 1: Remote FPGA
But as mentioned above, currently when uploading VHDL projects to the RFL website it can
be tedious as the signals must be assigned to certain register banks. The aim of my project is
to make the process of uploading the VHDL projects easier for the user by automating the
process. The automation of the integration of a user designed VHDL to RFL will follow the
steps below.


Extract design hierarchy signals.
Allow the user to view input, output and internal signals via the GUI.
4



Icons on the GUI to allow the user to select internal signals, which makes
these internal signals observable on the RFL.
Provide database to enable UI building on RFL.
Automate the bit file generation process.
Figure 2:Process flow of program.
2.2 Software Tools: To implement the above steps, the Java programming language will
be used. The reason for choosing Java is that there is a very large community based around
the language, which means the language is support widely. Many users of the end product
will already have Java downloaded which means compatibility shouldn’t be an issue. The
NetBeans platform was chosen ahead of the Eclipse platform as creating GUI using
NetBeans is manageable as it utilises a ‘drag and drop’ method of GUI generation.
The Xilinx ISE program is used to generate example VHDL projects. Xilinx ISE allows users to
test, simulate and generate the bit file, which allows user to download their projects to
FPGA boards.
2.3 Extracting signals: To open the users VHDL files and parse through the files, the
Java scanner method is being used. The scanner function opens the .vhd files, which are
very similar to text files. A try-catch loop is used to loop through the .vhd files until it has
been completed parse through. The program can now parse to each line of the .vhd files to
find the key words that relate to signals, e.g. vector. An original technique that was being
used was to use other scanner methods such as “scanner.findInLine()” but this was an
inefficient method of performing a search as it required parse the file and then parsing
through each line separately.
5
A different, more efficient method, called Regular expression was chosen. Regular
expression is a special search mechanism in which lines of text are compared to predefined
patterns and if there is a match the program can choose certain words from within the line.
The regex method is difficult to understand but is much more efficient.
Figure 3: Example of Java Regex function.
2.4 Display signals on GUI: The display will change as these steps take place:



The end program will prompt the user to enter the location of the .prj file that relate
to the user .vhd files.
The GUI will then display all the internal signals, which the user can choose to view
as outputs.
The user will then press a button to upload the code to the RFL, from which they will
be prompted to enter their log in details.
2.5 Database: The DataAccess.java class defines how the signal data is stored. Each
instance of the DataAccess class relates to one signal within the .vhd files and each
DataAccess instance contains information about the signal, such as its name, size (Vector,
scalar, etc.), direction, the component in which the signal is declared and the name of
the .vhd file in which it is declared. As different bits of information that relate to each signal
are parsed at different stages, each DataAccess element (name, size, etc) must have get and
set functions. The get and set functions allow the program to declare and return values at
any stage in the parsing process.
6
Figure 4: Code from DataAccess Class.
As there will be multiple signals for each .vhd files each instance of the DataAccess class
must be stored. An array would be a good solution to this problem. An array operates by the
programmer declaring the size of the array, e.g. if there were five signals in the .vhd file the
programmer would have to declare an arraylist of size five. Each .vhd file can have different
number of signals so this method wouldn’t work. To expand this method, the program could
prompt the user to enter the number of signals in the .vhd files. This wouldn’t be an ideal
situation as the user may not know the number of signals featured in the .vhd files and the
end program should prompt the user for as little information as possible. A dynamic array is
needed and this is called an arraylist. This continues to create instances of DataAccess as
long as there are signals to be stored.
2.6 Modifying VHDL files: The end program will allow the user to choose internal
signals and change these to outputs. This allows the user to view the values of these internal
signals, which is very useful for testing. To implement this, the internal signals will have to
be declared in the port map section of the .vhd file. In relation to the GUI the user will select
a button beside each internal signal to allow the signal to be viewed on an output pin.
2.7 Automate bit generation: A bit file is bit stream that is used to download VHDL
files to FPGA boards. The Xilinx ISE tool carries this process out. To automate the process,
the developed program will have to access the Windows command line. The Xilinx ISE is
7
installed in a default location of “c:\xilinx\”. By completing this task with will enable to user
to upload VHDL files quicker and easier to the RFL webpage.
2.8 Tasks Completed: To date the sections mark 2.1 to 2.5 have been completed.
Sections 2.6 and 2.7 will be completed in the foreseeable future. As the project is divided
into two sections, much of the next semester will be spent on section two, while section one
is being used in real world testing.
3 IEEE Standards
3.1 Introduction: ‘The Institute of Electrical and Electronic Engineers (IEEE) is the world’s
largest professional association dedicated to advancing technological innovation and
excellence for the benefit of humanity’. [2] The main aim of the IEEE 1500 Standard is to
facilitate the testing of embedded logic by design the SoCs for test. The IEEE 1500 Standard
relates very closely to both the IEEE 1450.6 and the IEEE 1149.1. Incorporating design for
test methods in SoCs is very useful as if the chip fails, entering a certain sequence of bits
into the SoC will help the manufacturer locate the problem.
3.2 IEEE 1149.1: The aim of the IEEE 1149.1 standard [3] was to create methods and
mechanisms for testing populated printed circuit boards (PCB). This standard was originally
released in 1990, after many years of research, and is still widely used to this day.
The IEEE Standard 1149.1 is sometimes referred to as its more common name of Joint Test
Action Group (JTAG). JTAG uses methods, such as debugging, storing data in the volatile/
non-volatile memory and boundary scanning, to test printed circuit boards. The method of
interfacing with the chip requires the chip to have 4/5-pins available for the JTAG. The five
pins are:
1. TDI (Test Data In) this signal supplies the data to the JTAG registers.
2. TDO (Test Data Out) this signal serially outputs the data from the JTAG registers and
sends the data to the next chip’s TDI.
3. TCK (Test Clock) is the clock signal, which controls the timing of the test.
4. TMS (Test Mode Select) controls the state changes of the TAP controller. See figure 2
for example.
5. TRST (Test Reset) resets the test interface, but the signal is optional.
A very useful feature of the standard includes the ability to connect multiple chips in a daisy
chain by connecting the TDO of one chip to the TDI of another chip, while each chip is
directly connected to signals TMS and TCK, as seen in the figure below.
8
Figure 5: Example of multiple chips connected in a scan chain [4].
JTAG uses Test Access Port (TAP) controllers to control the JTAG testing. A TAP controller is
really just a state machine, which is controlled by the TMS signal. Figure 2 is an example of a
TAP controller. By looking at figure 2 it is clear to see that there are two distinctive paths,
one for the Data Register (DR) path and one for the Instruction Register (IR) path. The test
interface is controlled by the IR, which selects between the different data registers to be
used during testing. The IR takes in the test to be carried and the DR to be used during the
test and implements these in the TAP controller. In accordance with the IEEE 1149.1
standard, there must be four mandatory instructions. These are:
1. BYPASS: Connects TDI directly to TDO. This function is used to skip devices so that
the correct device can be tested.
2. EXTEST: External Test - Is used to test off-chip circuitry and board level
interconnections.
3. IDCODE: Also a code to be serially read from a component that shows,

The manufacturer’s identity,

The part number,

The version number for the part.
4. INTEST: Internal Test – Allows for testing of the logic components while the chip is
assembled
9
Figure 6: Example of TAP controller [5].
Boundary scanning gives the user the ability to read data at certain pins, load pins with
specific values or check for faults, such as open/closed circuits. Boundary Scan operates by
having ‘cells’ that are added to certain pins of the device, which can override the value at
the pin. Two ‘cells’ can operate together, one sending data and the other receiving, to
determine if there is a fault on the board by using the interconnections on the board.
Boundary Scan uses the JTAG access methods discussed above.
3.3 IEEE 1450.6: The IEEE 1450.6 standard [6] is a language created for a System-on-Chip
(SoC) flow test which facilitates the reuse of designs. This standard can be viewed as an
addition to the IEEE 1450 standard [7], Standard Test Interface Language (STIL), to enable
STIL to be used in more complex applications.
The IEEE 1450 standard or STIL was created to provide an interface between digital test
generation tools and the test equipment. STIL is not just designed for one particular tester
but with the addition of a translator data can be changed to suit a particular type of tester.
This capability is referred to as Tester Rules Checking. STIL represents information that
defines digital test operations but it does not describe how the tester carries out the task.
The IEEE 1450.6 standard is known as Standard Test Interface Language (STIL) for Digital
Test Vector Data or simply Core Test Language (CTL). The standard is an extension of the
IEEE 1450 standard and is very heavily related to the IEEE 1500 standard. One of the main
additional features of CTL to STIL is the ability to reuse test patterns.
CTL facilitates the reuse of a design, created by one group and reused as a sub-design
created by another group. CTL has the ability to model core wrapper and core test
information and send it to core users without disclosing any RTL or gate-level description of
the core. CTL is also designed to be a transfer mechanism of test information between a
core provider and a system integrator to allow for interoperability between producer and
consumer. Some useful features of CTL include:

Constructs to support many different cores and test methodologies.
10

Support of the IEEE 1500 standard in creating wrapper architecture.
3.4 IEEE 1500: The IEEE 1500 standard [8] presents an efficient method to access
wrapped, circuitry around embedded core to facilitate test reuse and interfacing between
core and Test Access Mechanism (TAM), cores while reducing total test time and silicon
overheads. The standard just focuses on the efficient testing of the digital aspect of SoC’s
and doesn’t address the analogue aspect. The standard is an extension of the IEEE Standard
1149.1.
The IEEE 1500 standard is very closely related to the IEEE 1149.1 standard, as one of the
main goals is to enable test reuse, while also reducing overall production time. The standard
attempts to do this by introducing the reuse of cores, which has a knock-on effect of
enabling test reuse. But as circuits become smaller and more complex, it becomes more
difficult to access these cores and also test them. The standard also promotes good designfor-test techniques.
One method of achieving these demands is to use a multiplexed architecture rather than a
distributed architecture. A multiplexed architecture can operate in a hybrid combination,
both serial and parallel, while distributed architecture can only operate in serial. Distributed
architecture can be very inefficient for bigger systems and leads to very big test times.
Another bonus of the multiplexed architecture is clear when accessing external logic, is that
the test methods are independent of the cores.
Each wrapper must have a Wrapper Instruction Register (WIR), Wrapper BYpass register
(WBY) and a Wrapper Boundary Register (WBR). The WIR enables all IEEE 1500 standard
operations by taking data in from the Wrapper Serial Port (WSP). The WBY connects the
Wrapper Serial Input (WSI) directly to the Wrapper Serial Output (WSO), i.e. by passing the
core. The WBY is setup as the default register, so if the wrapper isn’t selected, the scan
chain length is automatically reduced. The WBY register is very useful if the IEEE 1500
wrappers are connected in series as the scan chain length will be reduced, which will greatly
help reduce test time and increase efficiency. The WBR is used when a core is being tested,
the data is applied and the outputs are captured. The register allows the internal testing of
the core, while also testing the connectivity to other cores and circuitry. Shown in the figure
below is an example of a wrapper core featuring the WIR, WBY and WBR registers.
11
Figure 7: Example of wrapper core featuring WBR, WBY and WIR [9].
3.5 Task Completed: Tasks completed to date on this section are minimal. Some
background research has been done on the standards that relate to the wrapping of SoCs
but a much more thorough analysis will have to be carried out. This section will be
undertaken in semester two of the year.
4 References:
[1] About Remote FPGA Lab, RemoteFPGA, viewed 14 December 2011, <
http://remotefpga.com/w/home/>.
[2] IEEE. About IEEE, IEEE, viewed 15 December 2011, < http://www.ieee.org/index.html>.
[3] Institute of Electrical and Electronics Engineers (1990) IEEE Std 1149.1-1990: IEEE
Standard Test Access Port and Boundary-Scan Architecture: IEEE.
[4] Whitis, Mark. Single Scan Chain, Mark Whitis's Website, viewed 15 December 2011,
<http://www.freelabs.com/~whitis/electronics/jtag/>.
[5] Woodward, Joel. 2010 JTAG TAP Controller, ECN, viewed 15 December 2011,
<http://www.ecnmag.com/Articles/2010/07/Design-Talk/Scopes-Deliver-Advanced-JTAGDebug-Capabilities/>.
[6] Institute of Electrical and Electronics Engineers (2006) IEEE Std 1450.6-2005 IEEE
Standard Test Interface Language (STIL) for Digital Vector Data-Core Test Language (CTL):
IEEE.
[7] Institute of Electrical and Electronics Engineers (1999) IEEE Std 1450-1999 IEEE Standard
Test Interface Language (STIL) for Digital Test Vector Data: IEEE.
12
[8] Institute of Electrical and Electronics Engineers (2005) IEEE Std 1500-2005 Standard
Testability Method for Embedded Core-Based Integrated Circuits: IEEE.
[9] SECT eVC applied to a P1500 Wrapper core, 2009, Globetech, viewed 16 December 2011,
<http://www.globetechsolutions.com/index.php?module=articles&func=display&aid=70&pt
id=12&catid=111>
13