SLAAC1-V JHDL Model

Table of Contents

1. Introduction

2. The cell_interface for pelca
3. Using the Makefiles

4. Hardware Mode
5. SLAAC1-V Example Designs

This web page is a weak effort to document some key issues dealing with the SLAAC1-V JHDL model. This information is chiefly for the version of the SLAAC1-V model which is compatible with version 0.2.35. Later versions have a new memory drop-in which is not documented or supported here.

You can download the latest JDK-1.1.8-compiled slaac1v.jar from the following address: http://www.jhdl.org/release-latest/release/slaac1v/slaac1v-0.2.35.jar These should work O.K. with version 0.2.35 of JHDL found at www.jhdl.org. (http://www.jhdl.org/release-latest/bleedingedge.html)

The Makefiles for a JHDL SLAAC1-V project can be found at: http://jhdl.ee.byu.edu/release-latest/release/slaac1v/slaac1v-jhdl-Makefiles-2000-11-21.tar.gz

Here is the cell_interface for byucc.jhdl.platforms.slaac1v.pelca for the version of the SLAAC1-V model which is compatible with version 0.2.35 of JHDL:

  public static CellInterface cell_interface[] = {
  
    in("XP_RESET",1),//0
    // ring ports
    inout("XP_LEFT" ,72),//1
    inout("XP_RIGHT",72),//2
    inout("XP_XBAR" ,72),//3
    // handshake ports
    inout("XP_HDSKX0",2),//4
    inout("XP_HDSKXP",2),//5
    inout("XP_HDSKIF",3),//6
    // LED PORT
    out("XP_LED", 4),//7
    // memory ports
    out(  "XP_MEM0_ADDR",20), //8
    inout("XP_MEM0_DATA",36), //9 
    out(  "XP_MEM0_WE_N", 1),//10
    out(  "XP_MEM0_CE_N", 1),//11
    out(  "XP_MEM0_LD_N", 1),//12
    out(  "XP_MEM1_ADDR",20),//13
    inout("XP_MEM1_DATA",36),//14 
    out(  "XP_MEM1_WE_N", 1),//15
    out(  "XP_MEM1_CE_N", 1),//16
    out(  "XP_MEM1_LD_N", 1),//17
    out(  "XP_MEM2_ADDR",20),//18
    inout("XP_MEM2_DATA",36),//19
    out(  "XP_MEM2_WE_N", 1),//20
    out(  "XP_MEM2_CE_N", 1),//21
    out(  "XP_MEM2_LD_N", 1),//22
    out(  "XP_MEM3_ADDR",20),//23
    inout("XP_MEM3_DATA",36),//24 
    out(  "XP_MEM3_WE_N", 1),//25
    out(  "XP_MEM3_CE_N", 1),//26
    out(  "XP_MEM3_LD_N", 1),//27
    out("XP_IOSEL",2),//28
  };

"Reset"
"Left"
"Right"
"Xbar"
"HdSkX0"
"HdSkXP"
"HdSkIF"
"LED"
"Mem0Addr"
"Mem0Data"
"Mem0WE_n"
"Mem0CE_n"
"Mem0LD_n"
"Mem1Addr"
"Mem1Data"
"Mem1WE_n"
"Mem1CE_n"
"Mem1LD_n"
"Mem2Addr"
"Mem2Data"
"Mem2WE_n"
"Mem2CE_n"
"Mem2LD_n"
"Mem3Addr"
"Mem3Data"
"Mem3WE_n"
"Mem3CE_n"
"Mem3LD_n"
"IOSel"

Here is a little information I wrote on using the Makefiles:

  For those of you who are interested in creating designs for
  SLAAC1-V, I have created a more "official" set of Makefiles for
  processing designs.  The Makefiles are very similar to those used
  for SLAAC1A/B and Wildforce in organization.  The Makefiles even
  handle the wierdnesses--the x0.edf and PCI drop-in are included in
  the TAR file.

  To work with a design, untar the Makefile project in the same
  directory where your EDIF netlist and JHDL class files are.  Then,
  you should execute "make" you can define the class names for the
  Java on the command line. For example,

    make CLASS0=myx0 CLASS1=myx1 CLASS2=myx2

  This will implement all three PEs.  You can also declare a single
  CLASSX at a time, if you wish.  If you do a "make ... bin", the
  bitstream and readback files will be created.  Currently, the
  creation of the X0 readback files will fail for now due to the
  complications related to the non-JHDL parts of X0, but you will want
  to still do a "make ... bin" for X0 anyway.

