Upload
sook
View
29
Download
1
Embed Size (px)
DESCRIPTION
Satellite Computer System based on LEON Technology – Mid Semester Presentation. 19/4/2009 סמסטר אביב תשס“ט פרויקט דו-סמסטריאלי Ira Joffe & Yossi Zadik Supervised by: Ina Rivkin. Table of Contents. Project Goals The Leon3 System Block Diagram (Part A) Software Overview Hardware Overview - PowerPoint PPT Presentation
Citation preview
Satellite Computer System based on LEON Technology –
Mid Semester Presentation
ט תשס“אביבסמסטר 19/4/2009
פרויקט דו-סמסטריאלי
Ira Joffe & Yossi Zadik
Supervised by: Ina Rivkin
Table of Contents
Project Goals The Leon3 System Block Diagram (Part A) Software Overview Hardware Overview FPGA Implementation Project Checklist
Project Goals – Part A
Leon 3 environment study:– Hardware structure– Software structure– Tools: introduction and usage
Implementation – basic Leon system with small user core :– Software & HW coding– Implementation on RASTA board
Block Diagram - System Part A
SPARC V8 32-bit processor
AMBA bus – AHB, APB
Memory controller – ROM, SRAM, SDRAM
JTAG Interface Debug unit – access
to the processor
SOFTWARE
Programming the Leon3
Implementation of the SRAM.SREC in the Testbench
prom gen process
System Interaction
We wish to write a program to the Leon3 system and see that the signals run according to it and with the parameters of our program. We’ll go through the process of:
Writing the C program Compile and generate the SREC file Replace the existing SRAM.SREC file with our own Run simulation and check outcome
Step 1 – Writing the C Program
our_test () {
int i;
int *Array = 0x40005000;
for (i=0;i<32;i++) {
Array[i] = i;
}
}
We wrote a very simple
program:
Creating an array at a fixed location in the memory (middle of the SRAM). It’s size is 32 int, and contains the int 0-31.
Step 2 – Compile and Generate the SREC File
We generated the SREC file using these following commands:
Sparc-elf-gcc –g –O2 our_test.c -S -o our_test.s Sparc-elf-as –g our_test.s -o our_test.o Sparc-elf-objcopy –O srec our_test.o sram.SREC
..And got the new sram.SREC file.
C -> srec view
Step 3 – The new SREC File
S00C00007372616D2E7372656365
S315400000009DE3BF9003100014C227BFF0C027BFF482
S31540000010C207BFF480A0601F1480000D01000000DD
S31540000020C207BFF4BB286002C207BFF0BA0740014F
S31540000030C207BFF4C2274000C207BFF48200600176
S31540000040C227BFF410BFFFF301000000B01000014B
S3154000005081C7E00881E800000000000000000000C1
S31540000060000000000000000000000000000000004A
S70540000000BA
Address
Op. Code
Opcode read on wave
Step 4 – Simulation:Op. Code Execution
Wave explanation
USER IP CORE GENERATION
Adding our own
AHB slave (AND Unit)
IP Core Generation
We Wish to add a new IP core to the system. One that will do a very simple function – AND between 2 signals and provide the result. For that we will do the following steps:
1. Write the VHDL code2. Connect our IP to the LEON3MP system through
the AHB Bus3. Write a C code that demonstrates our IP
functionality4. Run simulation and check result
Connecting the IP – Definition & Instantiation
Leon3mp.vhd file
Connecting the IP to the AHB and Compiling
Leon3mp.vhd file
make.vsim file
Writing the C Code
int our_ip_test (){ int *num1; int *num2; int i; num1 = (int*)0xb0000004; num2 = (int*)0xb0000008;
*num1 = 0x11111000; *num2 = 0x00001111;
i = *(int*)0xb0000000; return i;
}
Running the Simulation
FPGA IMPLEMENTATION
Working on the Board
Synthesis
Synthesis was made in 2 parts:1. With the XGRLIB we ran synthesis using
Synplify, which results in an error but creates a .prj file.
2. Using Synplify 9.6 we loaded the .prj file and synthesized it.
Place and Route
P&R was done by ISE Project Navigator, using a .ucf file which holds the board’s timing constraints. At the end of the P&R a .bit file was created.
The GR-CPCI-XC2V Board
The GR-CPCI-XC2V Board cont.
The board was connected to the computer by a Xilinx Parallel Cable => JTAG.
The designed was implemented on the board by loading the .bit file to iMPACT and burning it on the board.
On Board Debugging Using GRMON
GRMON is a debug monitor provided by Gaisler for the Leon3.
It can access the board through different connections like UART, JTAG and more…
GRMON - loading
GRMON – system information
Our_ip_test - C test modification
int main() }
int *num1; int *num2;
int i; num1 = (int*)0xb0000004; num2 = (int*)0xb0000008;
* num1 = 0x11111000;* num2 = 0x00001111;
num1 = (int*)0xb0000000; i = *num1;
num1 = (int*)0x40000000;* num1 = i;
{
GRMON – test loading and running
Project Summery – Part A
Leon 3 system study – HW, SW, Tools Creating Work Environment Software generation process
– Coding– SRAM generation
Hardware generation process:– Code write– Connection to the AMBA I/F– Debugging
Implementation on FPGA:– Synthesis– Place & Route– Debugging – GRMON
PART B: SPW-AMBA Bridge Core with DMA User Core
Part B – SPW-AHB DMA Bridge
The design is based on the GRSPW - SpaceWire codec with AHB host interface from Gaisler Research
The SPW core should connect to the SPW bridge (by Assaf and Michael) in one end, and connect to the Leon system through AMBA IF in the other end
Between these basic demands we designed the following system:
Conceptual Structure of our SPW Core
Top
RX Top)to view RX
components press here(
TX Top(to view TX
components press here)
AHB masterIF and arbiter
APB slave IF
Hierarchal Structure – Part B
Current Status – Part B
Coding: done Compilation: all the blocks that doesn’t
useGaisler’s packages- done
Simulation: On going
Main Open Issues
The core does not include implementation of interrupts (on both directions) – based on SW queuing.
Both RX and TX FIFOs have 32 words depth, and starting DMA at half full.
TX and RX are competing on same AHB IF.
The End
RX top
RX flow manegerRX descriptors
fetcher
RX fifo RX SPW IF
RX dma RX AHB IF
DMA to AHB
RX Components
RX Inputs/Outputs
clk : in std_logic; -- Clock input rst : in std_logic; -- Active high reset
-- Control Registers IF rx_en : in std_logic; -- may receive packets pkt_received : out std_logic; -- HW set after done receiving. cleared by APB write rx_active : out std_logic; -- rx_flow_manager state != IDLE rx_desc_ave : in std_logic; -- rx descriptor is ready in mem rx_desc_off : out std_logic; -- rx descriptors not found in mem no_spill : in std_logic; rx_max_len : in std_logic_vector(24 downto 0); -- bits [1:0] are always 0 rx_base_addr : in std_logic_vector(21 downto 0); rx_desc_offset : out std_logic_vector(6 downto 0);
-- SPW IF spw_empty : in std_logic; -- SPW fifo is empty spw_rd_is_ctrl : in std_logic; -- Read is control (EEP/EOP) spw_rd_data : in std_logic_vector (SPW_WORD_LEN-1 downto 0); -- Read Data spw_rd_en : out std_logic; -- Read enable - pop word from SPW
-- AMBA AHB Master Interface AHBIn : in AHB_Mst_In_Type; AHBOut : out AHB_Mst_Out_Type
TX top
TX flow manegerTX descriptors
fetcher
TX fifo TX SPW IF
TX dma TX AHB IF
DMA to AHB
TX Components
TX Inputs/Outputs
-- General IF clk : in std_logic; -- Clock input rst : in std_logic; -- Active high reset
-- TX control signals from Registers tx_en : in std_logic; -- 1 if a packet is waiting for send tx_en_off : out std_logic; -- no desc is ready pkt_sent : out std_logic; -- HW set after done sending. cleared by APB write abort_tx : in std_logic; tx_base_addr : in std_logic_vector(21 downto 0); tx_desc_offset : out std_logic_vector(5 downto 0);
-- SPW IF spw_full : in std_logic; -- SPW fifo is full spw_wr_en : out std_logic; -- Write enable - push word to SPW spw_ctrl : out std_logic; -- Write is control (EEP/EOP) spw_data : out std_logic_vector (SPW_WORD_LEN-1 downto 0); -- Write Data -- AMBA AHB Master Interface AHBIn : in AHB_Mst_In_Type; AHBOut : out AHB_Mst_Out_Type
PROM GENERATION
prom.S prom.o
prom.exe prom.SREC
gcc - compile
gcc - linker Objcopy – binary to hex
S00C000070726F6D2E737265635AS113000081D8200003000004821060E08188400051S113001081900000819800008180000001000000B0S1130020030020408210600FC2A0004087444000BBS11300308608E01F881000008A1000008C10000061S11300408E100000A0100000A2100000A4100000F8S1130050A6100000A8100000AA100000AC100000B8S1130060AE100000901000009210000094100000E8S113007096100000981000009A1000009C100000D8S11300809E10000086A0E00116BFFFEF81E0000093S1130090821020028190400003000004821060E07ES11300A08188400001000000010000000100000000S11300B0874440008730E01C8688E00F12800016D9S11300C00320000005040E008410A233C420400065S11300D00539A81B8410A260C4206004050003FC39S11300E0C420600882103860C40040008530A00C31S11300F0030000048210600980A040021280000600S1130100033FFC00821061000539A81B8410A26023S1130110C4204000050000088210000080A0E00018S113012002800005010000008200400210BFFFFCB5S11301308620E0013D1003FFBC17A3E0BC2780012BS11301409C27A0600310000081C040000100000053S11301500100000001000000010000000100000097S1130160000000000000000000000000000000008BS9030000FC
Start code, one character, an ASCII letter 'S'.
Record type, one digit, 0 to 9, defining the type of the data field.
Byte count, two hex digits, a number of bytes (hex digit pairs) in the address, data and checksum fields.
Address, four, six or eight hex digits, the memory position for the data. This address is big endian.
Data, a sequence of n bytes of the data themselves. 2n hex digits.
Checksum, two hex digits. One’s component of the LSB.
The SREC File
Wave Diagram
PROGRAM GENERATION IN OUR PROJECT
The PROM does several initializations – registers, interrupts, traps, instruction and frame pointers.
After this stage the PROM jumps to the SRAM start. It is easier to enter the program to the SRAM and keep the
default initial settings. The SRAM.SREC file is created from the system.C file which
calls on different functions from Software/Leon3. The stages for SRAM generation are almost the same as
PROM, except Gaisler gives us a tool – BCC (Blind Cross Compiler) which enables us to do the following process:sram.c -> sram.o -> sram.srec
back
C to Assembler to SREC
1:our_test.c .LLM1:0000 9DE3BF90 save %sp, -112, %sp our_test () {0004 03100014 sethi %hi(1073762304), %g1 int *Array = (int *)0x40005000;0008 C227BFF0 st %g1, [%fp-16] .LLM3:000c C027BFF4 st %g0, [%fp-12] int i; .LL2:0010 C207BFF4 ld [%fp-12], %g1 for (i=0;i<32;i++) { 0014 80A0601F cmp %g1, 310018 1480000D bg .LL3001c 01000000 nop .LLM5:0020 C207BFF4 ld [%fp-12], %g1 Array[i] = i;0024 BB286002 sll %g1, 2, %i50028 C207BFF0 ld [%fp-16], %g1002c BA074001 add %i5, %g1, %i50030 C207BFF4 ld [%fp-12], %g10034 C2274000 st %g1, [%i5]0038 C207BFF4 ld [%fp-12], %g1003c 82006001 add %g1, 1, %g10040 C227BFF4 st %g1, [%fp-12]0044 10BFFFF3 b .LL2 };0048 01000000 nop .LL3: };004c B0100001 mov %g1, %i00050 81C7E008 ret0054 81E80000 restore Back
Step 4 – Simulation:Reading the Op. Code
Step 4 – Simulation:Signal interpretation
hbusreq =‘1’ meaning the AMBA bus arbiter has granted the leon3 to use the bus.
hgrant = ‘8000’ indicating which master is writing on the bus, in this case the leon3.
hwrite = ‘0’ meaning it’s a read transaction. htrans = ‘2’ and then ‘3’. 2 means non sequential,
indicating the first transfer of the burst. 3 means the remaining transfers of the burst.
hsize = ‘2’ means 32 bit transfer.
Step 4 – Simulation:Signal interpretation
hburst = ‘1’ meaning incrementing burst of unspecified length. haddr = ‘40000000’ is the first address we saw in the SREC file
which will contain the first op. code. The addresses which follow advance by +4.
hready goes up every time the op. code of the address requested has been fetched and is ready for reading.
hdata = ‘9DE3BF90’ shows the op. code from a given address. The first one is showed in the SREC file.
hsel = ‘8000’ indicating to which slave the bus addresses, in this case the memory controller.
Back
Step 4 – Simulation:Op. Code Execution
It is easy to follow the step by following the write signal.
There are 2 memory writes per each loop:– Writing to the next element of the array.– Updating the value of i, the loop index.
We can see the array being initialized with the growing value of i, just like we wanted.
Back