Debug Interface for Clone of 56000 DSP Andreas Nilsson av

Debug Interface for Clone of 56000 DSP Andreas Nilsson av
Debug Interface for Clone of 56000 DSP
Examensarbete utfört i Elektroniksystem
av
Andreas Nilsson
LITH-ISY-EX-ET--07/0319--SE
Linköping 2007
Debug Interface for Clone of 56000 DSP
Examensarbete utfört i Elektroniksystem
vid Linköpings tekniska högskola
av
Andreas Nilsson
LITH-ISY-EX-ET--07/0319--SE
Handledare: Thomas Johansson
Examinator: Kent Palmkvist
Linköping 2007-06-04
Presentationsdatum
2007-06-04
Publiceringsdatum (elektronisk version)
Institution och avdelning
Institutionen för systemteknik
Elektroniksystem
Department of Electrical Engineering
Electronics Systems
2007-06-11
Språk
Typ av publikation
Svenska
X Annat (ange nedan)
Licentiatavhandling
X Examensarbete
C-uppsats
D-uppsats
Rapport
Annat (ange nedan)
Engelska/English
Antal sidor
42
ISBN (licentiatavhandling)
ISRN LITH-ISY-EX-ET--07/0319--SE
Serietitel (licentiatavhandling)
Serienummer/ISSN (licentiatavhandling)
URL för elektronisk version
http://www.ep.liu.se
Publikationens titel
Debug interface for clone of 56000 DSP
Författare
Andreas Nilsson
Sammanfattning
The scope for this thesis was to design a debug interface for a DSP (digital signal processor). The DSP is a research version
of a Motorola 56000 that is designed for a project on asynchronous processor and for use in education.
The DSP and debug interface are controlled via a standard PC with RS232 interface equipped with Linux operation system.
In the project 4 blocks has been designed:
The first block can set the DSP core in debug mode or run mode. The second block sends a debug instruction to the DSP
core, these debug instructions were prerequisite to the project. The third block enable read and write connection to the
memory buses between the DSP core and the three memory blocks. The forth block can override the control signals to the
memories from the DSP core.
The project also uses an UART for interpreting and sending control signals and data between the different blocks and the
computer.
A text terminal program for Linux has also been programmed for handling the PC side communication.
The hardware has been constructed and tested together with a dummy DSP core and dummy memories, but it has not been
tested together with the live DSP core.
The Linux program has been tested the same way and seems to do what it's supposed to, though it leaves a lot work to be
easy to handle.
Antal sidor: 39
Nyckelord
Hardware testing, Debug interface, DSP, FPGA, ASIC
Abstract
The scope for this thesis was to design a debug interface for a DSP (digital
signal processor). The DSP is a research version of a Motorola 56000 that is
designed for a project on asynchronous processor and for use in education.
The DSP and debug interface are controlled via a standard PC with RS232
interface equipped with Linux operation system.
In the project 4 blocks has been designed:
The first block can set the DSP core in debug mode or run mode. The second
block sends a debug instruction to the DSP core, these debug instructions were
prerequisite to the project. The third block enable read and write connection to
the memory buses between the DSP core and the three memory blocks. The
forth block can override the control signals to the memories from the DSP core.
The project also uses an UART for interpreting and sending control signals and
data between the different blocks and the computer.
A text terminal program for Linux has also been programmed for handling the
PC side communication.
The hardware has been constructed and tested together with a dummy DSP core
and dummy memories, but it has not been tested together with the live DSP
core.
The Linux program has been tested the same way and seems to do what it's
supposed to, though it leaves a lot work to be easy to handle.
Contents
1
2
3
4
5
6
Introduction ................................................................................................... 1
1.1 Background ............................................................................................... 1
1.2 Purpose ...................................................................................................... 1
Prerequisite.................................................................................................... 3
2.1 Debug instructions .................................................................................... 4
Hardware ....................................................................................................... 5
3.1 Hardware used in project .......................................................................... 5
3.2 Software for hardware construction.......................................................... 5
3.3 Communication between computer and design ........................................ 5
3.4 Communication protocol........................................................................... 5
3.4.1 Instruction list ................................................................................... 6
3.4.2 Data format of return data................................................................. 6
Hardware construction .................................................................................. 7
4.1 UART ........................................................................................................ 8
4.1.1 Receiver............................................................................................. 8
4.1.2 Transmitter ........................................................................................ 8
4.2 Processor control....................................................................................... 9
4.2.1 In signals ........................................................................................... 9
4.2.2 Out signals......................................................................................... 9
4.2.3 Description ...................................................................................... 10
4.3 Debug instruction memory...................................................................... 11
4.3.1 In signals ......................................................................................... 11
4.3.2 Out signals....................................................................................... 11
4.3.3 Description ...................................................................................... 11
4.4 Read and write buffers ............................................................................ 12
4.4.1 Read buffer...................................................................................... 12
4.4.2 Write buffer..................................................................................... 14
4.5 Memory control....................................................................................... 15
4.5.1 Controller ........................................................................................ 16
4.5.2 Memory address register................................................................. 17
4.5.3 Memory address MUX.................................................................... 17
4.5.4 Control signal MUX........................................................................ 18
Software....................................................................................................... 19
5.1 Communication thread ............................................................................ 19
5.2 Initiate step .............................................................................................. 19
5.3 Step program step.................................................................................... 20
5.4 Read memories step ................................................................................ 20
Results ......................................................................................................... 21
6.1 Synthesized for FPGA............................................................................. 21
6.1.1 Stratix II .......................................................................................... 21
6.1.2 Cyclone II........................................................................................ 21
6.2 Testing..................................................................................................... 21
6.3 Possible improvements............................................................................ 22
6.3.1 Hardware ......................................................................................... 22
6.3.2 Software .......................................................................................... 22
7 Conclusions ................................................................................................. 23
8 References ................................................................................................... 24
1 Introduction
1.1 Background
Electronics Systems (ES), under the Department of Electrical Engineering at the
University of Linköping are making a clone of a Motorola 56000 digital signal
processor (DSP). The processor is designed as VHDL code that can be
synthesized for a FPGA (field programmable gate array). The main purpose of
producing the processor clone is to use it for testing ideas in the research of the
department and to use it in education.
1.2 Purpose
The purpose of this thesis is to design a debug interface for this DSP core where
it is possible to control the DSP core via a standard PC.
Features that are needed are:
Writing to memories.
Reading from memories.
Running the processor in normal mode.
Running the processor one instruction at a time.
Reading processor registers when processor is in debug mode (not
running).
In my project it was also included a task to make a program to control the
hardware from the PC-computer.
•
•
•
•
•
1
2
2 Prerequisite
The goal of this project is to be able to load and run a test program in the DSP
core and to read the values of the registers in the DSP between every instruction
step. After the execution of the program the content of the DSP memories are to
be read and all the gathered data compared with expected result. All this is to be
controlled via a standard PC with Linux operation system. The control is
supposed to be done manually via a terminal program or automatically via a
program on the PC.
DSP
CORE
Processor
CTRL
Memory
Debug
Instr
Figure 1: A sketch over the usable data buses, memory control bus and DSP debug control
signals.
The DSP has the following I/Os that is interesting to this project and where it is
possible to connect extra hardware.
• Debug signal (processor control), an in signal to switch between run and
debug mode.
• ds0, an out signal that goes high when the last clock cycle of an
instruction is executed
• Debug instruction bus, a 6-bit in instruction bus that sends instructions to
the DSP core when it is in debug mode. If this bus is set to a value of a
valid debug instruction when the DSP is in debug mode a register value
assigned by this instruction will be copied to the X data bus and other
buses will be tri-stated, P and Y data bus will always be tri-stated in
debug mode. If a non valid debug instruction is set the X data bus will be
tri-stated.
• 3*24-bit bidirectional data buses between the DSP core and the memories,
the 3 memories are Program memory, X data memory and Y data
memory.
• 3 control signals from the DSP core for each memory these signals are
read/write, output enable and chip select.
3
2.1 Debug instructions
The debug instructions for the DSP core have the following format [1].
d5 d4 d3 d2 d1 d0 Description
0 0 0 0 0 0 Tristated output
0 0 0 0 X 1 Reserved
0 0 0 1 D D Data ALU register, Table A-18 Motorola FM
0 0 1 D D D Data ALU register, Table A-18 Motorola FM
0 1 0 T T T Address ALU register, Table A-18 Motorola FM
0 1 1 N N N Address ALU register, Table A-18 Motorola FM
1 0 0 F F F Address ALU register, Table A-18 Motorola FM
1 0 1 P P P Pipeline table, own defintion
1 1 0 X X X Reserved
1 1 1 G G G PCU register, Table A-18 Motorola FM
Triple bit register encodings
Code DDD DD
FFF NNN TTT GGG PPP
000
A0
*
M0
N0
R0
*
PipePC
001
B0
*
M1
N1
R1
SR
PipeWord
010
A2
*
M2
N2
R2
OMR SSHdebug
011
B2
*
M3
N3
R3
SP
LCdebug
100
A1
X0
M4
N4
R4
SSH
LAdebug
101
B1
X1
M5
N5
R5
SSL
*
110
*
Y0
M6
N6
R6
LA
*
111
*
Y1
M7
N7
R7
LC
*
4
3 Hardware
3.1 Hardware used in project
During this project I have used a development board from Altera with a Stratix
II FPGA chip, in the end of the project changed to a development board with a
Cyclone II FPGA chip. The Department of Electrical Engineering are also
planning to make an ASIC including a synthesised version of my project.
3.2 Software for hardware construction
During the design process I have been using HDL Designer from Mentor
Graphics for VHDL coding and Quartus from Altera for synthesising the code.
3.3 Communication between computer and design
For communication between the hardware design and a standard PC-computer
the RS232 communication protocol without echo of sent data was used, this due
to the simplicity of this protocol.
The communication speed shall be set to a fixed speed during synthesis of the
design. The speed is depending on the clock frequency used for the
implementation and the number of bits per second (bps) can not be higher than
1/10 of that clock frequency.
In the case of this thesis the clock frequency was set to 48 MHz and the
communication speed was set to 57600 bps. Other examples of functioning
communication speed are 4800, 9600, 19200, 38400, 115200 and 230400.
3.4 Communication protocol
The communication protocol used is 8-bit ASCII. Different ASCII signs are
used for sending instructions and data.
0-9 and A-F are used for sending data in hex format.
Letters except for A-F are used for sending instructions (case sensitive).
“;” and “:” are used for flow control.
5
3.4.1 Instruction list
Here below follows a list of the ASCII instructions used for sending data to the
debug interface from the computer.
x = read X-bus, returns data.
y = read Y-bus, returns data.
p = read P-bus, returns data.
X = write to X-bus, followed by data in hex format (typ 24 bit)
Y = write to Y-bus, followed by data in hex format (typ 24 bit)
P = write to P-bus, followed by data in hex format (typ 24 bit)
I = set instruction, followed by instruction data in hex format (typ 6 bit)
M = set memory address, followed by address data in hex format
R = run complete program
r = run a single instruction and return to debug mode
S = stop program and enter debug mode
0-9 and A-F = hex data.
“return” = end of data
3.4.2 Data format of return data
Here below follows a list of the ASCII instructions used for sending data from
the debug interface to the computer. Data is only returned on instructions from
the computer, see chapter 3.4.1 for these instructions.
0-9 and A-F = returned data.
; after input data x, y or p = end of data
; after input data r = end of instruction
: after input data r = end of program.
: after input data R = end of program
6
4 Hardware construction
The debug interface contains of the following blocks:
• UART – A communication interface that translates and sends data
between the computer and the rest of the debug interface.
• Processor controller – A controller for setting debug mode or run mode on
the processor.
• Debug instruction memory – A memory for saving the debug instruction
received from the computer and forward it to the processor core.
• Read and write buffer – These buffers handle the communication between
data buses and the UART
• Memory control – A memory control override to use when core is in
debug mode.
R/W
R/W
R/W
DSP
CORE
Memory
MEM
CTRL
Processor
CTRL
Debug
Instr
Memory
UART
RS232 link
Figure 2: A sketch over the different blocks and how they are connected to the data buses,
control buses and DSP.
7
4.1 UART
I have used a ready UART and decoder unit built by Peter Kröger for the
Department of Electrical Engineering.[2] The UART has been modified to trigger
on the ASCII signals used in the instruction list. By default the decoder part
detects ASCII signals 0-9 and A-F as hexadecimal data and converts it to 4 bit
binary data.
4.1.1 Receiver
The receiver reads incoming RS232 ASCII. If an ASCII sign in the instruction
list is received the UART sends a trigger signal to the effected construction
block.
If ASCII for 0-9 or A-F is received hex data it as 4 bit binary packets to all other
construction blocks followed of a trigger signal telling that data is present.
If ASCII for “;” or <return> a signal telling each block that there are no more
data to receive is sent.
4.1.2 Transmitter
The transmitter sends ASCII data when told to do so from the other construction
blocks. If one block sends signal to send data when transmitter is already
sending data no action will be taken of this signal.
8
4.2 Processor control
Run
single
Run
full
Stop
end of
prog
Idle
Stop
end of
instr
Figure 3: The state diagram for the processor control state machine.
4.2.1 In signals
Here below follows a list of in signals to this block and were they come from
•
•
•
•
•
•
Run full from UART.
Run single instruction from UART.
Stop signal from UART.
End of instruction from DSP core.
Ds0 from DSP core.
Illegal instruction from DSP core.
4.2.2 Out signals
Here below follows a list of out signals to this block and were they go
• Debug mode to DSP core.
• End of instruction to UART.
• End of program to UART.
9
4.2.3 Description
The processor control is a state machine that generates the control signal to the
DSP core to set it into debug or run mode. It also generates return signals for
end of instruction and end of program to the UART.
In the “idle” state the DSP is set into debug mode and the state machine waits
for a signal to run a single instruction to go to the “run single state” or to run
until end of program to go to the “run full state”.
In the “run full state” the state machine sends a run signal to the DSP and waits
for a stop signal from the UART or an illegal signal from the DSP. Either of
these signals makes the state machine go on to the stop end of program state.
In the “stop end of program” state the state machine sets the DSP in debug
mode, sends an end of program signal to the UART and goes on to the “Idle”
state.
In the “run single” state the state machine sends a run signal to the DSP and
waits for signals for end of instruction or signals for end of program. In case of
an end of program signal the state machine goes to the “stop end of program”
state. In case of an “end of instruction” signal the state machine goes to the “stop
end of instruction” state.
The “stop end of instruction” state sets the DSP in debug mode, sends an end of
instruction signal to the UART and the state machine goes on to the “Idle” state.
10
4.3 Debug instruction memory
Control block
for register
Enable signal for shift-reg
6-bit shift-reg
shifting in 4
bits at a time
Figure 4: Block diagram of the debug instruction memory
4.3.1 In signals
Here below follows a list of in signals to this block and were they come from
•
•
•
•
New instruction data trigger signal from UART.
End of data signal from UART.
Data available from UART.
4-bit data bus from UART.
4.3.2 Out signals
Here below follows a list of out signals to this block and were they go
• 6-bit debug instruction bus to DSP core.
4.3.3 Description
The debug instruction memory consists of a controller and one shift register.
The controller triggers on a signal from the UART to start shifting in new data
into the shift register and an end of data to stop shifting in data to the shift
register.
The shift register triggers on an enable signal from the controller and a new data
signal from the UART to shift in data from the UART.
11
4.4 Read and write buffers
The read and write buffers consists of one read buffer and one write buffer that
has been linked together to one building block.
Figure 5: Block diagram for the read and write buffers.
4.4.1 Read buffer
Send
2
Send
Send
check
Idle
Wait
Idle
Send
End of
data
Figure 6: State diagram for the read buffer state machine.
12
4.4.1.1 In signals
Here below follows a list of in signals to this block and were they come from
• 24-bit data bus from bus between DSP core and memory.
• Read bus trigger signal from UART.
• Send next data trigger signal from UART.
4.4.1.2 Out signals
Here below follows a list of out signals to this block and were they go
• 4-bit data bus to UART.
• Available data trigger signal to UART.
• No more data to send trigger to UART.
4.4.1.3 Description
The read buffer actually is a state machine that in the “idle” state waits for a read
signal from the UART. When the trigger signal is received the state machine
moves to the “send” state.
The first time in each send cycle that the “send” state is reached it will copy the
4 most significant data bits from the data bus and send it to the UART together
with a send data trigger signal. The state machine goes on to the “send 2” state.
The next time the “send” state is reached the next 4 bits from the bus will be
copied and so on down to the 4 lowest significant bits.
In the “send 2” state the state machine waits for a handshake signal that tells that
the UART is ready to receive more data and goes on to the “send check” state.
In the “send check” state the state machine determines if the all data has been
sent or not, if all data has been sent the machine goes to the “wait idle” state
otherwise back to “send” state to send one more 4-bit package to the UART.
In the “wait idle” state it’s determined if the UART is ready to sent data, if it is
the machine goes to “send end of data” state.
In the “send end of data” state the machine sends an end of data signal to the
UART and the machine goes in to the “idle” state.
13
4.4.2 Write buffer
Control block
for register
Enable signal för shift-reg
k-bit shift-reg
sifting in 4
bits at a time
Figure 7: Block diagram for the write buffer
4.4.2.1 In signals
Here below follows a list of in signals to this block and were they come from
•
•
•
•
•
Trigger signal from UART
End of data signal from UART
New data signal from UART
4-bit input data bus from UART.
Output enable from memory control
4.4.2.2 Out signals
Here below follows a list of out signals to this block and were they go
• Output data to data bus, tri-stated
4.4.2.3 Description
The write buffer part of the read/write block triggers on signals from the
receiver block and from the memory control block. It receives data as 4 bit
blocks from the receiver block and shifts this data into a shift register. When a
write signal is received from the memory control bus the data from the shift
register is set on the data bus linked to the block.
14
4.5 Memory control
Memory
address
register
ADDR
MUX
X
ADDR
MUX
Y
ADDR
MUX
P
CTRL
MUX
X
CTRL
MUX
Y
CTRL
MUX
P
Controller
Figure 8: Block diagram for the memory control block.
The memory control block handles if the control signals to the memories come
from the DSP core or if the memories are controlled by internal control signals
from the debug interface.
The memory control block consists of the following parts.
•
•
•
•
Controller.
Memory address register.
One memory address MUX for each memory (P, X and Y).
One control signal MUX for each memory (P, X and Y).
15
4.5.1 Controller
Get
Write
Bus
Write
prep
Get
Read
Bus
Read
Prep
Idle
Read
Mem
Write
Mem
Figure 9: State diagram for the controller block in the memory control block.
4.5.1.1 In signals
Here below follows a list of in signals to this block and were they come from
•
•
•
•
Read in memory trigger signal from UART.
Write in memory trigger signal from UART.
Data available signal from UART.
4-bit data bus from UART.
4.5.1.2 Out signals
Here below follows a list of out signals to this block and were they go.
•
•
•
•
•
3 select signals to memory address MUXes and control signal MUXes.
3 out put enable signals, one to each read/write block.
Read/write signal for memory, goes to each control signal MUX.
Output enable signal for memory, goes to each control signal MUX.
Chip select signal for memory, goes to each control signal MUX.
4.5.1.3 Description
The controller generates control signals to the memories and handle if the
control signals that’s internally generated in the controller or the signals from
the DSP core are to be used.
The controller works as a state machine. When the state machine is in the idle
state the memory control block is transparent to the DSP core.
16
4.5.2 Memory address register
4.5.2.1 In signals
Here below follows a list of in signals to this block and were they come from.
•
•
•
•
New memory address data trigger signal from UART.
End of memory address data trigger signal from UART.
4-bit data bus from UART.
Data available signal from UART.
4.5.2.2 Out signals
Here below follows a list of out signals to this block and were they go.
• Memory address bus to memory address MUXes
4.5.2.3 Description
The memory address register works in the same way as the debug instruction
memory (see 4.3) and is used for setting an override memory address to the
memories.
4.5.3 Memory address MUX
4.5.3.1 In signals
Here below follows a list of in signals to this block and were they come from
• Memory address bus from DSP processor
• Memory address bus from memory address memory
• Select signal from controller in memory control
4.5.3.2 Out signals
Here below follows a list of out signals to this block and were they go
• Memory address bus to external memory
4.5.3.3 Description
The memory address MUX selects memory address from the memory address
register (4.5.2) or from the DSPs memory address bus. The selection is made
from the select signal from the controller.
17
4.5.4 Control signal MUX
4.5.4.1 In signals
Here below follows a list of in signals to this block and were they come from
•
•
•
•
•
•
•
Chip select signal from DSP core.
Chip select signal from memory control controller.
Output enable signal from DSP core.
Output enable signal from memory control controller.
Memory read/write signal from DSP core.
Memory read/write signal from memory control controller.
Select signal from memory control controller.
4.5.4.2 Out signals
Here below follows a list of out signals to this block and were they go
• Chip select signal to memories.
• Output enable signal to memories.
• Memory read/write signal to memories.
4.5.4.3 Description
The control signal MUX selects if the control signal to the memories come from
the controller or from the DSP. The selection is made from the select signal
from the controller
18
5 Software
The software sends control instructions via RS232 from computer to the debug
interface and receives the returned data and formats it.
The program runs in two different threads, the first thread handles the actual
communication over RS232, the other thread generates data to transmit and
formats the received data. The two threads communicate via a shared memory
area.
The program has three different modes.
• Init – It loads data into the P, X and Y memory in the processor. P for
program memory. X and Y for data memory,
• Step program – It steps the program in the core and reads register values
from the core.
• Read memories – It makes a memory dump of P, X and Y memories.
5.1 Communication thread
The communication thread receives the input from the RS232 interface and puts
the in data in a cyclic shared buffer. The data can be polled from the different
steps in the 3 program steps. The communication thread has been very
influenced by a rs232server program by David Björkevik.[3]
5.2 Initiate step
The initiate step opens the file called “file1.txt” that is supposed to be placed in
the same catalogue as the software program. The ASCII in this file is then sent
on to the RS232 port. Returned data will be ignored in this step. ASCII sign “/”
is used for commenting in the text file, which means that ASCII between two “/”
signs will be ignored.
This step is supposed to be used for loading the different memories. The ASCII
sign “;” in the text file will end this step end the software will go on to the Step
program step.
19
5.3 Step program step
The Step program step starts with sending the ASCII sign for running a single
instruction on the DSP core and waits for the return of the ASCII sign for either
end of instruction or the ASCII sign for end of program.
It then sends instructions to the debug interface to get the data from the different
registers in the DSP core. When all data is collected it will be formatted and
presented in the text terminal. If the ASCII sign for end of program was received
in after executing the instruction the step is terminated and the program will
continue on to the read memories step. Else if the end of instruction was
received this step will be run again until end of program signal is received.
5.4 Read memories step
The read memories step is supposed to be used for reading the data in the DSP
memories.
It sends the ASCII from the file called “file3.txt” placed in the same catalogue
as the software to the RS232 interface and waits for return data where expected.
Returned data will be presented on in the text terminal window. ASCII placed
between two “”” signs in the text file will also be presented in the text terminal.
And ASCII placed between two “/” will be ignored as comments in the text file,
it is not possible to make comments in text that is supposed to bee presented in
the text terminal.
When a “;” ASCII sign is detected in the text file this step will end and the
program will terminate and close the RS232 port.
20
6 Results
6.1 Synthesized for FPGA
6.1.1 Stratix II
The design has been synthesized for the Stratix II FPGA from Altera with no
errors.
The design uses 438 LUTs (Logical Units) and 355 registers of the FPGAs
capacity.
The design also uses 200 I/O ports, out of those 200 I/Os 196 will be internal
when the design is connected to the DSP processor and the memory, 2 will be
shared with the DSP processor (clk and rst), this means that the design actually
need 2 I/O ports from the FPGA chip.
Maximum clocking speed for the design for the Stratix II chip is 183.45 MHz
For complete area report see Appendix 1
For complete time analyse report see Appendix 2
6.1.2 Cyclone II
The design has been synthesized for the Cyclone II FPGA from Altera with no
errors.
The design uses 356 LUTs (Logical Units) and 336 registers of the FPGAs
capacity.
The design also uses 200 I/O ports, out of those 200 I/Os 196 will be internal
when the design is connected to the DSP processor and the memory, 2 will be
shared with the DSP processor (clk and rst), this means that the design actually
need 2 I/O ports from the FPGA chip.
Maximum clocking speed for the design for the Stratix II chip is 91.94 MHz.
For complete area report see Appendix 3
For complete time analyse report see Appendix 4
6.2 Testing
The hardware and software has been tested with a dummy core and dummy
memories since the finished Core and the real memories were not available to
me during the design period.
A standard PC with Linux has been connected via a RS232 to a FPGA
development board with the test design downloaded the FPGA. The PC program
has been run and the result has been compared with expected result.
21
6.3 Possible improvements
6.3.1 Hardware
As of now there is one known bug in the Core dummy that is used for
debugging, this means that the dummy Core cannot send a correct end of
program signal to the debug interface while stepping the DSP program.
The memory control has been coded for a generic s-ram and may need to be
replaced to work with the memory that will be used in the end.
Also there has been no validation done with the actual DSP core and the actual
memories which mean more bugs might be found.
6.3.2 Software
The PC program (Linux) has a lot of improvements to do.
As it is to day it is fixed to one RS232 device from the compilation, in an
improved version this could be set in a configuration file.
Another problem with the program is that all output data is sent to standard
output, which means that it is presented as text output in the text terminal. A
better way would be to save the data directly to output files.
A GUI interface could be nice to.
22
7 Conclusions
The hardware debug interface has been successfully developed and works nice
together with a dummy core and a dummy memory, though it has not been
tested together with the live core and the live memories.
The software manages to gather the wanted data from the DSP via RS232 and
the debug interface. The data is correctly formatted and presented the on the
screen but the software still is far from ready, this due to lack of time.
23
8 References
[1] Debug interface, internal document at Department of Electrical Engineering,
Thomas Johansson 2007
[2] Design of a debugging interface between a FPGA design and a SRAM
Device, Peter Kröger 2006, unpublished thesis at Electronics Systems,
Department of Electrical Engineering.
[3] rs232serv.c, David Björkevik, 2001
Reference literature for VHDL:
VHDL för konstruktion, Stefan Sjöholm and Lennart Lindh, Studentlitteratur
1994, 1996 Andra upplagan, ISBN 91-44-47782-1
24
Appendix 1
Area report for Stratix II FPGA
***********************************************
Device Utilization for EP2S15F484C
***********************************************
Resource
Used
Avail
Utilization
----------------------------------------------IOs
200
343
58.31%
LUTs
438
12480
3.51%
Registers
355
14410
2.46%
Memory Bits
0
419328
0.00%
DSP block 9-bit elems
0
96
0.00%
----------------------------------------------********************************************************
Library: hv_debint_m0_1
Cell: debuger
View: struct
********************************************************
Cell
Library
References
Total Area
NOT
RS232_IF1
stratixii
hv_debint_m0_1
6 x
1 x
RS232_send_if
hv_debint_m0_1
1 x
mem_ctrl
hv_debint_m0_1
1 x
read_bus
hv_debint_m0_1
1 x
read_bus_unfolded0
hv_debint_m0_1
1 x
read_bus_unfolded1
hv_debint_m0_1
1 x
stratixii_io
stratixii_lcell_comb
stratixii_lcell_ff
stratixii
stratixii
stratixii
Number
Number
Number
Number
of
of
of
of
ports :
nets :
instances :
references to this view :
Total accumulated area :
Number of IOs :
Number of LCs :
Number of LUTs :
Number of Registers :
Number of accumulated instances :
200 x
27 x
106 x
200
591
345
0
200
0
438
355
1036
62
129
0
36
63
0
93
34
39
42
0
39
42
42
39
0
1
1
1
62
129
0
36
63
0
93
34
39
42
0
39
42
42
39
0
200
27
106
Registers
LUTs
LCs
Registers
LUTs
LCs
LUTs
Registers
Registers
LUTs
LCs
Registers
LUTs
LUTs
Registers
LCs
IOs
LUTs
Registers
Appendix 2
Timing report for Stratix II
--------------------------------------------------------------------------Timing Analyzer Summary
--------------------------------------------------------------------------Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case tsu
N/A
None
4.254 ns
seriell_data_in
U_0_I0|r_tecken_3_
-clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case tco
N/A
None
9.291 ns
U_7|s_x
adress_x_out[8]
clk
-0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case tpd
N/A
None
10.274 ns
rst
x_bus[12]
--0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case th
N/A
None
-2.062 ns
y_bus[17]
U_4_U_0|r_data_temp_17_
-clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Clock Setup: 'clk'
4.549 ns
100.00 MHz ( period = 10.000 ns )
183.45 MHz ( period = 5.451 ns )
U_0_I0|r_tecken_1_
U_5_U_1_U_1_sr_0_
clk
clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Clock Hold: 'clk'
0.018 ns
100.00 MHz ( period = 10.000 ns )
N/A
U_0_sr_out_4_
U_0_sr_out_3_
clk
clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
: Total number of failed paths
:
:
:
:
:
:
:
: 0
--------------------------------------------------------------------------------------
Appendix 3
Area report for Cyclone II
***********************************************
Device Utilization for EP2C35F672C
***********************************************
Resource
Used
Avail
Utilization
----------------------------------------------IOs
200
475
42.11%
LUTs
565
33216
1.70%
Registers
336
33216
1.01%
Memory Bits
0
483840
0.00%
DSP block 9-bit elems
0
70
0.00%
----------------------------------------------****************************************************************
Library: hv_debint_m0_1_cyclone
Cell: debuger
View: struct
****************************************************************
Cell
GND
NOT
RS232_IF1
57 Registers
Library
References
cycloneii
cycloneii
hv_debint_m0_1_cyclone
Total Area
2 x
2 x
1 x
57
0
0 LCs
157
157 LUTs
RS232_send_if
36 Registers
hv_debint_m0_1_cyclone
1 x
36
123
123 LUTs
0
0 LCs
cycloneii_io_bidir_outputreg_en
72 IOs
cycloneii_io_input
62 IOs
cycloneii_io_input_inputreg
1 IOs
cycloneii_io_output
58 IOs
cycloneii_io_output_outputreg
7 IOs
cycloneii_lcell_ff
92 Registers
cycloneii_lcell_normal
22 LUTs
mem_ctrl
34 Registers
cycloneii
72 x
1
cycloneii
62 x
1
cycloneii
1 x
1
cycloneii
58 x
1
cycloneii
7 x
1
cycloneii
92 x
1
cycloneii
22 x
1
1 x
34
hv_debint_m0_1_cyclone
122
122 LUTs
0
0 LCs
read_bus
39 Registers
hv_debint_m0_1_cyclone
1 x
39
47
47 LUTs
0
0 LCs
read_bus_unfolded0
39 Registers
hv_debint_m0_1_cyclone
1 x
39
47
47 LUTs
0
0 LCs
read_bus_unfolded1
39 Registers
hv_debint_m0_1_cyclone
1 x
39
47
47 LUTs
0
0 LCs
Number
Number
Number
Number
of
of
of
of
ports :
nets :
instances :
references to this view :
Total accumulated area :
Number of IOs :
Number of LCs :
Number of LUTs :
Number of Registers :
Number of accumulated instances :
200
563
324
0
200
0
565
336
1129
Appendix 4
Timing report for Cyclone II
--------------------------------------------------------------------------Timing Analyzer Summary
--------------------------------------------------------------------------Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case tsu
N/A
None
4.798 ns
illegal_instr
U_2_r_state_2_
-clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case tco
N/A
None
12.151 ns
U_7|oe_r_w_regy
y_bus[19]
clk
-0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case tpd
N/A
None
13.091 ns
adress_y_in[14]
adress_y_out[14]
--0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Worst-case th
N/A
None
-0.220 ns
seriell_data_in
U_0_I0|nx18075z3
-clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Clock Setup: 'clk'
9.123 ns
50.00 MHz ( period = 20.000 ns )
91.94 MHz ( period = 10.877 ns )
U_0_I0|r_tecken_5_
U_5_U_1_U_1_sr_3_
clk
clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
:
:
:
:
:
:
:
:
:
Clock Hold: 'clk'
0.391 ns
50.00 MHz ( period = 20.000 ns )
N/A
U_7|mem_adress_0_
U_7|mem_adress_0_
clk
clk
0
Type
Slack
Required Time
Actual Time
From
To
From Clock
To Clock
Failed Paths
: Total number of failed paths
:
:
:
:
:
:
:
: 0
Appendix 5
Manual
How to connect hardware
Connect RS232 port on FPGA-board to RS232 port on the computer. If the
computer does not have a comport use a USB to RS232 dongle. Most Linux
distributions have native support for USB to RS232 dongles based on the FTDI
chip.
Manual control
Start a terminal program on the computer, for example miniterm under Linux.
Under settings for the chosen program select the used RS232-port (e.g. ttyS0 in
Linux of com 1 in windows) and set speed to the speed selected during
synthesising of the design (see 3.3), no parity, 8-bit ASCII blocks and local
echo.
Send instructions. See instruction list (3.4.1).
Example of instructions
Here follows some examples of how to communicate with the interface, DSP
core and memories.
How to run step a single instruction
• Send the ASCII sign “r” the interface will return either “;” for end of
instruction or “:” for end of program.
How to run the full DSP program
• Send the ASCII sign “R” the interface will return “:” when the DSP
program reaches and illegal instruction which is used for end of program.
The program can also be manually stopped by sending ASCII sign “S”.
How to load data into memory
• Start with making sure that the DSP core is in debug mode if you're not
shure send the ASCII sign “S” if the DSP was running a “;” will be
returned otherwise no return will be made.
• Now set the debug instruction to '000000' by sending “I00↲”
• Set memory address by sending “MZZZZZZ↲” where Z are hexadecimal
digits.
• Set bus data for X,Y and P buses by sending “XZZZZZZ↲”,
“YZZZZZZ↲” and “PZZZZZZ↲” wher Z are hexadecimal digits.
• To write the data from the bus into the memories send the ASCII data
“WZ↲” where Z is a hexadecimal digit. Lowest significant bit from the
word triggers the X memory to store bus value, second bit triggers the Y
memory and the third bit triggers the the P memory. The forth bit is don't
care.
How to read memory
• Start with making shure that the DSP is in debug mode and that the debug
instruction is set to '000000', similar to in writing to memory.
• Set Memory read address by sending “MZZZZZZ↲” where Z represents
memory address hexadecimally.
• Sen “GZ” where Z is a hexadecimal value similar used as for the “W”
instruction. This will copy the memory values to the data bus.
• Now send x,y or p to get the data returned from respected buses.
• The data will be returned as “ZZZZZZ;” where Z represents hexadecimal
data.
• Sen “g” to stop reading the data from the memories to the data buses and
to increment the memory adress.
How to read A0 register
• Start with making shure that the DSP is in debug mode similar to
previous.
• Set Debug instruction to '001000' (for other registers use the debug
instruction for that register instead) by sending “I08↲” (hexadecimal
version of the debuginstruction)
• Send “x” to read the register value from the data bus, the value will be
returned as “ZZZZZZ;” where Z are hexadecimal data.
Software control
Start with locating the software file “ctrlprog” and generate the two text files
called “file1.txt” and “file3.txt”. In “file1.txt” is supposed to have the ASCII
data that is needed for loading the initial data for the DSP memories and the file
“file3.txt” is supposed to have the instructions for reading the data from the DSP
memories, see Appendix 6 for an example of how these files can look.
Make sure that you have permission to connect to the RS232 interface, if not
contact the sys admin to get permission.
Run the program by typing ctrlprog in the text terminal and in the catalogue
were the 3 files are present. If you like to get the output data to a text file instead
of as on screen data use the command “ctrlprog > [file name]. See Appendix 7
for example on how output can look.
Appendix 6
Exampel of data in file1.txt
M0000
/set memory address/
X111111 /set X bus value/
Y222222 /set Y bus value/
P333333
/set P bus value/
W7
/write X, Y and P bus values to Memory address previously /
M0001
/set next memory address/
X444444 /set X bus value/
Y555555 /set Y bus value/
P666666
/set P bus value/
W7
/write X, Y and P bus values to Memory address previously /
;
/end of file/
Exampe of data in file3.txt
M 00000000000
/set memory address for first reading/
G7
/set X, Y and P buses to memory values/
p
/read P bus value/
"
"
/print new line to text termal/
x
/read X bus value/
"
"
/print new line to text termal/
y
/read Y bus value/
"
"
/print new line to text termal/
g
/tristate X, Y and P bus from mem and inc mem address/
;
/end of file/
Appendix 7
Example of output data from software
step
x=
a=
a2=
b2=
$400101000000
$0A40010C400109
x1=
$400101
x1=
$0A a1=
$0B b1=
pc= $0128
$400103
$40010C
$40010D
sr= $0138
la= $013E
lc= $013F
ssh= $013C
ssl= $013D
P:0128 400129
000000
400001
800002
y=
b=
x0=
$400103400102
$0B40010D400109
$000000
r7=
x0=
a0=
b0=
$400102
$400109
$400109
omr=
sp=
$0117
n7=
$011F
m7=
$0127
$3A
r6=
r5=
r4=
r3=
r2=
$0116
$0115
$0114
$0113
$0112
n6=
n5=
n4=
n3=
n2=
$011E
$011D
$011C
$011B
$011A
m6=
m5=
m4=
m3=
m2=
$0126
$0125
$0124
$0123
$0122
$3B
r1=
r0=
$0111
$0110
n1=
n0=
$0119
$0118
m1=
m0=
$0121
$0120
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
In English
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
© Andreas Nilsson
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement