NoC Routing

Debugging was extensive today on the routing for the NoC. Timing issues and c code syntax were the main contributions to the bugs.

The NoC has now been tested and found to be successful in:

• sending a large sum of packets around the whole network (peer-peer-peer-etc...)
• sending "stop packets" to halt execution of a certain target PE
• crisscross sending of packets (PE0 to PE2 and PE1 to PE3, simultaneously)
  

Work will continue in evaluating power consumption and other schemes of routing.

Meeting

• Evaluation next Wednesday
• Work on benchmark for systemC designs
  
• Research quantum computing (see ACM ISCA paper about quantum computing and low power)
• Register for independent study for fall semester
• 2-page paper about work done this summer
  

FDR2 - How to run

On the Linux machine in the lab, at a terminal command line, type cd $FDRHOME
Then type ./bin/fdr2

FDR2 will open and ask you which csp file to open up. You can then begin to use the program. You can check for deadlock, check for livelock, perform refinement, check the determinism, and evaluate the model.

CSP is a collection of algebraic operators that denote different ways of building and combining processes.

Transaction Level Model diagram

Network-on-Chip diagram

Network-on-Chip Agenda

• Connect clock to testbench modules
  
• Global stop function to stop the systemC simulation (use extern for variables)
• Buffer network interface receive, create a status register to check if buffer contains anything. - The buffer needs to be in a critical section (perhaps semaphore) so that the MSP doesn't read the storage while a packet is being received (messing up the storage count).
  
• Network Interface not connected to bus by GPIO, but rather IO/register
• Diagram the levels of SystemC modules (top, OCA, PEs, etc...)
• Dummy ports to connect Network Interface unused ports (possibly think about revision of network interface to use both ports)

NoC Interface Diagram

Network-on-Chip

To allow testing of a multi-core systemC model, the Network-on-Chip model is used. In the original NoC model, the processing element (PE) was simple - it randomly generated addresses and data. The MSP430 systemC model will be used to replace the PE to create a more realistic model for testing.

A network interface has to be created to connect a MSP430 to the network. Each network interface will handle creation and disassembly of packets. A packet will contain a packet header (to give information about type of packet- data, control, etc...), the destination address, and the data. Once the network interface has received these three items, it will create a packet and pass it to the network. When the network interface receives a packet, it will split it up and send it to the local MSP430.

A possible timing problem with packet creation could be solved possibly through the use of another pin that contains strobe information.

System On Chip Artwork

This artwork was created for use on my summer research poster. It was created using Microsoft Visio 2003.

CSP Assignment

Communicating Sequential Processes (CSP) is a formal method to describe concurrent process. It has many applications in embedded system and multi-processor system-on-chip. The assignment is to download and evaluate CSP related tools:

Formal Systems:
http://www.fsel.com/software.html
Download ProBE and test it. Check if FDR2 is usable and ask for academic license policy.

CSP++:
http://www.uoguelph.ca/~gardnerw/research/

Research and Debugging

Research continues on modeling at the system level. The two articles about transaction level modeling have given way to many other sources on system level modeling and verification.

Further progress has been made in debugging the SystemC model for the MSP430 core and peripherals. Sample programs are written in C code, compiled and translated into machine code, and then verified by comparing the model output to the expected output. Furthermore, the IAR Embedded Workbench tool also generates a list file containing assembly code - this is useful in debugging because I can see what instructions the core will process.

SystemC Model

The MSP430 SystemC model has been fixed to work with code generated from a C compiler called IAR Embedded Workbench. A program can be written in C code, compiled, and translated into machine code that the SystemC model can read and execute. With this step completed, I was assigned some new tasks:

• Check that simple function calls compile and run on the model. In addition, check that add, subtract, multiply, loop, etc... work on the model.
• Create a document detailing the workflow required to go from C code to machine code to running on the MSP430 SystemC model.
• Learn more about SystemC signals (see SystemC user guide)
• Read two articles on Transaction Level Modeling

System Level Diagram

Click diagram for larger view

SystemC Tasks Remaining

Still to do:

• Bus decoder - used to determine which device the CPU will be using (memory or a peripheral)
• Transactions
• Correct the timing
• Begin exploring paper topics in more depth
  

SystemC Model Expansion

It was suggested that in order to create a good model that could be used in discussion in a possible paper, an analog sensor module could be added to the existing model. The module would include an analog source, an A/D interface, and a register map that connected to the existing bus. The MSP430 core could then verify the data received and convert the digital value into a more meaningful representation of the analog input (such as 2.5 V).

