LEON FAQs

HELPFUL HINTS FOR UT SoC PROJECT COMPLETION

As we did our project, we found some bugs in the LEON VHDL model, scripts and sometimes information that could lead to wrong interpretation, in the documentation and references. We thought of a need to prepare a list of "bugs" we found and fixes for them. Of course, this may not cover all errors in the source files and documentation, but this will probably help persons involved in taking this project further. Some of the tips provided here are from mailing lists. We hope it saves you the pain of reading about 2000-odd emails we had to read! We recommend persons planning to work on this project in the future to join these mailing lists [5].

Synthesis Using Synopsys FC II

Error: Elements of aggregate or string literal are
out of bounds, overlap, or do not cover all cases
in routine config line 103 in file '/home/pkurugan/leon/leon/config.vhd' (HDL-124)

Eliminate by changing

constant CREPLALG_TBL : cache_replalgbits_type := (0, 1, 0); -- # of extra bits in

to

constant CREPLALG_TBL : cache_replalgbits_type := (lru => 0, lrr => 1, rnd => 0, others => 0); -- # of extra bits in

Do NOT include fp1eu.vhd in synthesis scripts!

Are you adding master or a slave?

These instructions are for
Leon-2.3.7 and they are written as I remember them, I added several
slaves and a master to my design quite some time ago.

TARGET.VHD:

If you are adding a slave, at least the following should be checked:

Check the values in AHB_SLV_MAX, AHB_SLV_ADDR_MSB so that they suit
you. Also note that the AHB_CACHE_MAX and AHB_CACHE_ADDR_MSB affect the
cacheability of the memory space, so they might also require
modifications. You should also add a line in the "ahb_slv_config_vector"
of your used configuration (default is "ahbslvcfg_std", if I remember
correctly). You should also check the cache table associated to your
configuration ("ahbcachecfg_std" in default configuration).

If you are adding a master then do the following:

Check the value of AHB_MST_MAX. In ahb_config_type (ahb_std) you
should modify number of masters and adjust the default master.

MCORE.VHD:

You should add your device as component and bind the ports to
appropriate signals. Master input (of ahb_mst_in_type) should be binded
to ahbmi(master_index) and output (of ahb_mst_out_type)
ahbmo(master_index) signals, where master_index is the index of your
master. The processor itself is of index 0.

Similarly slave inputs (of ahb_slv_in_type) should be binded to
ahbsi(slave_index) and slave outputs (ahb_slv_out_type) to
ahbso(slave_index). Slave index should be the same as in ahb_slvcfg_std
of "TARGET.VHD".

In addition, the clock port of your component should be binded to
"clko.clk" and synchronous reset to "rst.syncrst". These are the all
required modifications that I remember right now...

Hope this helps.

On Boot PROM

--------------------------------------------------------------------
LEON PROM/Debug Design Flow Setup (Leon 1.1.10)
--------------------------------------------------------------------
First: LEON Prom implementation description is not easy to understand
and overall information does not exists!

This document gives you a little help to understand the differences.
I use Cygwin for a bash simulation which is needed by Leon LECCS
tools
and DSU Monitor.

There are some main questions:

1) Which kinds of boot configuration can I use?
2) Is there a bootloader available?
3) Debugger?
4) Problems?

To answer these questions following information exists:

1) Leon-2 User's Manual Version 1.0.10
2) Leon DSU Monitor User's Manual 1.05
3) MkProm version 1.3.6 manual
4) The Leon/ERC32 GNU Cross-Compiler System 1.1.5
5) device.vhd
6) makefile subfolder leon/pmon

---------------------------------------------------
1).Which kinds of boot configuration can I use?
---------------------------------------------------

One or two prom
Jiri Gaisler describe different kinds of boot configurations.
One prom (external OR internal) or two proms (external AND internal)
can be configured! For a better understanding the internal prom is
implemented on-chip within Leon toplevel boundaries, external prom is
placed outside the toplevel. External prom can be placed on-chip
(e.g.FPGAs) or off-chip on pcb and is connected to the Leon memory
controller.

One prom solution should be the final implementation with a external
prom for the application SW, if e.g. all tests are finished. On the
other hand one prom solution is possible for a bootloader (PMON, see
below). PMON can be implemented internal or external! It will be
instantiated while synthesis if you select in device.vhd following
options:

boot_tkconfig..->..boot..=..memory (external prom: application or
PMON)
boot_tkconfig..->..boot..=..prom (internal for PMON only)

Two prom solution is practicable for tests and SW delopment phase. A
internal prom contains a small bootloader (PMON, see below) and a
external prom contains application SW. Activation of internal or
external prom is selectable by a DIP switch (Leon PIO4):

boot_tkconfig -> boot = dual

