Virtual platform with OpenRisc

2010/06/08 by Sean Chen

Agenda

• Physical platform• Virtual platform• How to Co-Work?• Case for OpenRisc• Requirements

– SystemC /TLM– Toolchain– Other tools

• Getting Start– How to write your test program?– UART sample case– How to run and simulation ?

• References

Physical platform

Physical platform

• Requirements– Physical hardware

• Your IP– Include JTAG interface

• External bridge– Communication between host and target

» FT232, MAX232…

– Software• Driver

– FT232, MAX232

• Tool-chain– GDB debug– Cross compiler (gcc 4 ARM)

Physical platform

• Background– Firmware

• Software control– Compiler

– Tool chain

– How to debug?

• hardware control– Memory map

– Configure register

– Timing sequence

Virtual platform

Black Box(c)

TDI

TDOTMSTCLK

TRST

JTAG(SystemC)

GDB (Client)

Wrapper (SystemC)

Console(Host)

Using the software platform to model the hardware components

Benefits: Fast, build easily, debug quickly ….

Effort: Model building (the Model accurately issue)

Virtual platform V.S Physical platform

• Virtual platform– High level control

• Software – C / SystemC / GDB….

» Dynamic» Portable

• Physical platform– Low level control

• Hardware devices– C

» Driver» Memory map» Configure register

Physical

virtual

Virtual && Physical Co-Work

Virtual platform

Physical platform

Case for OpenRisc

• How to build the virtual platform– Test model

• OpenRisc– C / Verilog

– Wrapper• C 2 SystemC

– Cross Compiler• executable• Debug

– Instruction set• Instruction definition

– putc -> asm()– printf

OpenRisc

• Architecture

JTAG

UART

OpenRisc

• Memory Map

Boot loader location

Requirements/SystemC/TLM

• What’s SystemC?– SystemC processes can communicate in a simulated real-time e

nvironment, using signals of all the datatypes offered by C++, some additional ones offered by the SystemC library, as well as user defined. In certain respects, SystemC deliberately mimics the hardware description languages VHDL and Verilog, but is more aptly described as a system-level modeling language

• What’s TLM?– Transaction-level modeling (TLM) is a high-level approach to

modeling digital systems where details of communication among modules are separated from the details of the implementation of functional units or of the communication architecture. Communication mechanisms such as busses or FIFOs are modeled as channels,

Requirements/Toolchain

• what’s Toolchain?– a toolchain is the set of programming tools that are used to crea

te a product (typically another computer program or system of programs). The tools may be used in a chain, so that the output of each tool becomes the input for the next, but the term is used widely to refer to any set of linked development tools.

• Requirements– GNU compiler (cross compiler)

• GCC• GDB• Lib …• Patch

Requirements/other tools

• Verilog-Perl– Verilog Parser– Include

• Syntax Tree • SigParser • Netlist • …

• System-Perl– SystemPerl is a version of the SystemC language. It is designed

to expand text so that needless repetition in the language is minimized. By using sp_preproc, SystemPerl files can be expanded into C++ files at compile time, or expanded in place to make them valid stand-alone SystemC files.

Requirements/other tools

• Verilator– Verilator is the fastest free Verilog HDL simula

tor, and beats many commercial simulators. It compiles synthesizable Verilog (not test-bench code!), plus some PSL, SystemVerilog and Synthesis assertions into C++ or SystemC code

Getting start 1/2

• Download requirements && Path set – Toolchain and other tools

• Ref: http://funningboy.blogspot.com/2010/05/openrisc-4-install.html

– Waveform or simulation tool• gtkwave / Modelsim( default Icarus Verilog simulation)

• File lists– or32-elf

• bin• Include• lib• …

– Or1ksim-0.0.3 (software link)

Getting start 2/2• Download orpsocv2

– Ref: http://opencores.org/openrisc,orpsocv2

• File lists– sw

• Our test program location– Sim

• Our simulation result and Makefile location– rtl

• orpsocv2 rtl verilog code– Bench

• Systemc interface 2 orpsocv2– Boards