As an aside, research of the ARM AMBA (Advanced Microcontroller Bus Architecture), an open standard, on-chip bus specification. It is used in the development of multi-processor and multi-peripheral embedded processors ("a common backbone for SoC modules").

Also, research of materials for multi-processor designs can be found at OCPIP.org . OCP-IP (Open Core Protocol International Partnership) is "dedicated to making a common standard for intellectual property (IP) core interfaces, or sockets, that facilitate 'plug and play' System-on-Chip (SoC) design."

MSP430 SystemC Model

Still To Do (near future):

• byte mode (word mode implemented)
• DADD - a binary coded decimal (BCD) addition operation
• Testing to ensure correct output and status flags
• Use of gcc code flow to create machine code from C code
• Transaction level modeling of bus

MSP430 SystemC Model

The model now contains a memory module that serves as the 64K memory that the MSP430 uses. The addressing modes of the MSP430 are confusing - depending on which registers are used, the addressing mode bits mean different things. This allows the microcontroller to have 7 addressing modes available, while only being able to select out of a maximum of 4 at a time (depending on the operation type).

The initial thought that the MSP430 was RISC-like is becoming more and more dissolved as I continue. The addressing modes are an example of this. It may have only 27 instructions, but the addressing modes and other characteristics complicate this notion.

Most of the instructions are now working for the direct addressing mode. Work is continuing to make the other addressing modes perform correctly.

Xilinx Virtex-II PRO

I began working with the new Xilinx board that came in recently. The Virtex-II PRO (XC2P30) has two PowerPC Processors and is more powerful than the boards we normally use. The use of expansion boards such as DDR SDRAM will allow the board to grow with our applications. The board will primarily be used as a host for embedded processor cores and complex digital systems.

Virtex-II PRO FPGA

I installed the software that came with FPGA board. The EDK (Embedded Development Kit) is a set of tools for designing embedded processor systems using programmable logic, and supports the IBM PowerPC processors and the Xilinx MicroBlaze soft processor core. The main tool is the "Platform Studio". It integrates all of the steps from design entry to debugging and verification.

I began reading the "Platform Studio User Guide", provided by Xilinx, to learn how to create a basic embedded hardware system using one of the PowerPC cores.

The steps taken in creating a hardware system for EDK using the Xilinx Platform Studio (XPS) are:

1. Create a New XPS Project
2. Select a Target Board
3. Select the Processor to be Used
4. Configure the Processor
5. Configure IO Interfaces
6. Specify Internal Peripheral Settings
7. Specify Software Configuration
8. View System Summary and Generate
9. View Peripherals and Bus Settings
10. Generate Bitstream
11. Download Bitstream and Execute

System Level Design

Processor + VHDL/Verilog blocks (peripherals)
Full level functionality at high-level -> SystemC
ISS: Instruction set simulator

Model:

FETCH - get instructions
MEMORY- data & code (not necessarily separated)
DECODE & EXEC- all in one
INTERRUPTS- non-preemptive
GPIO - integrated into memory manager
GPR - function-wise store data, access data

process {
fetch()
decode() // including exec & addl fetch
wait()
update() // reg & memory
}

MSP430 Model

Work has continued in systemC to develop a model for the MSP430. I was told during a recent meeting that my previous work on the model was at the gate-level and needed to be at the system-level. However, the attempt has helped me become more familiar with systemC.

Planning was needed to layout the model. The instructions had to be decoded into the necessary parts such as the opcode, addressing mode, source, and destination. The status register was developed to be set by the appropriate executions.

RISC CPU model

The provided example demonstrates a simple RISC CPU design.

The CPU is modeled in SystemC. The CPU reads in an assembly program and executes it. It then writes the result back to the registers. The instruction set is based on a commercial RISC processor together with MMX-like instruction for DSP programs. It consists of more than 39 instructions, including: arithmetic, logic, branch, floating point, and SIMD.

Algorithms are executed in the CPU and cycles can be measured. The behavior of the CPU and aspects of the memory can be modified by the user.

The memory data is initialized through these files:
abc.asm - sample program
bios - system bios data
dcache - initial data cache
icache - initial instruction cache
register - initial register values

SystemC files:
bios.cpp - system bios unit
dcache.cpp - data cache unit
decode.cpp - instruction decode unit, contains opcodes
exec.cpp - case switch on opcode_tmp's
fetch.cpp - instruction fetch unit
floating.cpp - floating point execution unit
icache.cpp - instruction cache unit
main.cpp - top level
mmxu.cpp - MMX-like execution unit
paging.cpp - instruction paging unit
pic.cpp - programmable interrupt unit

