LEOX home page Free Hardware and Software Resources for System on Chip


News & Stats
Contact Us
Want to help
Mailing list
 

FAQ
HOWTO
mini-HOWTO
 

Development Tools
Hardware IPs
Software IPs
 

Please find underneath the following development tools:

  1. The LEOX Cross Development Kit that will help you install an Open Source compiler/debugger and related technologies.
  2. The DRAGONFLY micro core that will make design of new IP blocks easier, and will try to standardize IP's I/O interfaces.
    The idea behind is to ensure the "IP reuse" notion and the "Plug and Play" aspect of IPs.


Development Tools: LEOX Cross Development Kit (CDK)


LEOX Cross Development Kit: Summary
Description The LEOX Cross Development Kit (CDK) automagically compiles and installs
the dedicated LEOX project development environment from all required
source packages.
Documentation How to build a SPARC-based cross development environment
Latest Version leox-CDK-1.0.18.tar.gz      (Updated: 2003 Jun 22nd)

Please see the ChangeLog file for modifications
Licence(s) GNU General Public Licence (GPL) for the leox-CDK-1.0.18 package
Author(s) The LEOX team
Related Link(s) none

The LEOX Cross Development Kit (CDK) automagically builds the following packages:

  • Cross-compiler from the latest binutils-2.14 / gcc-2.95.3 sources.
  • Cross-debugger from the latest insight-5.3 source.
  • The TSIM/LEON remote SPARC simulator, version 1.1.6 (evaluation version is provided under the TSIM evaluation license).
  • 2 tools useful for uClinux compilation:
    • genromfs - create a ROM file system image.
    • elf2flt      - convert ELF to FLAT binary format.
  • SPARC-based C starter code (crt0) useful for uClinux userland applications.

How to install the Cross Development Kit

You do not need to be the root user to install this CDK. Once you are inside your top level directory, let say [ROOT_DIR], un-archive the LEOX CDK by executing the following command:

  1. tar xzvpf leox-CDK-1.0.18.tar.gz

Thus you will get into the directory called leox-CDK-1.0.18 the following structure:

    -rw-r--r--       15127 jun 17 2000  COPYING       text of the GNU GENERAL PUBLIC LICENSE
    -rw-r--r--        2605 jun  1 10:41 ChangeLog     contains the history of all modifications
    -rw-r--r--        3995 may 24 20:35 Makedefs      contains the environment profile
    -rw-r--r--        7374 jun  1 10:54 Makefile      contains all methods to compile/install this CDK
    -rw-r--r--        3966 jun  1 12:51 README.LEOX   read this file first
    drwxr-xr-x        4096 apr 29 16:19 patches/      directory containing patch files
    drwxr-xr-x        4096 may 17 16:41 tarballs/     directory containing all sources packages
    -rw-r--r--        6063 feb 15 13:54 tsimlic.txt   *** TSIM STANDARD LICENSE ***

Due to a lack of our download space capacity, you are invited to grab through FTP the following packages:

  1. grab tarballs/binutils-2.14.tar.gz (11.7 MB) from
          ftp://ftp.gnu.org/pub/gnu/binutils/binutils-2.14.tar.gz
    grab tarballs/gcc-core-2.95.3.tar.gz (8.5 MB) from
          ftp://ftp.gnu.org/pub/gnu/gcc/gcc-2.95.3/gcc-core-2.95.3.tar.gz
    grab tarballs/insight-5.3.tar.gz (22.1 MB) from
          ftp://sources.redhat.com/pub/gdb/releases/insight-5.3.tar.gz

This LEOX Cross Development Kit compiles and installs automagically all source packages specified into the environment profile: Makedefs. It builds the cross development toolchain into the [ROOT_DIR]/gnu directory. You shouldn't have to modify the Makefile.

Once you have the files listed in the previous section, follow the instructions:

  1. cd leox-CDK-1.0.18
  2. Edit Makedefs and modify to your need the macro: ROOT_DIR
  3. make

Once all packages are compiled and installed, you need to add:

  • [ROOT_DIR]/gnu/bin to your PATH environment variable.
  • [ROOT_DIR]/gnu/man to your MANPATH environment variable.
Now, you are ready to enjoy the LEOX cross development environment.


Development Tools: DRAGONFLY micro core


DRAGONFLY: Summary
Description The DRAGONFLY is not a general-purpose micro processor but rather a
flexible controller that can perform complex state-machines execution.
The aim of the DRAGONFLY is to make design of new IP blocks easier.
The DRAGONFLY implements a full instruction set.
Documentation The DRAGONFLY 1 micro core      (70 pages)
Latest Version dragonfly-1.2.tar.gz      (Updated: 2002 May 31st)

Please see the ChangeLog file for modifications
Licence(s) GNU Lesser General Public Licence (LGPL)      (for the VHDL source code)
Author(s) The LEOX team
Related Link(s) none

The DRAGONFLY micro core has been designed as a small (less than 4K gates), fast and programmable core, to be used in an ASIC or a FPGA, in areas such as serial communication management (UART, Smart cards controllers, LDC drivers, IC controllers, SPI controllers), on-chip test and debug of complex blocks, intelligent DMA, FLASH controllers, audio-rate SDRAM controllers, and so on.

The advantages of having a programmable core on an ASIC to perform complex tasks are obvious:

  • writing and debugging software code is faster than designing the same function in hardware.
  • it is possible to reload the software in the ASIC, to correct bugs or change the functionality.

