1 |
100 |
arniml |
|
2 |
|
|
README for the T400 uController project
|
3 |
|
|
=======================================
|
4 |
151 |
arniml |
Version: $Date: 2006-06-12 00:09:56 $
|
5 |
100 |
arniml |
|
6 |
|
|
|
7 |
|
|
Introduction
|
8 |
|
|
------------
|
9 |
|
|
|
10 |
151 |
arniml |
The T400 µController is an implementation of National's 4-bit COP400
|
11 |
|
|
microcontroller family architecture. It is intended to be used as a
|
12 |
|
|
replacement for the original chip in SOCs recreating legacy systems.
|
13 |
|
|
Its final target is to provide design variants that are compatible with the
|
14 |
|
|
COP420/421 and COP410L/411L family members. All of them derived from the
|
15 |
|
|
common t400_core design.
|
16 |
100 |
arniml |
|
17 |
122 |
arniml |
|
18 |
100 |
arniml |
Download
|
19 |
|
|
--------
|
20 |
|
|
|
21 |
|
|
Download the latest stable release from the project homepage at OpenCores.org:
|
22 |
|
|
|
23 |
|
|
http://www.opencores.org/projects.cgi/web/t400/overview/
|
24 |
|
|
|
25 |
|
|
You can get the latest version of the design files from CVS:
|
26 |
|
|
|
27 |
|
|
http://www.opencores.org/pdownloads.cgi/list/t400
|
28 |
|
|
|
29 |
|
|
Please keep in mind that this is work in progress and might contain smaller or
|
30 |
|
|
bigger problems.
|
31 |
|
|
You should also check the Tracker for known bugs and see if they affect your
|
32 |
|
|
work.
|
33 |
|
|
|
34 |
|
|
|
35 |
|
|
Installation
|
36 |
|
|
------------
|
37 |
|
|
|
38 |
|
|
Once the directory structure is generated either by check-out from CVS or by
|
39 |
|
|
unpacking the tar-archive, the central project initialization file should be
|
40 |
|
|
set up. A template called init_project.template.sh is located in the sw
|
41 |
|
|
directory where a copy can be edited. Normally, only the definition for the
|
42 |
|
|
variable PROJECT_DIR has to be adjusted to the path where the directory
|
43 |
|
|
structure is located.
|
44 |
|
|
The commands for setting the necessary variables assume a bash/sh-like
|
45 |
|
|
shell. In case you run a different shell like csh or ksh, you should adjust
|
46 |
|
|
these commands as well.
|
47 |
|
|
|
48 |
|
|
The meaning of the variables is as follows:
|
49 |
|
|
|
50 |
|
|
* PROJECT_DIR
|
51 |
|
|
Points to the root of the project installation. All further references are
|
52 |
|
|
derived from its setting.
|
53 |
|
|
|
54 |
|
|
* MAKEFILES
|
55 |
|
|
Identifies the global Makefile for compilation of tests.
|
56 |
|
|
|
57 |
|
|
These variables must be properly set whenever scripts or makefiles of the T400
|
58 |
|
|
project are executed that are related to verification tasks. Otherwise, you
|
59 |
|
|
will most likely encounter error messages.
|
60 |
|
|
|
61 |
|
|
NOTE: The concepts of the mentioned shells require that the init_project.sh is
|
62 |
|
|
run in the context of the shell. I.e. you should 'source' the script
|
63 |
|
|
instead of executing it like a command. This will make sure that the
|
64 |
|
|
variable settings are really effective in the calling shell instance.
|
65 |
|
|
|
66 |
|
|
|
67 |
|
|
Directory Structure
|
68 |
|
|
-------------------
|
69 |
|
|
|
70 |
|
|
The project's directory structure follows the proposal of OpenCores.org.
|
71 |
|
|
|
72 |
|
|
t400
|
73 |
|
|
|
|
74 |
|
|
\--+-- rtl
|
75 |
|
|
| |
|
76 |
122 |
arniml |
| +-- vhdl : VHDL code containing the RTL description
|
77 |
|
|
| | | of the core.
|
78 |
|
|
| | \-- system : RTL VHDL code of sample systems.
|
79 |
|
|
| |
|
80 |
|
|
| \-- tech : Technology specific files.
|
81 |
|
|
| |
|
82 |
|
|
| +-- cyclone : Cyclone technology flavor.
|
83 |
|
|
| |
|
84 |
|
|
| +-- spartan : Spartan technology flavor.
|
85 |
|
|
| |
|
86 |
|
|
| \-- generic : Generic RTL designs.
|
87 |
100 |
arniml |
|
|
88 |
|
|
+-- bench
|
89 |
|
|
| |
|
90 |
|
|
| \-- vhdl : VHDL testbench code.
|
91 |
|
|
|
|
92 |
|
|
+-- sim
|
93 |
|
|
| |
|
94 |
|
|
| \-- rtl_sim : Directory for running simulations.
|
95 |
|
|
|
|
96 |
|
|
\-- sw : General purpose scripts and files.
|
97 |
|
|
|
|
98 |
|
|
\-- verif : The verification suite.
|
99 |
|
|
|
|
100 |
|
|
+-- include : Global includes and makefiles.
|
101 |
|
|
|
|
102 |
|
|
+-- black_box : Black-box verification tests.
|
103 |
|
|
|
|
104 |
122 |
arniml |
+-- int : Interrupt verification tests.
|
105 |
|
|
|
|
106 |
|
|
\-- system : General system level tests.
|
107 |
100 |
arniml |
|
108 |
|
|
|
109 |
|
|
Compiling the VHDL Code
|
110 |
|
|
-----------------------
|
111 |
|
|
|
112 |
|
|
VHDL compilation and simulation tasks take place inside in sim/rtl_sim
|
113 |
|
|
directory. The project setup supports only the batch mode of certain
|
114 |
|
|
simulators. However, there should be no problems to integrate the testbench
|
115 |
|
|
and RTL code into arbitrary simulation environments.
|
116 |
|
|
|
117 |
|
|
The main file for compilation is Makefile which contains all information
|
118 |
|
|
regarding the dependencies of the source files and their compilation
|
119 |
|
|
order.
|
120 |
|
|
|
121 |
|
|
Compilation is based on the make-utility, thus invocation looks like this:
|
122 |
|
|
|
123 |
|
|
$ make
|
124 |
|
|
|
125 |
|
|
This will call ghdl to analzye and elaborate the complete design hierarchy.
|
126 |
|
|
|
127 |
|
|
Tristan Gingold's GHDL simulator/compiler, a VHDL front-end for gcc.
|
128 |
|
|
http://ghdl.free.fr/
|
129 |
|
|
|
130 |
|
|
Make will analyze all VHDL files (RTL and testbench code) and elaborate all
|
131 |
142 |
arniml |
testbench top-levels:
|
132 |
100 |
arniml |
|
133 |
148 |
arniml |
* tb_t410_behav_c0
|
134 |
|
|
Testbench for the T410 derivative.
|
135 |
|
|
It instantiates the T410 system toplevel and is intended to exectue all
|
136 |
|
|
verifcation tests tagged with 't41x'.
|
137 |
|
|
|
138 |
|
|
* tb_t411_behav_c0
|
139 |
100 |
arniml |
Testbench for the T411 derivative.
|
140 |
|
|
It instantiates the T411 system toplevel and is intended to exectue all
|
141 |
|
|
verifcation tests tagged with 't41x'.
|
142 |
|
|
|
143 |
|
|
* tb_t420_behav_c0
|
144 |
|
|
The testbench for the T420 derivative.
|
145 |
|
|
It instantiates the T420 system toplevel and is intended to execute all
|
146 |
142 |
arniml |
verification tests tagged with 't42x' and 't420'.
|
147 |
|
|
|
148 |
|
|
* tb_t421_behav_c0
|
149 |
|
|
The testbench for the T421 derivative.
|
150 |
|
|
It instantiates the T421 system toplevel and is intended to execute all
|
151 |
100 |
arniml |
verification tests tagged with 't42x'.
|
152 |
|
|
|
153 |
|
|
* tb_int_behav_c0
|
154 |
|
|
The testbench for the interrupt verification suite.
|
155 |
|
|
It instantiates the T420 system topevel and is intended to execute all
|
156 |
|
|
verification tests tagged with 'int'.
|
157 |
|
|
|
158 |
122 |
arniml |
* tb_microbus_behav_c0
|
159 |
|
|
The testbench for the microbus verification.
|
160 |
|
|
It instantiates the T420 system toplevel in microbus configuration and is
|
161 |
|
|
intended to execute all verifications tests tagged with 'mb'.
|
162 |
|
|
|
163 |
142 |
arniml |
* tb_prod_behav_c0
|
164 |
|
|
The testbench for the production test.
|
165 |
|
|
It instantiates the T420 system toplevel an checks D and P output ports
|
166 |
|
|
for the patterns generated by the software as proposed in
|
167 |
|
|
"Testing of COP400 Familiy Devices"
|
168 |
|
|
National Semiconductor
|
169 |
|
|
COP Note 7
|
170 |
|
|
April 1991
|
171 |
|
|
|
172 |
100 |
arniml |
The Makefile has a 'clean' target to delete all intermediate data:
|
173 |
|
|
|
174 |
|
|
$ make clean
|
175 |
|
|
|
176 |
|
|
The basic simple sequence list can be found in COMPILE_LIST. This can be
|
177 |
|
|
useful to quickly set up the analyze stage of any compiler or
|
178 |
|
|
synthesizer. Especially when synthesizing the code, you want to skip the VHDL
|
179 |
|
|
configurations in *-c.vhd and everything below the bench/ directory.
|
180 |
|
|
|
181 |
122 |
arniml |
|
182 |
100 |
arniml |
Preparation of the ROM Files
|
183 |
|
|
----------------------------
|
184 |
|
|
|
185 |
|
|
All testbenches listed above load the internal ROM of the controller from a
|
186 |
|
|
file in hex-format. Its existance is mandatory as it is referenced in the
|
187 |
|
|
VHDL code of the ROM model lpm_rom.vhd. In case it is missing, the
|
188 |
|
|
simulation will stop immediately after elaborating the design.
|
189 |
|
|
|
190 |
|
|
These files are:
|
191 |
|
|
|
192 |
|
|
* rom_41x.hex
|
193 |
|
|
Program ROM compiled for the T41x derivatives. Maximum size 512 bytes.
|
194 |
|
|
Referenced by the t410_notri system.
|
195 |
|
|
Enabled by the 't41x' tag.
|
196 |
|
|
|
197 |
|
|
* rom_42x.hex
|
198 |
|
|
Program ROM compiled for the T42x derivatives. Maximum size 1024 bytes.
|
199 |
|
|
Referenced by the t420_notri system.
|
200 |
142 |
arniml |
Enabled by the 't42x', 't420', 'int', 'mb' and 'prod' tag.
|
201 |
100 |
arniml |
|
202 |
|
|
The verification flow for the T400 project generates these two files
|
203 |
|
|
automatically from the assembler source files. Whenever the make process
|
204 |
|
|
locates one or more of the above tags, it assembles and links the source code
|
205 |
|
|
for the repsective derivative.
|
206 |
|
|
|
207 |
|
|
All regression tests and the general purpose software is organized in a cell
|
208 |
|
|
structure. Currently, this means that the software for a cell is contained in
|
209 |
|
|
a dedicated directory where the assembler run takes place. In the future,
|
210 |
|
|
there will be more aspects to a cell.
|
211 |
|
|
|
212 |
|
|
Assembling, linking and putting the hex-files in place is under the control of
|
213 |
|
|
the make-mechanism. E.g. to assemble the source code of a cell, issue the
|
214 |
|
|
following command:
|
215 |
|
|
|
216 |
|
|
$ make
|
217 |
|
|
|
218 |
|
|
The above mention environment variable MAKEFILES enables execution of the make
|
219 |
|
|
process from within any subdirectory in the verification tree. This generates
|
220 |
|
|
the linker file (test_41x.p and test_42x.p) and derives hex-files which are
|
221 |
|
|
placed into the simulation directory. So most likely, for running a test case
|
222 |
|
|
or any other software, you will want to issue:
|
223 |
|
|
|
224 |
|
|
The only supported assembler is Alfred Arnold's macroassembler AS. See
|
225 |
|
|
|
226 |
|
|
http://john.ccac.rwth-aachen.de:8000/as/
|
227 |
|
|
|
228 |
|
|
|
229 |
|
|
Verification Environment
|
230 |
|
|
------------------------
|
231 |
|
|
|
232 |
|
|
The verification environment consists of a number of test programs. They are
|
233 |
|
|
all self-checking. I.e. after testing the targeted functionality, they emit a
|
234 |
|
|
pass/fail information. This information is detected by the testbench which
|
235 |
|
|
stops the simulation and prints out the simulation result. This is the default
|
236 |
|
|
mechanism for stopping the VHDL simulation.
|
237 |
|
|
|
238 |
|
|
Pass/fail is signalled by a certain sequence of the L port contents:
|
239 |
|
|
(R denotes an optional value stored in A when calling the pass or fail
|
240 |
|
|
routines)
|
241 |
|
|
|
242 |
|
|
1) L outputs 0x0R
|
243 |
|
|
2) L outputs 0xaR
|
244 |
|
|
3) L outputs 0x5R
|
245 |
|
|
4) L outputs 0x0R -> Pass
|
246 |
|
|
L outputs 0xfR -> Fail
|
247 |
|
|
|
248 |
|
|
The detection is modelled like a state machine and in case the sequence is of
|
249 |
|
|
bytes inside the accumulator does not match, the detection process restarts
|
250 |
|
|
from the beginning. This mechanism is part of all verification tests except
|
251 |
|
|
for the interrupt testbench.
|
252 |
|
|
|
253 |
|
|
The complete regression suite can be executed with the run_regression.pl
|
254 |
|
|
script. For each test cell, it steps through the sequence
|
255 |
|
|
|
256 |
|
|
1) Assemble the source code
|
257 |
|
|
2) Run the compiled VHDL design (currently only GHDL)
|
258 |
|
|
|
259 |
|
|
It is highly recommended to redirect the output of run_regression.pl into a
|
260 |
|
|
file. Otherwise, analyzing the messages related to each test cell is almost
|
261 |
|
|
impossible.
|
262 |
122 |
arniml |
|
263 |
|
|
|
264 |
|
|
Clocking System
|
265 |
|
|
---------------
|
266 |
|
|
|
267 |
|
|
The main clock is supplied at input ck_i. To ease system integration, ck_i can
|
268 |
|
|
accept integer multiples of the target clock frequency. Input ck_en_i is used
|
269 |
|
|
to qualify rising edges on ck_i as active clock edges. When ck_i is supplied
|
270 |
|
|
with the target frequency, ck_en_i can be kept high constantly.
|
271 |
|
|
|
272 |
|
|
|
273 |
148 |
arniml |
Generic Parameters
|
274 |
|
|
------------------
|
275 |
122 |
arniml |
|
276 |
148 |
arniml |
Most generic parameters are provided to set the numerous I/O options. Thus
|
277 |
|
|
such options are exhibited on the toplevel designs.
|
278 |
|
|
All generics are implemented with integer types to enable analysis of the RTL
|
279 |
|
|
code without tool restrictions. The related constants are defined in
|
280 |
|
|
t400_opt_pack-p.vhd.
|
281 |
|
|
|
282 |
|
|
opt_type_g : Derivative type - T420, T421, T410, T411
|
283 |
|
|
opt_ck_div_g : Internal divider on CK
|
284 |
|
|
opt_cko_g : Enable CKO as general purpose input
|
285 |
|
|
opt_l_out_type_7_g : Output driver type L[7]
|
286 |
|
|
opt_l_out_type_6_g : Output driver type L[6]
|
287 |
|
|
opt_l_out_type_5_g : Output driver type L[5]
|
288 |
|
|
opt_l_out_type_4_g : Output driver type L[4]
|
289 |
|
|
opt_l_out_type_3_g : Output driver type L[3]
|
290 |
|
|
opt_l_out_type_2_g : Output driver type L[2]
|
291 |
|
|
opt_l_out_type_1_g : Output driver type L[1]
|
292 |
|
|
opt_l_out_type_0_g : Output driver type L[0]
|
293 |
|
|
opt_microbus_g : Enable MICROBUS interface
|
294 |
|
|
opt_d_out_type_3_g : Output driver type D[3]
|
295 |
|
|
opt_d_out_type_2_g : Output driver type D[2]
|
296 |
|
|
opt_d_out_type_1_g : Output driver type D[1]
|
297 |
|
|
opt_d_out_type_0_g : Output driver type D[0]
|
298 |
|
|
opt_g_out_type_3_g : Output driver type G[3]
|
299 |
|
|
opt_g_out_type_2_g : Output driver type G[2]
|
300 |
|
|
opt_g_out_type_1_g : Output driver type G[1]
|
301 |
|
|
opt_g_out_type_0_g : Output driver type G[0]
|
302 |
|
|
opt_so_output_type_g : Output driver type SO
|
303 |
|
|
opt_sk_output_type_g : Output driver type SK
|
304 |
|
|
|
305 |
|
|
|
306 |
122 |
arniml |
FPGA Implementation
|
307 |
|
|
-------------------
|
308 |
|
|
|
309 |
|
|
All of the design files contain pure RTL code. This is true even for the
|
310 |
|
|
technology specific power-on reset module. Two flavors exist, each of them
|
311 |
|
|
implementing the desired behavior in a way that is understood by the design
|
312 |
|
|
tools. The RAM for the data memory is described by generic RTL code as
|
313 |
|
|
well. It should be translated automatically by the tool chain to a technology
|
314 |
|
|
specific RAM macro.
|
315 |
|
|
|
316 |
|
|
There is a generic method for the program memory ROM as well, although this
|
317 |
|
|
project uses a flow where hex-files are loaded by lpm_rom.vhd as the default
|
318 |
|
|
method. Convert the ROM image to an RTL VHDL file with one of the two
|
319 |
|
|
following commands (either from hex or bin format):
|
320 |
|
|
|
321 |
|
|
$ hex2rom -b [rom image file] rom_t41x 9l8s > rom_t41x.vhd
|
322 |
|
|
$ hex2rom -b [rom image file] rom_t42x 10l8s > rom_t42x.vhd
|
323 |
|
|
|
324 |
|
|
The option -b specifies that contains binary data. Skip this
|
325 |
|
|
option to process a file in hex format.
|
326 |
|
|
|
327 |
|
|
These resulting RTL representations are instantiated by t410_rom-struct-a.vhd
|
328 |
|
|
and t420_rom-struct-a.vhd. Altera and Xilinx design tools will detect and
|
329 |
|
|
extract the ROM and turn it into a memory macro.
|