MSP430 SystemC Model

I worked on creating the functions of the MSP430 in SystemC. After some experimentation, I arrived at a simplistic model for a function template that can be used for most of the functions. The MSP430 has 27 instructions ranging from logic functions to arithmetic functions to branch and jump instructions (among others). These simple instructions are the basic of the RISC model for the MSP430, and many more functions can be created from these instructions.

The list of instructions:

0100 MOV
0101 ADD
0110 ADDC
0111 SUBC
1001 SUB
1001 CMP
1010 DADD
1011 BIT
1100 BIC
1101 BIS
1110 XOR
1111 AND

000 JNE/JNZ
001 JEQ/Z
010 JNC/JLO
011 JC/JHS
100 JN
101 JGE
110 JL
111 JMP

000 RRC
001 SWPB
010 RRA
011 SXT
100 PUSH
101 CALL
110 RETI

Adaptive SoC Modeling and Design Objectives

1. Become familiar with SystemC and VHDL.
2. Write a SystemC model for MSP430 core (can simplify functions if difficulty exists).
3. Write the bus transaction level model (TLM) connecting 430 core.
4. Test multi-core processing and communication.
5. Model DVS (Dynamic Voltage Scaling) for different cores.
6. Create adaptive processing array model for streaming data (data flow modeling).

SystemC

I began working on a training course for SystemC called "Introduction to SystemC" by Forte Design Systems. It is a large tutorial designed to give a broad view of SystemC and its syntax. Example code is given; following each section is a short quiz.

The chapters include: Introduction to System C, Channels and Modules, Events and Processes, Structure, Modeling, and Functional Verification.

Chap1:
- Understand why C++ is inadequate and in general how SystemC addresses these inadequacies.
- Understand modeling terms and model types used in SystemC.
- Understand at a high level how SystemC systems and modules are put together.
- Understand at a high level the SystemC module communication paradigm.

Chap2:
- Learn SystemC provided data types and their usage.
- Understand SystemC communication behavior using interfaces, channels and ports.
- Learn the SystemC provided channels.
- Learn how to declare the structure of a module.

Chap3:
- Learn about Events, the basic SystemC synchronization object.
- Learn about SystemC Processes: Thread and Method.

First Day of Research at MSU

I arrived at MSU this morning and continued to work on tutorials and examples in SystemC and VHDL. Professor Zhong scheduled a meeting at 2:00 PM.

Research articles can be found at IEEE Xplore and ACM.org Portal. These two sites will provide additional information that is needed to research System-on-Chip designs and methods.

Professor Zhong suggested that I start with designing simple machines such as an array of ALUs. The two approaches are:

1. Model approach - SystemC, VHDL, Verilog (see Jimmy)
2. Prototype approach - FPGA, microBLAZE (embedded processor), MSP430

Modeling is better to start with first because the prototype/hardware approach would require too much reading of reference material before interesting results could be evaluated.

The overall goal is to study the Adaptive SoC design. It would use an embedded processor for most of computations, but hardware would be designed to handle processes that would benefit from parallelism. One example would be an MPEG decoder in hardware, which is more desirable than in software because of the continuous computation required.

Two questions were posed:

1. How to model concurrent processing?
2. How to model communication (channels, ports, etc...)?

I was encouraged to invent a process that uses several computers. The process would be light-weight and could be as basic as a few multipliers.

Professor Zhong also spoke about future topics that I would be able to pursue. One such topic was applications in signal analysis. It would look at a wireless sensor network. An example of research in this area would be to answer: "How to process data that requires significant computation time?". Aspects of fine-grain parallelism would play a role in this research. Also energy modeling would be of interest. Another topic suggested was Nanoscale devices and fabrication techniques.

Assigned Readings

4 technical papers were read. The titles are:

• "Five Ways to Design Future SoC"
• "MOGAC: A Multiobjective Genetic Algorithm for the Co-Synthesis of Hardware-Software Embedded Systems"
• "High-Level Power Analysis for On-Chip Networks"
• "Route Packets, Not Wires: On-Chip Interconnection Networks"

Start of a Summer Research Blog

The purpose of this blog is to record aspects of the research I complete during the summer of 2005.

The research will occur at Michigan State University in the Electrical and Computer Engineering Department. The faculty advisor will be Professor Zhong. Topics range from System-on-Chip (SoC) architectures, SystemC, Xilinx Tools, MicroBLAZE, Cadence IC Design, VLSI, FPGAs, and ASICs.