OpenCores
URL https://opencores.org/ocsvn/light52/light52/trunk

Subversion Repositories light52

[/] [light52/] [trunk/] [doc/] [quickstart.txt] - Blame information for rev 10

Details | Compare with Previous | View Log

Line No. Rev Author Line
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 10 ja_rd
The project includes ready-made support files for the following development
18
boards:
19 3 ja_rd
 
20 10 ja_rd
* Terasic's DE-1 (Cyclone-2):           directory /boards/terasic_de1
21
* Avnet's Spartan-3A Evaluation Kit:    directory /boards/avnet_s3aeval
22 3 ja_rd
 
23 10 ja_rd
For each board, the following is supplied:
24 3 ja_rd
 
25 10 ja_rd
1.- A suitable project file is included for Quartus-2 or ISE Webpack.
26
2.- A 'top entity' VHDL module with a light52 MCU instance connected to
27
    the on-board devices (most of which are unused).
28
3.- A constraints file, including the pin locations. This info is already in
29
    the project file but is supplied separately for convenience.
30 3 ja_rd
 
31
 
32 10 ja_rd
The project files in all cases use the object code package from the Dhrystone
33
demo. It is trivially easy to set up the project for some other demo: replace
34
the object code package (file obj_code_pkg.vhdl).
35 3 ja_rd
 
36 10 ja_rd
The demos only use a serial port connector (when available) and some LEDs and
37
7-segment displays (when available). It would be very easy to port the demos
38
to some other development board.
39 3 ja_rd
 
40 10 ja_rd
FPGA configuration files are NOT included, so you will need a synthesis tool.
41 3 ja_rd
 
42
 
43
 
44
How a software simulator has been used as a verification tool
45
==============================================================
46
 
47
This project includes a software simulator for the light52 core called b51. B is
48
for 'batch', because the simulator is not interactive; it runs from reset to
49
the end of the program (identified by a timeout or a single-instruction loop),
50
logging the execution as it goes along, and then quits.
51
 
52
This simulator can be found in directory /tools/b51, together with a CodeBlocks
53
project file. The simulator has been developed on Win32/Cygwin but should work
54
on Linux unmodified (only a Win32 binary is provided).
55
 
56
The simulator is meant to be used as a cosimulation tool: you run the same
57
program in b51 and in a Modelsim vhdl test bench.
58
Each of the simulations will log its evolution on a text file ('sw_log.txt' for
59
b51 and 'hw_sim_log.txt' for Modelsim). If the hardware model matches the
60
software model, the log files should be identical (this is a little trickier
61
than it seems, as will be explained in the design document).
62
Thus, the software model can be used as a 'golden model' of sorts.
63
 
64
I'm calling this scheme 'cosimulation', even though the simulations don't
65
interact directly (you have to match the log files yourself).
66
 
67
The b51 simulator is still not finished but it already can execute all the
68
software demos included with this project. Each demo includes a DOS BAT file
69
for launching the simulator. Until better documentation is available, you
70
are referred to those BAT files and the source code of b51 for details.
71
The log file format will also be described eventually in the design document.
72
 
73
 
74
Why a software simulator?
75
--------------------------
76
 
77
By using a software simulator as a 'golden model' that the hardware must match
78
closely, we can use far simpler test benches than would otherwise be necessary.
79
Besides, development and debugging become much easier and quicker.
80
 
81
The downside, of course, is that an accurate software model has to be developed
82
in addition to the hardware design. In this project, it has been built from
83
scratch -- and yet I think I have saved an awful lot of development time.
84
 
85
This scheme (software model + hardware simulation + software-only test bench)
86
is nothing new; it has been used to test new computers since at least the 70's.
87
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.