Note that the Java class names used in the example are myx0.class, myx1.class, and myx2.class. Depending on our OS environment, you will probably have to modify the Makefiles, but they should at least be a start. You should note that when executing "make ... bin", you should have Java setup and the JHDL.jar and slaac1v.jar in your CLASSPATH to make the necessary files for readback.

Here is the basic structure of the files when they are unpacked (they actually add a "Makefile" file and "syn" directory in the current directory when unpacked):

.: (Directory)
Makefile -- The main top-level Makefile. You can modify the CLASSX
	    variables in this Makefile to reflect the class names of
	    your designs.  I generally just set those on the command
	    line instead, as described above.
syn/     -- The directory where all of the Xilinx Alliance files are
	    placed.

./syn: (Directory)
Makefile     -- This Makefile sets up the calls to the "Makefile_pe"
		Makefile which is described next.  This Makefile
		essentially is used to make the files in the peX
		directories.  There should be no reason to edit this
		file. 
Makefile_pe  -- This is the Makefile which does all of the work.
		Basically, the "Makefile" above actually changes to
		the appropriate subdirectory (pe0, pe1, pe2) and then
		executes this Makefile from within that subdirectory.
		I believe there really shouldn't be any need to edit
		this file since all paths are relative and not
		absolute. 
pci_lc_i.ngo -- This is the NGO for the PCI interface from Xilinx.
pe0/         -- The subdirectory where all of the pe0 Xilinx files
		go. 
pe1/         -- The subdirectory where all of the pe1 Xilinx files
		go. 
pe2/         -- The subdirectory where all of the pe2 Xilinx files
		go. 
x0.edf       -- The X0 wrapper design for SLAAC1-V.  This is required
		since the JHDL design essentially is dropped into the
		larger X0 design which also contains the PCI core and
		the SLAAC1-V logic which bridges between the PCI core
		and the user's design.
x0_chip.ucf  -- UCF file for X0
xp_chip.ucf  -- UCF file for X1 and X2

./syn/pe0: (Directory)
(Empty)

./syn/pe1: (Directory)
(Empty)

./syn/pe2: (Directory)
(Empty)

A few notes about hardware mode:

1. When you load up the SLAAC1-V board model and you want to work with hardware mode, the first thing you should do is click on the "Hardware Mode" checkbox in the SLAAC1-V board window. This should be done before loading any designs into the PEs. When you click on the checkbox, you can tell the board model which SLAAC1-V board to connect to (usually, it is 0, unless you have more than 1 board) and the frequency at which you want to run your design.
2. For readback to work in hardware mode, you must click on the "Read X" (where X is 0, 1, or 2) checkbox for each PE you want to readback. Readback is disabled for execution by default for all PEs. A common mistake is not turn readback on before executing---people expect to see something, but all they get is "0" for flip-flop and RAM values. Readback can be turned on or off at any time during execution.

   When readback is enabled, you can use all of the normal JAB viewer capabilities to see hardware values. Note that the only primitives being readback are those which are highlighted in magenta (or pink) in the SchematicViewer. You can look at the .readback.report or .rbentry files for the design also to see what hardware is actually being readback. This is useful since when the design is implemented with the Xilinx Alliance or Foundation tools, parts are optimized away. If something is not working in hardware as you expected, it is usually good to see if has undergone some optimization.

I have copied several small slaac1v examples to: http://jhdl.ee.byu.edu/release-latest/release/slaac1v/slaac1v-examples.tar.gz

All of these designs are very small and provide an example of how to use the SLAAC1-V JHDL environment. These are basically my readback regression tests for SLAAC1-V. In each directory is the Java source for the design, a netlist command script, and a hardware verification script. Once you have compiled the Java file, you can just execute:

	 java jab -s netlist.cmd

	 java jab -s verify.cmd

The BlockRAM examples are in the "ramb4dual" and "ramb4single" directories.