• Real board support (xilinx)– Backend

• Lib and pll define

Top Platform

Host

Testprog

How to write your test program?

– Instruction support• Assembly support

– Register type– Instruction set– Memory address /space– Control sequence– Exception

*.S Compiler

*.c

*.bin

void or32_exit (int i){asm("l.add r3,r0,%0": : "r" (i));asm("l.nop %0": :"K" (NOP_EXIT));while (1);}

UART sample casevoid except vectors…

void syscall_except(){}

void dpf_except(){}

…

Void uart_print_str(char *);

Void uart_print_long(unsigned long);

Int main(){

uart_init();

uart_print_str(“Hello World.\n\t”);

report(0xdeaddead);

or32_exit(0);

}

Name: uart_init()

//set control register / status register

REG8(UART_BASE+UART_IER) = 0x00;

…

//set baud rate

devisor = IN_CLK/(16 * UART_BAUD_RATE);

REG8(UART_BASE+UART_LCR) |= UART_LCR_DLAB

….

Name : reset()

//reset register , status , interrupt , and DMA…

Name : main()

//pc pointer to main

Name : or32_exit()

UART sample case0x000021b0 <main+0>: l.addi r1,r1,-80x000021b4 <main+4>: l.sw 4(r1),r20x000021b8 <main+8>: l.addi r2,r1,80x000021bc <main+12>: l.sw 0(r1),r90x000021c0 <main+16>: l.jal <uart_init> 0x000021c4 <main+20>: l.nop 00x000021c8 <main+24>: l.movhi r3,0x00x000021cc <main+28>: l.ori r3,r3,0x3da40x000021d0 <main+32>: l.jal <uart_print_str>0x000021d4 <main+36>: l.nop 00x000021d8 <main+40>: l.movhi r3,0xdead0x000021dc <main+44>: l.jal <report>0x000021e0 <main+48>: l.ori r3,r3,0xdead0x000021e4 <main+52>: l.jal <or32_exit>0x000021e8 <main+56>: l.addi r3,r0,00x000021ec <main+60>: l.lwz r9,0(r1)0x000021f0 <main+64>: l.lwz r2,4(r1)0x000021f4 <main+68>: l.jr r90x000021f8 <main+72>: l.addi r1,r1,8

store current PI (program pointer)2 main function

Call uart_init

How to run and simulation ?

• Software image creation – ELF files– Verilog Memory (VMEM) files

• This is a hex format suitable for loading into Verilog simulations

– command • # or32-elf-objcopy -O binary myapp.or32elf myapp.

bin • #bin2vmem myapp.bin > myapp.vmem

Event-driven simulation

• Default Icarus Verilog– The event-driven simulation tests are configured main

ly by a single command file for Icarus. This command file is generated for each test. Another generated file is a header file defining some things such as the name of the test

– Command• #vvp a.out• #vvp -M../../bench/verilog/vpi/c -mjp_vpi a.out

Cycle-accurate simulation

• Load a program – #../vlt/Vorpsoc_top -f myapp.or32

• Enable debugging via GDB– #../vlt/Vorpsoc_top -r portNum

• Standard log file (human readable) – #../vlt/Vorpsoc_top --log executed.log

• Binary log file – #../vlt/Vorpsoc_top --binlog executed.binlog

• Reading a binary log file – #../../sw/utils/binlog2readable executed.binlog -o executed.log

Cycle-accurate simulation

• Bus transactions log – #../vlt/Vorpsoc_top --bus-log

• VCD generation – VCD dump

• #../vlt/Vorpsoc_top --vcdfile mydump.vcd

– VCD dump with time set• #../vlt/Vorpsoc_top --vcdfile mydump.vcd --vcdstart

15000 --vcdstop 25000

Cycle-accurate simulation

• Memory dump– dump memory area

• #../vlt/Vorpsoc_top --memdump memdump.bin 0x2000 0x10000

• Crash monitor – #../vlt/Vorpsoc_top -c

References

• OpenRisc– http://opencores.org/openrisc,orpsocv2#own_

software

• embecosm– http://www.embecosm.com/