External Prom
External prom can be used for application or for the PMON bootloader
(see below). It works as one or two prom solution. External prom
could
be a additional IC (e.g.flash) or implemented into FPGA with Xilinx
Coregenerator/*.mif flow. Conversion to external prom format is left
to the user.
For flash programming you can use sparc-rtems-objcopy to convert
application SW to S-records:

sparc-rtems-objcopy -O srec app.exe app.srec

For FPGA prom you can use bin2mif.exe to generate app.mif:

bin2mif.exe bprom.mif

The designer has to configure "device.vhd". Following settings must
be
made for extern prom boot configuration:

boot_tkconfig..->..boot..=..memory / dual

---------------------------------------------------
2).Is there a bootloader available?
---------------------------------------------------

Leon has at least two bootloader. PMON and DSU. DSU has additional
debugging options and a description is in chapter "debugger".

PMON bootloader
Leon can implement a 1kB bootloader called PMON.
PMON is a simple S-record monitor that can be placed into internal or
external prom. Two versions are provided, one to be used for internal
prom (bprom.c) and one for external proms (eprom.c). A monitor writes
a boot message to UART1 transmitter and then waits for S-records to
be
downloaded at UART1 receiver. It recognises two types of S-records:
memory contents and start address. A memory content S-record is saved
to the appropriate address in memory, while a start address record
will cause the monitor to jump to the indicated address. Applications
compiled with LECCS (elf) can be converted to a suitable S-record
stream with:

sparc-rtems-objcopy -O srec app.exe app.srec

The internal version automatically detects attached memory and
configures the memory controller register. The external version
(eprom.c) needs to be edited first to reflect the current board
configuration. Both communicate with UART 1.
Both versions must be compiled with an ELF-based compiler such as
LECCS. Within eprom.c first edit board-specific parameters, bprom.c
has no need for editing.
If in "device.vhd / syn_tkconfig / infer_rom" is true the internal
prom is build from "bprom.vhd" while synthesis. If false the internal
prom is directly instantiated with a xilinx *.mif (memory
initialisation file) while place and route.

#####Generate internal boot prom including PMON (bprom.c to
VHDL):#####
a)
Compile the internal monitor bprom.c with:
sparc-rtems-gcc -nostdlib -nostdinc -O2 -Ttext=0 bprom.c -o bprom.exe
b)
Generate bprom.bin (for rom2vhdl.exe!):
sparc-rtems-objcopy -O binary bprom.exe bprom.bin.
c)
Convert bprom.bin with rom2vhdl to rom.vhdl:
rom2vhdl bprom.bin
d)
Copy rom.vhdl to your VHDL sources and rename it to bprom.vhd. It
will
be instantiated while synthesis if you select in device.vhd following
options:
syn_tkconfig..->..infer_rom..= true (bprom.vhd is VHDL)
boot_tkconfig -> boot = dual / prom

#####Generate internal boot prom including PMON (bprom.c content is
written into xilinx ".mif" (memory initialisation file) and
implemented while P&R):#####
a)
Compile the internal monitor bprom.c with:
sparc-rtems-gcc -nostdlib -nostdinc -O2 -Ttext=0 bprom.c -o bprom.exe
b)
Generate bprom.bin (now for bin2mif.exe!):
sparc-rtems-objcopy -O binary bprom.exe bprom.bin.
c)
Convert bprom.bin with bin2mif.exe into bprom.mif:
bin2mif bprom.mif
d)
Copy bprom.mif to your P&R working directory. The content will be
implemented while P&R if you select in device.vhd following options:
syn_tkconfig -> infer_rom = false (bprom.vhd is black box)
boot_tkconfig -> boot = dual or prom
-> pabits = 8 (addressbits for 1kB PMON)

#####Generate external boot prom including PMON:#####
a)
Compile the external boatloader with:
sparc-rtems-gcc -nostdlib -nostdinc -O2 -Ttext=0 eprom.c -o eprom.exe
b)
Conversion to your external prom format is left to the user. You can
use sparc-rtems-objcopy to convert PMON to S-records:
sparc-rtems-objcopy -O srec eprom.exe eprom.srec

---------------------------------------------------
Debugger?
---------------------------------------------------

Leon has a debug support unit (DSU) which communicate with a specific
DSU UART.
On a host system you can use Leons dsumon.exe to communicate with
DSU.
You can make a little bit debugging or load application into Leon.
The
DSU will be implemented while synthesis if you select in device.vhd
following options:

apbslvcfg_tkconfig: true (DSU UART)
ahbslvcfg_tkconfig: true (DSU)
ahb_tkconfig: masters => 2 (very important!)
debug_tkconfig: dsuenable => true
dsutrace => true
tracelines => 128

--------------------------------------------------
Problems?
---------------------------------------------------

1)
makefile generates corrupted rom2vhdl.exe and bin2mif.exe (error
message within bash like "not enough memory").
2)
PMON can't communicate with host (no valid received UART1 data).
3)
External Prom (flash or on-chip) is not tested due to pmon problems.

----- FROM THE LEOX TEAM

Your LEON, fitted into your FPGA, will usually boot from its internal
bootstrap
code called PMON bprom (see file pmon/bprom.c). The size of this bootstrap is
less than 1 KByte. This program does at power-up the following things:
- Initialization of registers PSR and WIM
- Initialization of I & D Caches
- Initialization of UARTs 1 & 2
- Initialiazation of Timer 1
- Configure RAM memory access (especially MEMORY Configuration Register 2)
o RAM bus width auto-detection
o Number of RAM banks auto-detection
o Determine the size of each RAM bank
- Initialization of the Stack pointer
- Display result of the AM auto-configuration on UART1
(write a string: e.g. LEON-1: 1*4096K 32-bit memory
- Wait for your downloaded S-Record program

To download your application program into LEON's RAM, use the "send file"
feature of terminals such as HyperTerminal or TeraTerm.