Difference between revisions of "LEON 3"
(New page: ==Project Goal== The idea for the ML510 Board is outlined: 1) Have the board run a Leon3 core, with many peripherals. 2) Run an MMU-less Linux version (MMU-less so that software is SCOO...) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Project Goal== | ==Project Goal== | ||
| − | + | 1) Perform all required task to place and route the Leon3 core on the XILINX XC5VFX130T Chip on the ML510 Board. | |
| − | + | 2) Boot an MMU-less Linux version (uCLinux) (MMU-less so that software is SCOORE compatible) | |
| − | + | ||
| − | 2) | + | |
3) Create a AHB component that will allow communication with a DUT (module under test). | 3) Create a AHB component that will allow communication with a DUT (module under test). | ||
| Line 15: | Line 13: | ||
6) On error, transfer state information back to computer. | 6) On error, transfer state information back to computer. | ||
| − | 7) | + | 7) Re-run testbench with current state information -- essentially resuming from where the Leon3 left off. |
| − | 8) Fix error, | + | 8) Fix error, re-synthesize, offload to back Leon3, resume testing. |
Latest revision as of 16:27, 3 September 2009
Project Goal
1) Perform all required task to place and route the Leon3 core on the XILINX XC5VFX130T Chip on the ML510 Board.
2) Boot an MMU-less Linux version (uCLinux) (MMU-less so that software is SCOORE compatible)
3) Create a AHB component that will allow communication with a DUT (module under test).
4) Extend ATC to allow VPI testbenches to run on the Leon3
5) Current testbenches can test modules within the FPGA, running at native speeds
6) On error, transfer state information back to computer.
7) Re-run testbench with current state information -- essentially resuming from where the Leon3 left off.
8) Fix error, re-synthesize, offload to back Leon3, resume testing.
Essentially, an HDL module would be tested in hardware. This allows speeds in excess of 100MHz, much faster than the 10KHz simulation speed of PC based simulators.
By saving state information for the last 1000 cycles for example, the hope is that by "rewinding" back that far, the bug can be reproduced.
Using VCS or Modelsim for simulation, debugging can ensue.
The hardware is used to allow acceleration of HDL verification. If more transparency is needed, either FPGA based scopes such as ChipScope can be used, or switching to the PC simulator can happen almost transparently. The end goal is to save time in discovering the presence of bugs, and to focus mostly on debugging the bugs themselves.
A mechanism such as DSP-Builder's Hardware in the Loop (HIL) allows for the instantiation of a module within the fpga, while the logic to interface with it is created by the tool automatically. The main difference is that our design executes the testbench on the FPGA as well, saving bandwidth and potential problems in interfacing the PC to the module.
Programming Board
using grmon: add to path - #export PATH=$PATH:/home/tom/leon3/grmon-eval/linux add libjtag.so from quartus 32 bit #export LD_LIBRARY_PATH=/software/altera/quartus/linux
envoke grmon, #grmon-eval -altjtag
To use grmon-rcp, libwidget_gtk2.so 32 bit needs to be present
A 32-bit Java also need to be used Install 32 bit openjdk Switch from 64 to 32 bit java #alternatives --config java #alternatives --config javac
