1 |
3 |
ja_rd |
|
2 |
|
|
Until a proper design document is made, this quickstart file will help you
|
3 |
|
|
set up one of the included software demos on a development board. Plus, there's
|
4 |
|
|
a brief explanation of the cosimulation verification scheme.
|
5 |
|
|
|
6 |
|
|
All of this stuff will eventually be properly explained in a design document.
|
7 |
|
|
This file is just a stopgap until that document is written.
|
8 |
|
|
|
9 |
|
|
Software demos
|
10 |
|
|
===============
|
11 |
|
|
|
12 |
|
|
All the demos included in the project (in directory /test) come pre-compiled
|
13 |
|
|
(that is, the repository includes the object code package necessary to build the
|
14 |
|
|
system), so it isn't necessary to install any MCS51 assembler or compiler if all
|
15 |
|
|
you want to do is play a little with the core.
|
16 |
|
|
|
17 |
|
|
The demos are meant to run on a development board, for which a top vhdl entity
|
18 |
|
|
is supplied, plus a constraints file for the pin location assignment.
|
19 |
|
|
|
20 |
|
|
The only development board directly supported in the present state of this
|
21 |
|
|
project is Terasic's DE-1 board for altera Cyclone-2 FPGAs. It would be very
|
22 |
|
|
easy to port the demos to some other board, since the core uses no board
|
23 |
|
|
features other than FPGA internal resources, a serial port and a reset button
|
24 |
|
|
(plus a few LEDs that can be safely ignored).
|
25 |
|
|
|
26 |
|
|
FPGA configuration files are NOT included, so you will need a synthesis tool.
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
|
30 |
|
|
How to build one of the software demos on a development board
|
31 |
|
|
==============================================================
|
32 |
|
|
|
33 |
|
|
In order to build a demo using one of the supported development boards, you need
|
34 |
|
|
to follow the indications given in sections 1 and 2 below. Basically, you need
|
35 |
|
|
to know what source files to include and where is the pin location data.
|
36 |
|
|
|
37 |
|
|
Directory /vhdl/demos includes a subdirectory for each of the development boards
|
38 |
|
|
this project has been tested on. for each board, a 'top' entity is provided,
|
39 |
|
|
together with a pin location file and a basic test bench for the top entity.
|
40 |
|
|
|
41 |
|
|
The test bench is meant to be used with Modelsim script /sim/light52_c2sb_tb.do
|
42 |
|
|
(suitably modified and renamed for the different target boards). It is provided
|
43 |
|
|
as a convenience 'as is', in case you need to debug some basic fault on a demo.
|
44 |
|
|
|
45 |
|
|
The object code package, the tool that builds it and the cosimulation feature
|
46 |
|
|
of this project need to be explained separately, this file can't enter in any
|
47 |
|
|
more detail.
|
48 |
|
|
|
49 |
|
|
All the demos use the basic configuration of the UART, which is 19200/8/N/1, and
|
50 |
|
|
assume a clock rate of 50MHz. This is configured in the top vhdl entity.
|
51 |
|
|
|
52 |
|
|
|
53 |
|
|
1.- VHDL source files
|
54 |
|
|
------------------------
|
55 |
|
|
|
56 |
|
|
In order to build the 'Dhrystone' demo for the DE-1 board, the project should
|
57 |
|
|
include the following VHDL files:
|
58 |
|
|
|
59 |
|
|
*.- All the core vhdl files: /vhdl/*.vhdl.
|
60 |
|
|
*.- Top entity SoC file for the board: /vhdl/demos/c2sb/c2sb_soc.vhdl
|
61 |
|
|
*.- Object code package file: /test/dhrystone/obj_code_pkg.vhdl
|
62 |
|
|
|
63 |
|
|
('C2SB' here stands for 'Cyclone-2 Starter Board')
|
64 |
|
|
|
65 |
|
|
When other target boards become 'supported' by this project, suitable top
|
66 |
|
|
entities will be added to the /vhdl/demos directory.
|
67 |
|
|
|
68 |
|
|
Of course you can easily modify this c2sb_soc entity to suit your target
|
69 |
|
|
hardware.
|
70 |
|
|
|
71 |
|
|
When building some demo other than Dhrystone, the only difference is that you
|
72 |
|
|
need to use the proper object code package file. The name of the object code
|
73 |
|
|
package, and the name of the object code constant, are hardwired on the vhdl
|
74 |
|
|
top entity but they can be easily changed by editing the demo makefile. This may
|
75 |
|
|
be necessary if some project uses more than one light52 core, for instance.
|
76 |
|
|
|
77 |
|
|
|
78 |
|
|
2.- Pin location constraints
|
79 |
|
|
-------------------------------
|
80 |
|
|
|
81 |
|
|
The constraints file for the DE-1 board is in file:
|
82 |
|
|
|
83 |
|
|
*.- /vhdl/demos/c2sb/c2sb_pins.csv
|
84 |
|
|
|
85 |
|
|
When using Quartus-2, this csv file can be directly imported into the project
|
86 |
|
|
constraints.
|
87 |
|
|
|
88 |
|
|
Note that no constraints other than pin locations are used in the present
|
89 |
|
|
version of the project!
|
90 |
|
|
|
91 |
|
|
When a new board target is added to the project, the pin location file will be
|
92 |
|
|
included too; its format will depend on the target chip toochain, of course.
|
93 |
|
|
|
94 |
|
|
These top entities and constraint files are only included as a convenience to
|
95 |
|
|
build quick demos around the light52 core. A real project will not need them
|
96 |
|
|
at all.
|
97 |
|
|
|
98 |
|
|
|
99 |
|
|
|
100 |
|
|
|
101 |
|
|
How a software simulator has been used as a verification tool
|
102 |
|
|
==============================================================
|
103 |
|
|
|
104 |
|
|
This project includes a software simulator for the light52 core called b51. B is
|
105 |
|
|
for 'batch', because the simulator is not interactive; it runs from reset to
|
106 |
|
|
the end of the program (identified by a timeout or a single-instruction loop),
|
107 |
|
|
logging the execution as it goes along, and then quits.
|
108 |
|
|
|
109 |
|
|
This simulator can be found in directory /tools/b51, together with a CodeBlocks
|
110 |
|
|
project file. The simulator has been developed on Win32/Cygwin but should work
|
111 |
|
|
on Linux unmodified (only a Win32 binary is provided).
|
112 |
|
|
|
113 |
|
|
The simulator is meant to be used as a cosimulation tool: you run the same
|
114 |
|
|
program in b51 and in a Modelsim vhdl test bench.
|
115 |
|
|
Each of the simulations will log its evolution on a text file ('sw_log.txt' for
|
116 |
|
|
b51 and 'hw_sim_log.txt' for Modelsim). If the hardware model matches the
|
117 |
|
|
software model, the log files should be identical (this is a little trickier
|
118 |
|
|
than it seems, as will be explained in the design document).
|
119 |
|
|
Thus, the software model can be used as a 'golden model' of sorts.
|
120 |
|
|
|
121 |
|
|
I'm calling this scheme 'cosimulation', even though the simulations don't
|
122 |
|
|
interact directly (you have to match the log files yourself).
|
123 |
|
|
|
124 |
|
|
The b51 simulator is still not finished but it already can execute all the
|
125 |
|
|
software demos included with this project. Each demo includes a DOS BAT file
|
126 |
|
|
for launching the simulator. Until better documentation is available, you
|
127 |
|
|
are referred to those BAT files and the source code of b51 for details.
|
128 |
|
|
The log file format will also be described eventually in the design document.
|
129 |
|
|
|
130 |
|
|
|
131 |
|
|
Why a software simulator?
|
132 |
|
|
--------------------------
|
133 |
|
|
|
134 |
|
|
By using a software simulator as a 'golden model' that the hardware must match
|
135 |
|
|
closely, we can use far simpler test benches than would otherwise be necessary.
|
136 |
|
|
Besides, development and debugging become much easier and quicker.
|
137 |
|
|
|
138 |
|
|
The downside, of course, is that an accurate software model has to be developed
|
139 |
|
|
in addition to the hardware design. In this project, it has been built from
|
140 |
|
|
scratch -- and yet I think I have saved an awful lot of development time.
|
141 |
|
|
|
142 |
|
|
This scheme (software model + hardware simulation + software-only test bench)
|
143 |
|
|
is nothing new; it has been used to test new computers since at least the 70's.
|
144 |
|
|
|