The Dragonfly core however, is not well suited to be used as a general purpose processor. It has no interrupt mechanism (this has been chosen for simplicity of implementation), and as such it can't handle true real-time tasks (those tasks should be handled inside a peripheral if needed). The core has no multiply/divide instruction, and its arithmetic capability are basic.

The philosophy behind the core is that, real-time and complex arithmetic tasks are handled inside adapted peripherals (serial interfaces, FIFOs, Arithmetic operators, Timers, etc.), while the core itself is responsible for peripheral configuration, data motion and interpretation, complex state machine emulation, complex decisions calculations.

Writing software for the DRAGONFLY is done using a simple, easy to use and easy to learn assembly language. Available software tools are:

  • a complete macro assembler (that runs on Linux, Solaris and Windows).
  • an Emacs mode for easy assembly code edition.
  • a tcl/Tk based debugger to be used (only) with the Modelsim VHDL simulator.

Description of the DRAGONFLY micro core

The DRAGONFLY core is a simple 3 stage pipeline with a true Harvard-like architecture (data and program memory are separated and accessed in parallel). Instructions are 16 bits wide, while data are only 8 bit wide.

The DRAGONFLY implements a full instruction set such as:
  • ALU operations.
  • Shift operations.
  • Bit operations.
  • Branch operations.
  • Data Transfer operations.
  • FIFO operations.
  • Simplified Mnemonics.
  • Low power and sleep mode.
First stage of the pipeline is program memory access, second stage
decodes the instruction and execute it, third stage is data memory
access.

As a consequence of this architecture, the data in memory are
accessed by LOAD instructions with 1 cycle of latency, while most
instructions are allowed to store directly their result in memory
with no latency.

The DRAGONFLY has 2 set of registers :
  • the address registers (I, J, K, L)
  • the ALU registers (OP0, OP1, OP2)
Most instructions allows parallel access to both set of registers,
for instance it is possible to compute an ADD between 2 ALU
registers, and simultaneously to access and modify an address
register to compute the address where the result will be stored.
DRAGONFLY: Architecture Overview
Click on this figure to enlarge

Address registers are 8 bit wide and are used to generate address to access data memory. So the data memory can have at most 256 locations. If more memory is to be used, one must implement a paged memory access with a page register mapped in the IO space.

ALU registers are 8 bit wide but have been designed to manipulate 16, 24 and 32 bit data efficiently. The registers can be used as "normal" registers, but also, they can be used as 4 bytes FIFOs that holds up to a complete 32 bit word. Once in the FIFO, a multi-byte word can be manipulated with most ALU operation, one byte at a time.

S register is the status register and holds 8 status bits.

Program memory access is done through 2 combined registers: a 11 bits PC, and a 5 bits page selector PG. The PG register gives the 5 MSB of the instruction address, while the 11 LSB are given by the PC. This gives up to 64K accessible instructions.
The PC is automatically incremented each cycle, and can be changed by either relative branch or absolute jump instructions. However, PG is not automatically modified, so for instance the PC may wrap around from 7FF to 000 without affecting the page number.
PG can be changed only with the SNP ("set next page") instruction, combined with a JUMP instruction.
The 11 bits of the PC plus the 5 bits of the PG can be saved/restored from memory to implement function call and return through different pages.

No interruption mechanism exists, but the Ex bit in the S register can be used to signal the occurrence of an external event (however it must be tested explicitly by the program).

An external IO bus, separated from the data memory bus and accessed through IO LOAD and IO STORES links the DRAGONFLY to its peripherals.

How to run the testbench using Mentor Modelsim simulator

Unarchive the downloaded file. Thus, you should get a dragonfly-1.2 directory with everything inside.

  1. tar xzvpf dragonfly-1.2.tar.gz

Launch the gui of the Mentor Modelsim simulator:

  1. vsim - gui
  2. Change the working directory to dragonfly-1.2

If you don't have a work library defined, do it now on the Modelsim console:

  1. vlib work
  2. vmap work work

If you are on a PC computer, edit the file dgf.do and change the line:

exec dgfas_sun -h -g "$test_name.dgf"
   to
exec dgfas_pc.exe -h -g "$test_name.dgf"

Note: under Linux, replace dgfas_sun by dgfas_linux

On the Modelsim console, type the following command:

  1. do dgf.do

The core is compiled, and simulation is started.
Run the simulation for some time.
Give a look to the debugger window, try to move forward/backward.
You are done!

How to change the software being tested

Modify the following line into the dgf.do file:

set test_name test_dgf_branch_op

Note: test_name is the tcl variable holding the name of the *.dgf file to be compiled and run.

How to install the DGF mode under Emacs

Add the following lines to your .emacs file:

(load "/YOUR_HOME_DIR/dragonfly-1.2/dgf.el")
(setq auto-mode-alist (append '(("\\.dgf$" . dgf-mode)) auto-mode-alist))

Note: Replace YOUR_HOME_DIR by the name of your home directory.

Thus you will get a new DGF item inside the menu bar of Emacs while editing a DGF source file.

How to compile a DGF source file

  1. Edit your DGF source file under Emacs
  2. Inside the DGF item of the Emacs's menu bar, define assembler path
  3. Use the DGF subitems to compile your source file and to generate the appropriate output files.



LEOX.org - Free Hardware and Software resources for System on Chip
Copyright © 2000,2001 by The LEOX team
Ideas, requests, problems regarding LEOX.org? Send feedback.
Last modification: 2003/6/23 at 21:26
All brands and product names may be trademarks of their respective owners.
All information is provided "as is", there is no warranty that the information is correct or suitable for any purpose, neither implicit nor explicit.