Pages that were not edited since the beginning of history (literally); it's a listing of the oldest entries in the editlog.

[RSS]

2006-04-07
Bee2Faq 06:59 Info alschult
BcFaq 07:10 Info alschult
MssgeTodo 07:11 Info alschult
2006-05-22
Bee2CorrPhotos 20:47 Info BrianRichards
2006-06-02
[DIFF] AdcFaq 16:44 Info aparsons
2006-06-12
[DIFF] Bee2 Core Template 21:26 Info alschult
2006-06-26
[DIFF] Bee2 Debian Root Nfs 04:03 Info alschult
[DIFF] Local Spelling Words 15:07 Info alschult
[DIFF] Bee2Memory 16:08 Info alschult
[DIFF] Bee2 Core Opb Select Map V101a 16:11 Info alschult
[DIFF] Bee2Pins 16:12 Info alschult
[DIFF] Bee2LinuxKernel 16:17 Info alschult
[DIFF] Bee2 Debian Root Fs 16:21 Info alschult
2006-06-27
[DIFF] Bee2Feedback 06:28 Info alschult Upload of attachment 'bee2_feedback_acrob at6.pdf'.
[DIFF] Bee2Cores 16:02 Info alschult
2006-06-28
[DIFF] Bee2TclRewrite 16:57 Info alschult
[DIFF] Bee2Readme 18:19 Info alschult

AbandonedPages (last modified 2006-04-06 18:05:05)

AdcFaq - BEE2wiki

ADC Board FAQ

  1. ADC Board FAQ
    1. Links
    2. Frequently Asked Questions
      1. What should be the power at signal and clock inputs on the ADC boards ?
      2. What analog signal ports should be connected on the ADC board ?

Links

Other useful FAQs:

Frequently Asked Questions

What should be the power at signal and clock inputs on the ADC boards ?

The power should be 0 dBm.

What analog signal ports should be connected on the ADC board ?

The I+, Q+ and clk_i inputs must be fed the two analog channels and clock respectively at 0dbm. The sync input must be fed by a 0 to 2.5V logic signal.

AdcFaq (last edited 2006-06-02 16:44:55 by aparsons)

BcFaq - BEE2wiki

Block Creators FAQ

  1. Block Creators FAQ
    1. Links
    2. Frequently Asked Questions
      1. What are the steps for creating a new block ?

Links

Other useful FAQs:

Frequently Asked Questions

What are the steps for creating a new block ?

The first step for interfacing a BEE hardware component into the toolflow is to create a simulink block which matches the port listings of the VHDL you want to interface. Next, add a functional simulink model in a subsystem which is disregarded for generation.

Simulink object must have the tag property 'xps:<name>', which can be set by right-clicking the simulink block and editing 'Block Properties'. This property tells the toolflow which directory to examine for implementation details of your block, as described next.

In xps_library there are a bunch of directories prefixed with '@' that represent each BEE hardware component. By default, a new block inherits all the properties from the '@xps_block' directory. To add a component, you need to make a new directory here.

Next, copy any files from '@xps_block' into your directory that you want to implement differently.

What follows is for EDK stuff...

  1. The base system is under hitz\designs\bee\lib\xps_lib.

    1. For testing and development replace 'xps_lib' with 'xps_lib_devel'.

  2. Unzip a base system.

    1. Your IP must be in '\\hitz\designs\bee\lib\xps_lib\XPS_..._base\pcores'.

    2. Here there are 3 dirs: data=mpd file (describes port, etc, of IP), hdl=source code, and netlist=netlist files(edn,ngc).

  3. MHS file in root of base system. It is an EDK design which enumerates IPs, their interfaces to bus, parameters like addresses, and a map of what external nets get attached to which IP ports.

We need to write the code which will write the entries in the mhs and mpd files, vhdl wrappers around the simulink netlist (to create the appropriate bus interface), and then we need to write C code for communicating with the en.

From '@xps_block':

BcFaq (last edited 2006-04-07 07:10:56 by alschult)

Bee2Binaries - BEE2wiki

BEE2 Pre-compiled Binaries

We have provided most of the pieces necessary to boot and run a BEE2 in pre-compiled, binary form. The following list includes all of the reference design bitstreams, a minimal Debian root file system, a more feature rich Debian root filesystem, the BEE2 test suite, and the default boot Compact Flash configuration.

  1. BEE2 Pre-compiled Binaries
    1. Special Formatting Instructions
    2. Reference Designs
      1. Linux Reference Design
      2. MPI Reference Design
      3. DSP Reference Design
    3. Debian Root Filesystems (CF or NFS)
    4. BEE2 Test Suite
    5. Default Boot Compact Flash

Special Formatting Instructions

For all ACE files, you will need to properly format the CompactFlash card with a FAT16 partition. The SystemACE chip that is used on the BEE2 requires special formatting options to properly read the files on the FAT16 partition. Once you have acquired a CF card you need to format it using the following command (assuming you are in Linux): 

mkdosfs -s 2 -F 16 -R 1 /dev/sda1  (16MB CF)
mkdosfs -s 8 -F 16 -R 1 /dev/sda1  (128MB CF)
mkdosfs -s 16 -F 16 -R 1 /dev/sda1 (256MB/512MB CF)
mkdosfs -s 64 -F 16 -R 1 /dev/sda1 (1GB CF)

We have tested all of these parameters on CFs at Berkeley, however they may not be right for your particular CF. More information can be found in the XUP documentation (search for "mkdosfs"). You can also download "mkdosfs" for Windows which should be run with the same options (the only difference is "/dev/sda1" would be replaced with "DRV:/" where DRV is the driver letter of the CF).

For instructions on how to further format the CF card to hold a root filesystem, see the Bee2DebianRootFs page.

Reference Designs

All of the reference designs can be built from source code contained within the BEE2 board support package. Information and instructions on how to build all the designs can be found in the Bee2Reference page.

Linux Reference Design

MPI Reference Design

DSP Reference Design

Debian Root Filesystems (CF or NFS)

The first Debian root image contains a very minimal installation of Debian. It is fully prepared to boot Debian, but almost no packages have been installed. This is a good starting point if you want complete control over your system, or you want a small footprint. The second image contains a root file system with many common packages pre-installed. Instructions are available for installing on a Compact Flash and installing on an NFS server.

BEE2 Test Suite

These binaries can be built from the test_suite CVS module. Instructions are available for running the test suite. Currently the test bitstreams are different for each user FPGA due to the way the LVCMOS traces are tested. We are planning to replace this with a single bitstream in the future.

Default Boot Compact Flash

The best way to boot the BEE2 is to use a Compact Flash that has several base systems installed. We have provided a default configuration that has three separate systems:

The purpose is for the user to place their new bitstreams as the "standard" bitstream. If ever the new bitstream was to fail to boot, you can simply reboot with the "failsafe" bistream so you can re-upload your configuration without having to remove the CF card and use an external reader.

Finally, the test suite is useful to have around to diagnose errors. Our current chassis has an external switch which selects the bitstream to boot. On a bare board this is available through a configuration jumper that is labeled on the board (see Bee2Setup for more information).

Bee2Binaries (last edited 2006-10-21 01:35:46 by hchen05)

Bee2CoreOpbSelectMapV101a - BEE2wiki

http://bee2.eecs.berkeley.edu/img/BEE2_logo_mini.png

Core

OPB SelectMAP Controller for Control FPGA

Created: 2006-06-05

  1. Introduction
  2. Functional Description
  3. Parameters
  4. Instantiation
  5. Register Definition
  6. Interrupt Behavior
  7. Drivers
  8. Frequently Asked Questions
  9. Core Facts
  10. Revision History

Introduction

The OPB SelectMAP controller core provides the ability to independently program and communicate with the four BEE2 user FPGAs. The core connects to the OPB bus via the Xilinx IPIF interface and provides a simple, register based interface to the user. The core provides two modes of operation, programming mode and FIFO mode. In programming mode the core can independently set and readback the configuration bitstreams of each user FPGA and also controls each FPGA PROG pin. In FIFO mode, the core can be used in conjunction with the opb_selectmap_fifo core in the user FPGA to provide a low-speed communication channel.

Two device driver models are currently available which utilize the core. First, the BORPH/Linux operating system has integrated support for the core and uses it to both program the user FPGAs on demand and as a control channel. Second, a generic Linux character device driver is available that allows easy programming and file I/O style communication with the user FPGA logic.

Functional Description

The primary use of this core is to transfer bytes of data over the SelectMAP bus (more information about the SelectMAP bus can be found in the Virtex-II Pro User Guide). The SelectMAP bus can operate in two modes. When unconfigured the SelectMAP pins on the FPGA are used to program and readback configuration information. After configuration the pins can either continue to operate as configuration pins or can become general purpose I/O. The OPB SelectMAP controller core provides two modes of operation that allow both configuration and reuse of the SelectMAP pins after configuration as a general purpose 8-bit data bus.

In both modes the core does not provide any hardware buffering. In configuration mode the transfer timing is completely deterministic (actually there are modes that are non-deterministic, such as configuring an encrypted bitstream, however these require the use of the BUSY signal which is not connected to the control FPGA of the BEE2) and in data transfer mode all buffering is done at the user FPGA. The buffering is performed at the user FPGA to accomodate the limited number of control signals available after configuration. To operating in data transfer mode (also known as FIFO mode), the user FPGA bitstream must contain the corresponding opb_selectmap_fifo core.

The core provides four independent SelectMAP interfaces, each connected to one user FPGA. Each interface is controlled by a pair of registers, the control and data registers. The control register contains information about the configuration state of the chip (i.e. the state of the PROG_B pin) as well as interrupt state and the core mode (i.e. configuration or FIFO mode). The primary interaction with the core is through the data register. The data register provides single byte transfers of data to or from the user FPGA. In configuration mode the writes result in normal SelectMAP configuration writes, while reads result in readback of configuration data if the proper read command has already been issued via writes. In FIFO mode reads and writes transfer a single byte at a time from or to the FIFO on the user FPGA. Currently the FIFO depth is fixed at 129 bytes.

Parameters

This core takes no parameters outside the standard IPIF parameters.

Instantiation

Instantiation of the core in a Platform Studio design is similar to any other core that attaches to a bus and has external ports. The following external ports need to be attached to external nets in the MHS file and constraints need to be added to the system UCF file from the file found in the core's ucf directory. 

 PORT FPGA_CCLK    = FPGA_CCLK,    DIR = O
 PORT FPGA1_D      = FPGA1_D,      DIR = IO, VEC = [0:7]
 PORT FPGA1_RDWR_B = FPGA1_RDWR_B, DIR = O
 PORT FPGA1_CS_B   = FPGA1_CS_B,   DIR = O
 PORT FPGA1_INIT_B = FPGA1_INIT_B, DIR = I
 PORT FPGA1_DONE   = FPGA1_DONE,   DIR = I
 PORT FPGA1_PROG_B = FPGA1_PROG_B, DIR = O
 PORT FPGA2_D      = FPGA2_D,      DIR = IO, VEC = [0:7]
 PORT FPGA2_RDWR_B = FPGA2_RDWR_B, DIR = O
 PORT FPGA2_CS_B   = FPGA2_CS_B,   DIR = O
 PORT FPGA2_INIT_B = FPGA2_INIT_B, DIR = I
 PORT FPGA2_DONE   = FPGA2_DONE,   DIR = I
 PORT FPGA2_PROG_B = FPGA2_PROG_B, DIR = O
 PORT FPGA3_D      = FPGA3_D,      DIR = IO, VEC = [0:7]
 PORT FPGA3_RDWR_B = FPGA3_RDWR_B, DIR = O
 PORT FPGA3_CS_B   = FPGA3_CS_B,   DIR = O
 PORT FPGA3_INIT_B = FPGA3_INIT_B, DIR = I
 PORT FPGA3_DONE   = FPGA3_DONE,   DIR = I
 PORT FPGA3_PROG_B = FPGA3_PROG_B, DIR = O
 PORT FPGA4_D      = FPGA4_D,      DIR = IO, VEC = [0:7]
 PORT FPGA4_RDWR_B = FPGA4_RDWR_B, DIR = O
 PORT FPGA4_CS_B   = FPGA4_CS_B,   DIR = O
 PORT FPGA4_INIT_B = FPGA4_INIT_B, DIR = I
 PORT FPGA4_DONE   = FPGA4_DONE,   DIR = I
 PORT FPGA4_PROG_B = FPGA4_PROG_B, DIR = O

The following shows an example instantiation from a MHS file (an example can also be found in the XPS_Ctrlfpga_linux system that is contained in the BEE2 reference package). 

BEGIN opb_selectmap
 PARAMETER INSTANCE   = opb_selectmap_0
 PARAMETER HW_VER     = 1.01.a
 PARAMETER C_BASEADDR = 0xe0002000
 PARAMETER C_HIGHADDR = 0xe00023ff
 BUS_INTERFACE SOPB   = opb
 PORT CCLK            = FPGA_CCLK
 PORT FPGA1_D         = FPGA1_D
 PORT FPGA1_RDWR_B    = FPGA1_RDWR_B
 PORT FPGA1_CS_B      = FPGA1_CS_B
 PORT FPGA1_INIT_B    = FPGA1_INIT_B
 PORT FPGA1_DONE      = FPGA1_DONE
 PORT FPGA1_PROG_B    = FPGA1_PROG_B
 PORT FPGA2_D         = FPGA2_D
 PORT FPGA2_RDWR_B    = FPGA2_RDWR_B
 PORT FPGA2_CS_B      = FPGA2_CS_B
 PORT FPGA2_INIT_B    = FPGA2_INIT_B
 PORT FPGA2_DONE      = FPGA2_DONE
 PORT FPGA2_PROG_B    = FPGA2_PROG_B
 PORT FPGA3_D         = FPGA3_D
 PORT FPGA3_RDWR_B    = FPGA3_RDWR_B
 PORT FPGA3_CS_B      = FPGA3_CS_B
 PORT FPGA3_INIT_B    = FPGA3_INIT_B
 PORT FPGA3_DONE      = FPGA3_DONE
 PORT FPGA3_PROG_B    = FPGA3_PROG_B
 PORT FPGA4_D         = FPGA4_D
 PORT FPGA4_RDWR_B    = FPGA4_RDWR_B
 PORT FPGA4_CS_B      = FPGA4_CS_B
 PORT FPGA4_INIT_B    = FPGA4_INIT_B
 PORT FPGA4_DONE      = FPGA4_DONE
 PORT FPGA4_PROG_B    = FPGA4_PROG_B
END

Register Definition

The core is controlled by two very simple registers, the data and control registers. The address map is defined below:

Register Name

OPB Address

Access

Data (User FPGA 1)

C_DEV_BASEADDR + 0x0

Read/Write

Control (User FPGA 1)

C_DEV_BASEADDR + 0x4

Read/Write

Data (User FPGA 2)

C_DEV_BASEADDR + 0x8

Read/Write

Control (User FPGA 2)

C_DEV_BASEADDR + 0xC

Read/Write

Data (User FPGA 3)

C_DEV_BASEADDR + 0x10

Read/Write

Control (User FPGA 3)

C_DEV_BASEADDR + 0x14

Read/Write

Data (User FPGA 4)

C_DEV_BASEADDR + 0x18

Read/Write

Control (User FPGA 4)

C_DEV_BASEADDR + 0x1C

Read/Write

Control Register

Controls the mode of the core (configure of FIFO), the state of the PROG_B pin, interrupt state, and the occupancy of the FIFOs when in FIFO mode.

0..3

4

5

6

7

8......15

16......23

24.....30

31

None

MODE

PROG_B

INIT_B

DONE

RFC

WFC

None

IRQ



Bit Location

Name

Core Access

Reset Value

Description

0-3

None

N/A

N/A

N/A

4

MODE

Read/Write

0 (Configure mode)

Mode selection. 0 = Configure mode, 1 = FIFO mode.

5

Program pin (PROG_B)

Read/Write

Depends on FPGA state

Prog pin of user FPGA, when set the user FPGA is unconfigured.

6

Init pin (INIT_B)

Read

Depends on FPGA state

Init pin of user FPGA, also doubles as control pin in FIFO mode.

7

Done pin (DONE)

Read

Depends on FPGA state

Done pin of user FPGA, goes high when configuration complete.

8-15

Read FIFO Count (RFC)

Read

0

Number of bytes currently in read FIFO.

16-23

Write FIFO Count (WFC)

Read

129

Number of bytes that can be written to FIFO.

24-30

None

N/A

N/A

N/A

31

Interrupt (IRQ)

Read/Write

0

Interrupt request state.

Data Register

Reads and writes to the data register result in either transfer of data from or to the SelectMAP interface.

0......7

8......................31

Data

None

In configure mode, writes to the data register will result in the transfer of the 8-bit value across the SelectMAP bus. During chip configuration all commands are sent to the chip as a series of four bytes to form a control word. Reads while in configure mode are currently not fully supported, although they have been in the past (version 1.00a).

In FIFO mode, writes to the data register will cause the byte to be written to the user FPGA write FIFO. Before all writes you should check the Write FIFO Count (WFC) field in the control register to make sure that you do not overflow the FIFO. The count will give the number of bytes that can currently be written into the FIFO, so it is safe to write up to that count without polling the control register again. If you do overflow the FIFO, the overflowed bytes will be lost. A read of the data register will result in a single byte being pulled from the read FIFO on the user FPGA. Before doing any reads while in FIFO mode, you must check the Read FIFO Count (RFC) field of the control register to make sure it is safe to read. The RFC will tell you how many bytes are currently in the FIFO and it is safe to read up to that count without polling. Underflowing the FIFO can potentially lock up the OPB bus and deadlock the system in the current design, so it is crucial to check the RFC before reading.

Interrupt Behavior

The opb_selectmap core provides independent access to each user FPGA SelectMAP bus. Therefore, the core exports four independent interrupt requests. Interrupts can only become active when in FIFO mode and are edge triggered. The user FPGA FIFO core triggers an interrupt by asserting the INIT_B pin (the opb_selectmap_fifo core has several different interrupt behaviors, see the documentation for more details). The interrupt will remain asserted until the IRQ bit in the control register is cleared by the ISR.

Drivers

There are currently two drivers available for the opb_selectmap core. First, the core is used both for configuration and for communication in the BORPH/Linux operating system. For more information on BORPH please visit the home page.

The second driver is a Linux character device driver which gives simple, scriptable access to the device. The driver is currently included in the default BEE2 Linux tree and the default kernel configuration (you can view the source CVSweb).

The driver exports two interfaces to the user. First, a simple proc entry is created for each device with the names /proc/fpga/selectmap[1-4]. Reading the proc entry gives the current status of the device, such as the mode and the state of the PROG_B and DONE pins. Users can write an ascii string to the proc entry with the side effect of writing that value to the control register for that FPGA. For example, to set the mode of to configure you could execute the following command: 

$ echo 0f000000 > /proc/fpga/selectmap1

The second driver interface is a character device entry created for each device with the names /dev/selectmap[1-4]. This is the primary way of interacting with the core in both configuration and FIFO mode. The character device interface has the same semantics of almost any other file, except that it does not support certain operations such as seek. Interacting with the device is as simple as first opening the /dev file and then performing reads and writes. Configuration of a chip is made very easy, as you can simply use the tools cat and echo to program a chip. For example, here is a very simple set of commands to program a user FPGA: 

$ echo 00000000 > /proc/fpga/selectmap1  # Assert PROG_B to deprogram FPGA
$ echo 04000000 > /proc/fpga/selectmap1  # Deassert PROG_B and set to Configure mode
$ cat download.bit > /dev/selectmap1     # Send the bitstream
$ echo 0f000000 > /proc/fpga/selectmap1  # Set FIFO mode (if desired)

One thing to note is that the Linux driver is not very sophisticated (it is intended as a debug driver) and thus is not very high performance. For example, it does not take advantage of the interrupt signals and performs all I/O as programmed I/O. If you are planning to use the FIFO mode capabilities in a high performance application you will either need to implement this functionality or borrow from the BORPH driver which takes advantage of interrupt driven I/O and performs better OS buffer management.

Frequently Asked Questions

None so far.

Core Facts

BEE2 Core Facts

Core Specifics

Supported Device Family

Virtex-II Pro

Version of Core

opb_selectmap_v1_01_a

v1.01.a

Resources Used

Min

Max

Total Core I/Os

53

53

Core FPGA IOBs

53

53

LUTs

318

318

FFs

291

291

Block RAMs

0

0

Provided with Core

Documentation

Wiki Doc

Design File Formats

Verilog, VHDL

Constraints File

UCF

Verification

BFM simulation

Instantiation Template

N/A

Reference Designs

None

Design Tool Requirements

Xilinx Implementation Tools

ISE 8.1i or later

Verification

ModelSim SE 6.1a

Simulation

ModelSim SE 6.1a

Synthesis

XST 8.1

Support

Support provided by Berkeley Wireless Research Center

Revision History

Click the Info link below to see the revision history.

Bee2CoreOpbSelectMapV101a (last edited 2006-06-26 16:11:51 by alschult)

Bee2Cores - BEE2wiki

BEE2 IP Core Documentation

General Cores

Memory System

Communication

Control FPGA Cores

Display

Configuration

IIC

User FPGA Cores

Communication

IBOB Cores

BEE2 Core Documentation Template: Bee2CoreTemplate

Bee2Cores (last edited 2006-06-27 16:02:20 by alschult)

Bee2CorrPhotos - BEE2wiki

The BEE2 in the Field: Reviving the BEE1 Chassis for a 16 Antenna Correlator

Photos of the BEE2 in Campbell Hall, 5/19/2006

Bee2CorrPhotos (last edited 2006-05-22 20:47:18 by BrianRichards)

Bee2Cvs - BEE2wiki

Accessing the BEE2 CVS Repository

The BEE2 board support package and PCB source code is all maintained in a CVS repository. We have provided both read-only access to the publicly available portions of the code through a CVSweb interface and through daily snapshots of the code. For read-write access and access to non-public source code, users must request an account to gain access to the repository.

Read-only CVS

We have provided both a web interface and snapshots of the important BEE2 CVS modules. You can find the snapshots on the main BEE2 website (http://bee2.eecs.berkeley.edu/#CVS) and you can access the CVS web interface at http://bee2.eecs.berkeley.edu/cvs (Note: This is not the CVS for the MSSGE toolflow, you can find information on accessing this package at MssgeFaq).

Accounts and Permission

To gain read-write access to the BEE2 CVS repository you must have a valid account and have proper group access. If you have a valid BWRC account you must be added to the bee2cvs group. Email the BWRC administrators (bee2-maintainers@lists.berkeley.edu) to request the change.

If you do not have a valid BWRC account you must request a BEE2 account from the system administrators. To do so, please email the following information to bee2-maintainers@lists.berkeley.edu with the subject [BEE2] Account Request and the following body:

You will receive an email with your new account name from the system administrators.

Client Configuration

These instructions are geared towards a Linux or Cygwin environment, but they should be easy to translate into other environments. First you need to set your CVSROOT variable. The best way to do this is to add the following line to your shell startup script (i.e. .bash_profile or the like): 

export CVSROOT=:ext:username@bee2.eecs.berkeley.edu:/cvshome/BEE2

You must also set the default external communication method for CVS to be SSH. To do this add this line to your startup script: 

export CVS_RSH=ssh

These commands will be slightly different if you use a shell other than bash or if you are using a program such as WinCVS.

CVS Modules

Currently the BEE2 CVS repository has several modules that can be checked out independently. Although the modules are independent, some of them rely on others through symlinks for things like IP cores. It should be clear which modules you will need, but if all else fails, you can check them all out. The following modules are currently available:

CVS Mailing List

All commits to the BEE2 CVS trees generate an automated email of the changes. These changes are archived in the BEE2 mailing lists. If you would like to receive these change emails, you must subscribe to the bee2-cvs mailing list. To sign up send mail to majordomo@lists.berkeley.edu with the following in the body of the email: 

subscribe bee2-cvs

Bee2Cvs (last edited 2006-07-12 23:01:12 by alschult)

Bee2DebianRootFs - BEE2wiki

Creating a Debian Root Filesystem on a Compact Flash

Introduction

The following contains the steps required to build a Debian root filesystem for the BEE2 or for other Virtex2 Pro boards such as the ML300 or XUP. The following assumes that you have a machine that is running Linux, although Cygwin might work (although this has not been tested). Many of the details were taken from work done at UIUC and BYU. You may refer to these pages for more details, and we thank them for their excellent work.

Partition the Compact Flash/Microdrive

You will need a fairly large CF or Microdrive to hold the root filesystem. The standard 1GB IBM Microdrive will work fine, and for CF you should have at least a 512MB card. The first task is to partition the CF. We need at least three partitions:

The easiest way to partition the CF is to simply use a USB to CF reader. I believe that the PCMCIA based readers that come with the IBM microdrives are a bit faster, but we find the USB readers to be more flexible. When you insert the USB reader into your linux machine you should see something like the following if you run dmesg: 

scsi29 : SCSI emulation for USB Mass Storage devices
  Vendor: General   Model: Flash Disk Drive  Rev: 2.05
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 2104704 512-byte hdwr sectors (1078 MB)
sda: assuming Write Enabled
sda: assuming drive cache: write through
 /dev/scsi/host29/bus0/target0/lun0: p1
Attached scsi removable disk sda at scsi29, channel 0, id 0, lun 0
USB Mass Storage device found at 35

The key line is SCSI device sda: 2104704 512-byte hdwr sectors (1078 MB) which tells us that the device is /dev/sda. Now we can partition the disk by running fdisk: 

# fdisk /dev/sda

Next delete any existing partitions (follow the prompts given by fdisk). Now we can create the three partitions. The first one should be a FAT16 partitions whose size should be anywhere from 20MB to 100MB, basically the size you think you'll need to hold all your ACE files. Most people will simply have a small 20-30MB partition large enough to hold one configuration: 

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-522, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-522, default 522): +20M

Follow the same example for the next two partitions. Make the second partition (the swap) between 64-128MB and make the root partition take up the rest of the drive. Now that the partitions are created we need to change the type on them. The first partition must be made type FAT16: 

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 6
Changed system type of partition 1 to 6 (FAT16)

Change the second partition in a similar fashion to swap (type 82). Now save the new partition table by entering w.

Format the Partitions

The SystemACE chip that is used on the BEE2 requires special formatting options to properly read the files on the FAT16 partition. Once you have acquired a CF card you need to format it using the following command (assuming you are in Linux): 

mkdosfs -s 2 -F 16 -R 1 /dev/sda1  (16MB CF)
mkdosfs -s 8 -F 16 -R 1 /dev/sda1  (128MB CF)
mkdosfs -s 16 -F 16 -R 1 /dev/sda1 (256MB/512MB CF)
mkdosfs -s 64 -F 16 -R 1 /dev/sda1 (1GB CF)

We have tested all of these parameters on CFs at Berkeley, however they may not be right for your particular CF. More information can be found in the XUP documentation (search for "mkdosfs"). You can also download "mkdosfs" for Windows which should be run with the same options (the only difference is "/dev/sda1" would be replaced with "DRV:/" where DRV is the driver letter of the CF). Next setup the swap partition by running: 

# mkswap /dev/sda2

Finally create the root file system by running: 

# mkfs.ext3 /dev/sda3

We use the EXT3 journalled file system because it is more robust than EXT2, especially since there is a propensity to reboot the board running Linux without a proper shutdown. You can use EXT2 or any other file system you like as well. You might also want to change the default fschk behavior for the partition, as it will often force a check when you boot due to time discrepancies. Be warned that this is generally not advised as it will prevent automatic filesystem checks and could lead to corruption. To change the check behavior run: 

# tune2fs -i 0 -c 0 /dev/sda3

Fast Root Installation

The fastest way to get a root filesystem on your CF is to simply download a copy of our pre-generated base system found rootfs.tar.gz (careful, its about 75MB). We also describe how to generate this image by hand, however this currently requires a PowerPC running Debian (we use a Mini). Unless you are doing something special, the prebuilt image should be fine.

Once you have downloaded the image somewhere convenient, mount the CF by executing: 

# mount /dev/sda3 /mount/point/

Then untar the root file system by doing: 

# tar -C /mount/point/ -zxvf rootfs.tar.gz

You should now run sync and be prepared to wait as the files are actually sync'd to disk. If you don't want to do any more customization on the root you can unmount: 

# umount /mount/point/

Root Customization

It is a good idea to add any packages you may need and edit the configuration files before you try to boot a V2P system. The first step is to chroot the file system and then mount proc: 

:/mount/point# chroot /mount/point
:/# mount -t proc proc /proc
:/# ANY CUSTOMIZATION
:/# umount /proc
:/# exit
:/mount/point#

The only package installed in our pre-built base system is the devfsd package required to properly mount devfs. The pre-built system uses a Berkeley mirror for APT, which you might want to change to a closer one. Do this by running base-config or editing /etc/apt/sources.list. Some good things to install include ssh (apt-get install ssh), ntpdate (apt-get install ntpdate), and gcc (apt-get install gcc).

Installing System ACE files

The final step before you can boot your new system is to install a System ACE file on the FAT16 partition so the board can boot. You can find a set of example bitstreams with standard, failsafe, and test suite for the BEE2 in default_cf.zip. To put the bitstreams on the CF you need to run the following: 

# mount -t vfat /dev/sda1 /mount/point
# unzip default_cf.zip -d /mount/point
# sync
# umount /mount/point

The sync above is not strictly necessary, but remember, to wait for umount to return before taking the CF out or you will have corrupted data. Alternatively in Windows simply open the mounted CF (it will only mount the FAT16 partition which holds the configuration bitstreams) and copy the contents of the zip file to the CF. Remember to properly unmount the card before removing or you may loose some of the bits.

You are now ready to boot Debian.

Bee2DebianRootFs (last edited 2006-06-26 16:21:27 by alschult)

Bee2DebianRootNfs - BEE2wiki

Creating a Debian Root Filesystem on a NFS

  1. Creating a Debian Root Filesystem on a NFS
    1. Introduction
    2. Obtaining the Root Filesystem
    3. Setting up your NFS Server

Introduction

This document explains the steps required to setup an NFS export with a BEE2 Debian root filesystem. Information on installing a root filesystem on a CompactFlash card can be found at Bee2DebianRootFs.

Obtaining the Root Filesystem

We have provided two different root filesystems. One is a minimal installation that has almost none of the Debian packages installed, and thus is fairly small. The second has several important packages (such as SSH, ntp, etc.) already installed. Both root filesystems are linked to in the Bee2Binaries wiki page.

Setting up your NFS Server

A good tutorial on how to setup an NFS share under linux can be found here

Under Windows, Cygwin can be used to setup a NFS server, as explained here

In both cases, make sure that you disable rootsquashing (by specifying the "norootsquash" option in /etc/exports)

Bee2DebianRootNfs (last edited 2006-06-26 04:03:18 by alschult)

Bee2Errata - BEE2wiki

BEE2 Errata

This page is intended to collect various bits of information regarding the use of the BEE2 board and its gateware infrastructure. Please scan through this page before working on your own designs, and please consult it first if you have strange errors with your designs. If you come across any tips, tricks, or vital information that should be easy to find, please feel free to add it to this page.

  1. BEE2 Errata
    1. Replacing SystemACE oscillator
    2. No output on RS232 serial or JTAG problems
    3. Linux on control FPGA stops booting when programming with JTAG
    4. User FPGA JTAG chain problems
    5. User FPGA startup clock
    6. User FPGA designs without SelectMAP block

Replacing SystemACE oscillator

Problem

Due to the length of the JTAG chain that connects the SystemACE chip to the control FPGA, there have been some problems booting the control FPGA with certain bitstreams. This problem manifests itself as the SystemACE status LED turning red during initial programming, or by software not properly starting on the embedded PowerPC (i.e. Linux bootloader not showing up).

The problem is caused by the oscillator that is installed on all BEE2's with a serial number lower than 2.2.X. The oscillator installed on those boards is a 32MHz oscillator that drives the SystemACE too fast for the JTAG chain. In all boards after the 2.2.X batch, this problem has been fixed. For boards before that, you will need to install a new 16MHz oscillator, or verify that your board has already been updated. Most sites with boards will receive a new oscillator in the mail from BWRC.

Instructions

The oscillator to be replaced is located under the CompactFlash card holder next to the SystemACE chip.

The oscillator has four surface mount pads that must be desoldered and lifted from the board. We suggest using two paddle iron tips, or using a single tip and some solder wick to lift the old oscillator. When the old oscillator has been removed, clean up the pads with some solder wick.

Finally, apply solder paste or solid solder to attach new oscilator. The picture below shows the correct orientation.

To test the correctness of the replacement, simply power on the BEE2 without a CompactFlash card in the slot. You should see the SystemACE status LED blink red at a slower pace than usual. Next, insert the BEE2 test suite on a CF card and make sure it properly boots and runs. Finally, insert a CF with the default Linux base system and make sure that too boots and runs.

No output on RS232 serial or JTAG problems

Designs on the control FPGA that use DDR2 DIMMs must have a DIMM inserted into each bank that is used (i.e. has a memory controller driving it). If you do not have a DIMM in the slot then the unterminated reflections of signals sent to the DIMM can cause problems with the RS232 and JTAG lines.

For any design that instantiates a DDR2 controller on a bank, that bank must have a DIMM inserted.

Linux on control FPGA stops booting when programming with JTAG

If you are having trouble with Linux freezing up in the boot process, it is likely because you don't have a CompactFlash card in the CF holder.

If the Linux kernel contains the SystemACE driver, then regardless of whether you programmed the control FPGA with JTAG or from the SystemACE, you need to have a CompactFlash card in the CF holder for the kernel to boot because the SystemACE driver will block trying to read the card.

User FPGA JTAG chain problems

Due to the length of the JTAG chain that connects the four user FPGAs, we have sometimes observed instability in both programming the FPGAs via JTAG and when performing debugging with Chipscope or XMD. The simplest solution to this problem is to simply instruct the debugging tools (Impact, Chipscope, or XMD) to use the JTAG cable at a slower speed.

For example, if you are using a Xilinx Parallel IV cable, the fastest setting is 5 MHz with ECP mode. If you experience problems when running at this speed, you can simply disable ECP mode and the cable will drop to 200 KHz. At this lower speed we have not experienced any problems in the lab.

User FPGA startup clock

For user FPGA designs that are programmed via the SelectMAP interface from the control FPGA, the proper startup clock must be selected in the bitgen options. The bitgen options are set via the etc/bitgen.ut file in a XPS project.

The two clocks that are of primary interest are the JTAG and CCLK clocks. When programming the FPGA from the JTAG chain you want to select the JTAG clock. The bitgen option is as follows: 

-g StartUpClk:JtagCLK

To configure the user FPGAs with the SelectMAP interface from the control FPGA you must select CCLK. The bitgen option for this is: 

-g StartUpClk:Cclk

For more information about the bitgen options you can refer to the Development System Reference Guide.

User FPGA designs without SelectMAP block

When creating an user FPGA design that does not instantiate a SelectMAP block (opb_selectmap_fifo or others), you must instantiate a place holder core that will drive the SelectMAP pins to a safe state. If you don't do this the pins will change to unconnected I/Os that can lock up the control FPGA and cause other strange errors. An example of this can be found in the user FPGA design in the "MPI demo" on the Bee2Reference page.

If you do this, please be careful not to send any data through the SelectMAP character device on the control FPGA as it could potentially mess up the state of the user FPGA.

Bee2Errata (last edited 2006-07-12 21:36:25 by alschult)

Bee2Faq - BEE2wiki

BEE2 Board FAQ

  1. BEE2 Board FAQ
    1. Links
    2. Frequently Asked Questions
      1. How cool is the BEE2 ?

Links

Other useful FAQs:

Frequently Asked Questions

How cool is the BEE2 ?

Way cool.

Bee2Faq (last edited 2006-04-07 06:59:19 by alschult)

Bee2Feedback - BEE2wiki

User Feedback

We have provided a feedback form to solicit comments from BEE2 users. The form is intended to be filled out by new users who have been working the the BEE2 for about two to three weeks. However, any users wishing to make comments about the BEE2 board, website, or board support package are encouraged to use the feedback form as well.

Download feedback form for Acrobat 7 (or form compatible with Acrobat 6)

Bee2Feedback (last edited 2006-06-27 06:28:19 by alschult)

Bee2LinuxConfig - BEE2wiki

Configuring a BEE2 for Linux

  1. Configuring a BEE2 for Linux
    1. Introduction
    2. Overview of Configuration
    3. Setting the Configuration Strings
    4. Boot Command String
    5. Changing Baud Rate

Introduction

The purpose of this page is to describe the steps required to setup a BEE2 board to properly boot linux. This is primarily concerned with setting up the EEPROM on the BEE2 to hold the proper configuration strings. You can also find information on building a BEE2 root filesystem on Compact Flash, building a root filesystem for NFS, and building a kernel.

Overview of Configuration

The BEE2 has a small 512 byte EEPROM which comes as part of the X1226 RTC. The EEPROM and RTC are connected to the IIC bus. We currently use a simple software IIC core which we developed to access the IIC and SMB devices on the board. We use the EEPROM to hold a series of key/value pairs which describe configuration information necessary to boot Linux. This information includes:

Setting the Configuration Strings

Our BEE2 test suite includes software to set and read the configuration strings for the board. We have information on building and running the test suite in the wiki. Once you have the test suite running on the board and are connected over the RS232 link, run the following command: 

set_eeprom

This will prompt you to enter the four pieces of information mentioned above. For each item it will also print the old value which you can cut/paste with your terminal emulator if you don't want to change the value. When you are done entering each one, hit enter, and at the end it should pause for a few seconds while it writes the values to the EEPROM. To test that the values were written successfully run the command: 

get_eeprom

Which should print out the values you just entered.

Boot Command String

The boot command is probably the most important value you will set. It is the string that is passed to the kernel on boot, and can take any of the acceptable boot parameters. Here is an example (and recommended) command line for the BEE2 Linux reference design: 

console=tty0 console=ttyS0,115200 nfsroot=/b2roots/hostname ip=192.168.0.100:192.168.0.1:192.168.0.1:255.255.255.0:hostname:eth0:off mem=512M rw root=/dev/nfs

Changing Baud Rate

The default baud rate for Linux on the BEE2 is 115200. There really isn't a good reason to change this, but if you find a reason to, you must change several things. First, you need to change the command line stored in the EEPROM from console=ttyS0,115200 to console=ttyS0,YOURBAUD. Next, you need to change the baud rate parameter stored in the EEPROM to your baud rate. Finally, on your root file system you need to edit the file /etc/inittab and change the baud rate on the getty that spawns on ttyS0.

Bee2LinuxConfig (last edited 2006-07-13 18:43:23 by alschult)

Bee2LinuxKernel - BEE2wiki

Building a Linux Kernel for BEE2

  1. Building a Linux Kernel for BEE2
    1. Introduction
    2. Acquiring the Kernel Source
    3. Generating the Hardware BSP files
    4. Configuring the Kernel
    5. Setting up a Build Environment
    6. Compiling the Kernel
    7. Creating the ACE File

Introduction

The BEE2 supports booting Linux kernel version 2.4. There are future plans to support kernel version 2.6 when and if drivers for Xilinx IP cores such as ethernet are released. We officially support a fork of the Linux-PPC kernel tree which has its root in version 2.4.30-pre1. This new tree is hosted in our CVS repository (see Bee2Cvs for more information). We have provided precompiled binary versions of the kernel (see Bee2Binaries), however it is likely that most users will need to build their own kernel at some point, primarily due to the static way in which device addresses are configured. This document specifies the few steps required to build a kernel image for the BEE2.

Most of these instructions have been described in greater detail in other excellent documents prepared at UIUC. For more detailed information please refer to "Building a Xilinx ML300/ML310 Linux Kernel".

Acquiring the Kernel Source

The officially supported kernel source for the BEE2 can be either checked out from our CVS repository, or can be downloaded as a daily snapshot from our BEE2 homepage. If you are checking out from the repository simply execute: 

cvs co linuxppc-2.4

or if you have downloaded the snapshot execute: 

tar -zxvf linuxppc-2.4_DXXX.tar.gz

This will create a clean kernel tree called linuxppc-2.4. Change into this directory to begin compiling the kernel.

Generating the Hardware BSP files

Many of the pcore drivers found in the kernel use a statically defined macros to define the base address and other parameters of the hardware. The values are communicated from the Xilinx tools to the kernel via automatically generated header files. The header files are part of the "BSP" generated by Platform Studio.

These instructions assume you are using a base system derived from a BEE2 reference design. In the BEE2 reference designs, the files will be created in a directory called /PATH/TO/XPS/PROJECT/bsp/. If you are using a different design, you must set the TARGET_DIR parameter under the OS software settings. To generate the BSP files perform the following steps:

The kernel is now set up with the proper BSP files. To verify that they are up to date you can inspect the file /PATH/TO/linuxppc-2.4/arch/ppc/platforms/xilinx_ocp/xparameters_ml300.h. This file contains all of the definitions of the hardware addresses and other configuration parameters.

Configuring the Kernel

We have provided a default configuration for the kernel that matches the hardware found in the XPS_Ctrlfpga_linux reference design. You should start with this configuration and modify it as necessary to suit your kernel and hardware needs. Using the default kernel configuration is fairly straight forward: 

cd /PATH/TO/linuxppc-2.4
cp arch/ppc/configs/bee2_defconfig .config
make oldconfig

If you would like to make further configuration changes simply run make menuconfig.

Setting up a Build Environment

Since most users have a workstation that does not run PowerPC code natively it is usually necessary to obtain a cross compiler to properly build the kernel. The other alternative is to build your kernels on a PowerPC machine such as a Mac (we have a Mac Mini on our bench that works well). Regardless, most people will want the power of their workstation or server, so a cross compiler is usually the best option.

Obtaining and installing a cross compiler has already been described in great detail, we refer you to the Cross Tool instructions written up by UIUC. The only thing to be aware of is the name of the cross compiler. The kernel we have provided is looking for a cross compiler with the prefix powerpc-405-linux-gnu-. If you have a different prefix for your compiler, you should change the CROSS_COMPILE parameter in linuxppc-2.4/Makefile.

Compiling the Kernel

Once you have your compiler setup and configuration done, it is a simple process to actually build the kernel. Simply run the following: 

cd /PATH/TO/linuxppc-2.4
make dep
make zImage
make modules

The build should proceed smoothly from there. A common error you might encounter is a complaining about a variable prefixed with XPAR not being defined. This means that the xparameters_ml300.h file is either out of date, or you have enabled a kernel option for a hardware device that is not found in your design. To update the xparameter_ml300.h file, follow the instructions on creating the BSP files found above. If the kernel is configured for hardware that is not actually in your base system, simply run make menuconfig and remove the non-existent device.

If everything does go smoothly you will end up with arch/ppc/boot/images/zImage.embedded newly generated. This is the new Linux kernel with the bootloader already embedded.

Creating the ACE File

The ACE file is used to program the control FPGA from a CompactFlash card on boot. In our XPS_Ctrlfpga_linux reference design we have provided several files that are used to create the ACE file. If you are not using our reference design as a starting point you will need to copy the following files which are all found in its root directory:

  1. bee2Genace.opt - Options for the ACE generator script

  2. genace.tcl - The ACE generator script modified to meet the boot requirements of the BEE2 memory

  3. mkace.sh - Wrapper script to invoke the ACE generator

The only file you should potentially modify is the bee2Genace.opt script. It sets the the paths of the three filenames required to generate an ACE file:

  1. -ace XXX - Path and filename of the output ACE file (system.ace)

  2. -elf XXX - Path and filename to the Linux kernel image (zImage.embedded)

  3. -hw XXX - Path and filename to the hardware bitstream (download.bit)

Creating the ACE file is several steps if you are using the default paths: 

cd /PATH/TO/XPS_Ctrlfpga_linux
cp /PATH/TO/linuxppc-2.4/arch/ppc/boot/images/zImage.embedded .
./mkace.sh

Once you have generated the ACE file you are ready to place it on a CompactFlash card to boot the system or to load it using XMD. Instructions on proper formatting of the boot CF can be found in Bee2DebianRootFs

Bee2LinuxKernel (last edited 2006-06-26 16:17:46 by alschult)

Bee2Memory - BEE2wiki

http://bee2.eecs.berkeley.edu/img/BEE2_logo_mini.png

Overview

DDR2 Memory System

Created: 2006-06-09

  1. Introduction
  2. Physical Memory
  3. DDR2 Controller
  4. User Memory Interface
  5. Frequently Asked Questions
  6. Revision History

Introduction

The purpose of this document is to give an overview of the DDR2 memory system supported by the BEE2. In addition to a brief overview of the physical memory support on each BEE2 module, this document also describes the custom memory interface logic created for the BEE2 at the Berkeley Wireless Research Center.

Overview

Access to the raw DDR2 memory has been implemented through a set of interfaces which build upon one another. The following figure gives a high level implementation of this layered approach.

At the lowest level is the actual DDR2 memory controller. Each DIMM has its own independent DDR2 controller, each of which is heavily pipelined and supports simple bank management. On top of the low-level DDR2 controller is the user memory interface. The user memory interface is a simple, common interface that user logic can use to access memory. The interface is implemented as a series of asynchronous command FIFOs which provide command buffering and decouple the user clock domain from the 200MHz DDR2 controller clock domain. Finally, on top of the user memory interface, any arbitrary user logic can be implemented.

Multi-port Access

To provide multi-port access to each DIMM, we have provided a simple arbiter to the user memory interface for each DIMM. The switch is completely configurable in the number of ports, and has different modes of arbitration. The basic arbitration is priority round-robin. This gives a good balance between the needs of a priority based arbiter and provides starvation free arbitration. In addition to the basic mode, the arbiter also supports bursting. Bursting allows a requester to maintain arbitrated status while it holds down the request line up to a configurable window of cycles. This enables efficient bursting for applications which require bursting to maintain sufficient performance. Finally, in addition to these two modes of arbitration, the arbitration logic itself is highly self contained with a consistent interface, allowing users to easily implement their own arbitration scheme to suit their particular needs.

The multi-port switch provides each port the same user memory interface as is provided by the asynchronous command FIFO block. This means that any logic design to work directly with the user memory interface will work without modification with the multi-port switch. An example of a system which uses the multi-port switch can be seen below.

This example is similar to the setup of the reference Linux base system provided with the BSP. In this example the multi-port switch provides two ports. One is connected to a PLB attachment that allows the host processor to access the physical memory. The second port is attached to a frame buffer device (note that the OPB attachment for the frame buffer is not for data transfer, it is simply for control registers). In this example, bursting is turned on to meet the timing requirements of the framebuffer's DVI output.

Physical Memory

Each BEE2 module has five Virtex-II Pro 70 FPGAs, each of which are connected to four fully independent DDR2 DIMM modules. At present the maximum memory capacity of each module is 1GB (although higher density DIMMs could bring this to 2GB or above) giving a total memory capacity of 20GB per BEE2 module. The FPGA is wired to accept a 72-bit data path, allowing the use of ECC storage bits as well.

For more information on the details of the physical connections to memory, please see the BEE2 module documentation which contains links to schematics, and data sheets. Additionally the Bee2Setup page has information about part numbers for DIMMs that have been verified to work with the BEE2.

DDR2 Controller

Overview

The heart of the BEE2 memory system is the DDR2 controller. The controller is responsible for all of the low-level DRAM management data transfer tasks. The controller was originally based on the data path generated from the Xilinx MIG007 tool and then heavily modified at BWRC. The tasks performed by the controller include:

As of now, the controller allows access to ECC storage bits, but does not actually implement ECC. For more detailed information on the controller implementation, please see the core documentation directly for the ddr2_controller_v2_00_a core.

Interface

Although the DDR2 controller has independent data paths for read and write data, the controller does not allow simultaneous issuance of both read and write commands. However, the controller is highly pipelined and can issue a command every other cycle. The interface provided by the controller is fairly simple, although it runs at 200MHz and therefore can introduce timing problems if interacted with directly. The preferred way to interact with this interface is through the asynchronous command FIFO block (described below), but the lowest latency option is to use this interface directly. The following diagram shows the signals that comprise the interface.

Please note that although there are separate user_read and user_write signals, they may not be asserted at the same time, and therefore only a single read or write can be issued at a time.

Functional Description

Issuing a command to the controller is controlled by the user_ready signal. When this signal is high, it means that in that cycle it is possible to issue a new command. Because of the single cycle turn around on this signal, it often shows up on the critical path for this interface. The transaction happens in two phases. First the address is accepted, and second the data is fetched (for a write) or returned (for a read).

Phase 1: Address

When user_ready is high the user can assert either user_read or user_write (but not both) along with a valid 32-bit address. Note that although you present a 32-bit address, the lower 4-bits of the address will be unused because the controller transfers data aligned on 128-bit boundaries (actually it is 144-bits if you count the extra ECC storage bits). The transaction is accepted on the rising edge that sees both user_ready and user_read or user_write asserted. Ready will always go low for at least one cycle after accepting an address. An additional signal, user_half_burst is also sampled at issue time. If this signal is high, it means that the controller will only accept or generate one 144-bit data value. If it is low then it means the controller will accept or generate two 144-bit data values.

Phase 2: Data

Timing

The following timing diagrams describe the behavior of the DDR2 controller interface.

Write Transactions

If the user_half_burst signal is asserted when issuing the command, then the user_get_data signal will only be asserted for one cycle and the controller only expects one 144-bit data value.

Read Transactions

If the user_half_burst signal is asserted when issuing the command, then the user_data_valid signal will only be asserted for one cycle and the controller only sends one 144-bit data value.

User Memory Interface

Overview

Although interacting with the DDR2 controller interface directly is the highest performance, lowest latency option to access memory, most applications will have logic operating in a different clock domain than the 200MHz controller. To address this issue, we have provided a easier to use and clock decoupled interface called the user memory interface. The implementation of this interface is the async_ddr2_v2_00_a core which contains block RAM based asynchronous FIFOs to buffer commands and provide clock domain crossing.

The interface has several different modes of operation which are set by two parameters:

Finally, the asynchronous command FIFO core also give the user the option to utilize a command tag FIFO that will maintain a 32-bit tag that corresponds to each read transaction. This makes certain applications easier given the split phase operation of commands.

Interface

The following diagram shows all the signals that comprise the user memory interface.

The interface is comprised of roughly three components. The command (Cmd) signals are involved with issuing a read or write command. The write (Wr) signals carry data and byte enables for writes, and the read (Rd) signals carry data and tag information from reads.

Functional Description

Just like the DDR2 controller, the asynchronous command FIFO block does only allows a single read or write command per cycle and no reordering of commands is done within the block. This is an important point for consistency and coherence issues for multi-core systems, as this means that this core acts as a synchronization point for all commands. It is possible to augment this core to perform reordering and optimization, but at this time it is safe to assume the same order in and out of the core.

Phase 1: Command Issue

To issue a command the user will assert Mem_Cmd_Valid and will present a valid address on Mem_Cmd_Address. The cycle in which the command is accepted the core will assert Mem_Cmd_Ack (this may be asserted during the first cycle Mem_Cmd_Valid is asserted).

Phase 2: Read data

When the read data has returned from the controller the controller will assert Mem_Rd_Valid and the Mem_Rd_Dout and Mem_Rd_Tag buses will be valid. The user can acknowledge the data at any time by asserting Mem_Rd_Ack for a single cycle.

Special Case: Narrow data mode and full burst mode

The only case where the description above differs is when the core has been configured with C_WIDE_DATA=0 and C_HALF_BURST=0. This case corresponds to utilizing the full bandwidth of the DDR2 controller, but without using the internal block RAM muxes. In this case the user is required to issue two commands for a write and will need to acknowledge two read data values for a read.

Frequently Asked Questions

None so far.

Revision History

Click the Info link below to see the revision history.

Bee2Memory (last edited 2006-06-26 16:08:43 by alschult)

Bee2OperatingSystem - BEE2wiki

http://bee2.eecs.berkeley.edu/img/BEE2_logo_mini.png

Overview

BORPH Operating System

Created: 2006-06-21

  1. Introduction
  2. Designing for BORPH HowTo
  3. Obtaining BORPH
  4. Paper about BORPH

Introduction

The purpose of this document is to give an overview of the BORPH Operating system used by the BEE2. In addition to a brief overview and philosophy behind BORPH, this document also describes how to build a BORPH compatible system on the BEE2.

Overview

BORPH is an extended Linux kernel that treats FPGA resources as native computational resources on reconfigurable computers such as BEE2. As such, it is more than just a way to configure an FPGA. It also provides integral operating system supports for FPGA designs, such as the ability for an FPGA design to read/write to the standard Linux file system.

A user process in BORPH, can therefore either be a software program running on a processor, or a hardware design running on a FPGA. A hardware design that is running on a FPGA is called a hardware process.

BORPH uses regions of FPGA fabric as computation units to spawn hardware processes. Each reconfigurable region is defined as a hardware region (hwr). Logically, it is the smallest unit of a RC that is managed by BORPH. Physically, it can be implemented as an entire FPGA in a multi-FPGA system, or a partially reconfigurable region within a FPGA. On a BEE2 module, there is only one hwr type defined, the b2fpga, which corresponds to one user FPGA.

Starting a Hardware Process

A user starts a hardware process by executing a BORPH Object File (BOF) file as if it is any other Linux executable, such as ELF or A.OUT. When a BOF file is executed, the kernel examines hardware configurations encapsulated in that file. Based on this information, the kernel chooses and configures one or more suitable hwr’s in the system for this BOF file. On a BEE2, since each hwr corresponds to one user FPGA, it means the kernel will choose a suitable user FPGA to spawn this BOF file. The spawning of BOF files are handled natively by the kernel using standard fork and exec syscall.

A running hardware process behaves almost identically to any other software process in a Linux system. Users can, for example, check the status of hardware processes using command such as ps. A hardware process can be terminated by command like kill or by simply pressing Ctrl-C. The following shows a typical session of executing a BOF file, checking the value of an ioreg, and terminating the process. 

  1:bash% ./counter.bof &
  [1] 2458
  2:bash% ps
  PID TTY TIME CMD
  2456 pts/4 00:00:00 bash
  2458 pts/4 00:00:00 counter.bof
  2507 pts/4 00:00:00 ps
  3:bash% cat /proc/2458/hw/ioreg/cntval
  A3B498E0
  4:bash% cat /proc/2458/hw/ioreg/cntval
  B289E906
  5:bash% kill -9 2458
  [1]+ Killed counter.bof
  6:bash%

Communicating with a Hardware Process

There are two primary methods to communicate with a hardware process: the ioreg interface described here, and standard Linux file I/O described in next subsection.

The ioreg Interface

BORPH’s ioreg interface encapsulates conventional memory mapped I/O concept with a virtual file system interface.

Communication between hardware and software usually involves defining a set of special hardware registers and shared memory regions that are mapped into memory space of a processor. Instead of requiring the FPGA designer to redesign a driver interface for each FPGA design, BORPH encapsulate this common design practice by supporting it systematically via its ioreg interface.

The ioreg interface extends a conventional Linux proc file system. A new hw directory is populated for each hardware process with information specific to a hardware design. For a hardware process with pid of <pid>, listing the directory /proc/<pid>/hw/ will shows the following three files: 

 bash% cat /proc/123/hw/hardware_region
 Region 0
   Address: 0x1
 bash%

It shows hardware process 123 is currently running at hardware region address 1. On a BEE2, it means it is physically running at user FPGA2. 

 bash% cat /proc/123/hw/ioreg_mode
 0
 bash% echo 1 > /proc/123/hw/ioreg_mode
 bash% cat /proc/123/hw/ioreg_mode
 1
 bash%

Reading and writing to a virtual file in this directory will be translated into reading and writing to the corresponding hardware resource in a hardware process. The detail of communication is documented in [Designing for BORPH HowTo]. Here, the usage of these files is first described.

An ioreg virtual file can represent one of the following physical resources:

  1. Single 32-bit word register

  2. On-chip Block RAM (BRAM)

  3. Off-chip memory connected to a user FPGA

Let's take a single word register as an example to explain how an ioreg virtual file work. For example, we have a register, cnt_val that stores the current value of a counter in a hardware process. To read the content of this register, a user may do the following: 

 bash% cat /proc/123/hw/ioreg/cnt_val
 00AF0123
 bash%

Note two things: First, the value of the register is read live from the running hardware. The value is read when the moment the kernel receives a read syscall from the command cat. Second, the value returned is represented as a 8-digit hexadecimal number using ASCII representation. This behavior is controlled by the value of ioreg_mode, which by default is "0", meaning it is in ASCII mode. If it is changed to "1", the value 11,469,091 is returned in a single 32-bit word with big endian encoding. This is usually not what you want to use in a shell because this value is not printable. However, if a software program is reading or writing to ioreg files, binary mode communication is usually preferred as it eliminates the need for ASCII conversion.

An ioreg virtual file that corresponds to a memory (either on-chip or off-chip) resource maps all contents of the memory in the file. As result, reading or writing into n bytes offset from the beginning of the file corresponds to accessing the n-th byte of the memory.

The General File System Interface

The second method a hardware process can communicate with the rest of the system is through access to the general file system. Similar to a normal Linux process, when a hardware process is started, the kernel open standard input and standard output for the process by default. A hardware process can therefore read from stdin, which is usually connected to the shell keyboard input. Alternatively, a hardware process can print to stdout, performing simple debugging by printing. A hardware process communicates with the kernel through a predefined packet network described in [Designing for BORPH HowTo].

Designing for BORPH HowTo

Befor you read on ...

The best way to get a taste of how to use BORPH is to follow these step-by-step BorphTutorials. Most of them are designed around our Simulink based MSSGE design flow. Howerver, since BORPH simply provides OS level support for BEE2, it does not depend on any language. More tutorial on how to make a BORPH compatible binary will be available soon. For now, the following sections give you some idea about the low level BORPH kernel interaction with a user design.

Preparing the hardware

BORPH uses the Selectmap programming/communication interface to program the userFPGAs and then communicate with them. This means that an opb_selectmap core (latest version) has to be present in the Control FPGA design and correctly hooked-up to the PowerPC running BORPH Linux. On the userFPGA side, an opb_selectmap_fifo core is required and should be correctly attached to the processor (PowerPC or Microblaze).

Preparing the software

  1. A BORPH Linux has to be compiled to run on the Control FPGA. It is compiled the exact same way a regular linux kernel is (see Bee2LinuxKernel). It is also self contained and once running it is able to start any BORPH file. An ACE file for the control FPGA with precompiled kernel and bitstream can be found here: borph.ace.

  2. On the User FPGA, the following code has to be modified and compiled to run on the processor with EDK. The two main functions to modify are "size_loc" and "map_loc", that are associating the "location" number for a ressource to its size and address. Each hardware ressource in the user FPGA has to be assigned a unique ID, coded on 24 bits and called the "location" of this ressource. This ID is going to be used by BORPH during each access request to identify the file or ressource it is talking to. 

/* ************************************ */
/* *                                  * */
/* * BEE2 BORPH communication example * */
/* *                                  * */
/* ************************************ */

/* 2006 Pierre-Yves droz */

/* Main file */

#include "xparameters.h"
#include "xbasic_types.h"
#include "xcache_l.h"
#include <stdio.h>
#include <stdlib.h>

#define MAX_PACKET_SIZE 1000
#define MAX_LOC         100

/*****************************************************************
 * Data macros
 *****************************************************************/

#define SELECTMAP_FIFO_NUM_WORDS 128

static inline Xuint32 GET_STATUS() 
{ 
  return XIo_In32(XPAR_OPB_SELECTMAP_FIFO_0_BASEADDR); 
}
static inline Xuint8  SELECTMAP_STATUS(Xuint32 word)
{ 
  return (Xuint8)((word >> 24) & 0xff); 
}

#define SELECTMAP_RFIFO_CNT(word) (Xuint8)((word >> 16) & 0xff)
#define SELECTMAP_WFIFO_CNT(word) (Xuint8)((word >> 8)  & 0xff)

/* Prototypes */
/* ********************************* */
void add_cmds();
void outbyte(unsigned char c);
int  inbyte();
void intr_selectmap(void);
void send_writeack(unsigned location, int val);
void send_selectmap_byte(unsigned char c);
unsigned char receive_selectmap_byte();
unsigned int receive_selectmap_int3();
void send_selectmap_int3(unsigned int data);
unsigned int receive_selectmap_int4();
void send_selectmap_int4(unsigned int data);

/* Globals */
/* ********************************* */
unsigned char last_byte_written;

/* Main thread */
/* ********************************* */

int main(void)
{
  int i;

/* activate the cache on the PPC */
  XCache_EnableICache(0x00000001);
  XCache_EnableDCache(0x00000001);

/* wait for greet from the BORPH linux */
  i = 0;
  do {
    i <<= 8;
    i |= receive_selectmap_byte();
  } while (i != 0x10FFAA55);

/* display welcome message */
  xil_printf("\n\r");
  xil_printf("***************\n\r");
  xil_printf("* Hello World *\n\r");
  xil_printf("***************\n\r");

/* loop waiting for chars and echo them */
  while(1) {
    outbyte(inbyte());
  }

}

/* The size_loc function associates a specific location number to its actual size in bytes */
/* ********************************* */
int size_loc(int location) {
        /* To be implemented by the user */;
}

/* The map_loc functio associates a specific location number to its actual address */
/* ********************************* */
Xuint32 map_loc(int location) {
        /* To be implemented by the user */;
}

/* The outbyte function implements stdout to the BORPH linux */
/* ********************************* */

void outbyte(unsigned char c)
{

  /* memorizes the last byte sent */
  last_byte_written = c;

  /* send a "write at location 1" packet to the control FPGA */
  /* Write command */
  send_selectmap_byte(3);
  /* location = 1 */
  send_selectmap_int3(1);
  /* offset = 0 */
  send_selectmap_int4(0);
  /* size = 1 */
  send_selectmap_int4(1);
  /* payload is the character */
  send_selectmap_byte(c);
  /* interrupt */
  intr_selectmap();
}

/* The inbyte function implements stdin from BORPH linux, it is also in charge of answering transfer requests from BORPH linux */
/* ********************************* */

int inbyte()
{
  unsigned char cmd;
  unsigned int location,size,offset,block_size,transfer_size;
  int i;
  Xuint32 data;
  core current_core;

  /* send a "read at location 0" packet to the control FPGA */
  /* Read command */
  send_selectmap_byte(1);
  /* location = 0 */
  send_selectmap_int3(0);
  /* offset = 0 */
  send_selectmap_int4(0);
  /* size = 1 */
  send_selectmap_int4(1);
  /* wait for packets from the control FPGA */
  /* HS: but we need to interrupt control FPGA to get this request */
  intr_selectmap();
  while(1) {
    cmd = receive_selectmap_byte();
    switch(cmd) {
      case 1 : /* read */
        /* get the location */
        location = receive_selectmap_int3();
        /* get the offset */
        offset = receive_selectmap_int4();
        /* get the size */
        size = receive_selectmap_int4();
        /* if location is 0, then output the location table */
        if(location == 0) {
            /* -- future implementation of location table output here -- */
        } else {
          /* check if location is greater than max location */
          if(location >= MAX_LOC) {
              /* -- future implementation of error handling here -- */
              /* -- error wrong location -- */
          } else {
            block_size = size_loc(location);
            if(offset+size>block_size) {
              size = block_size - offset;
            }
            if(offset>=block_size) {
              /* -- future implementation of error handling here -- */
              /* -- wrong seek -- */
            }
            offset += map_loc(location);
            data = XIo_In32(offset & 0xFFFFFFFC);
            while(size != 0) {
              if(size > MAX_PACKET_SIZE-10)
                transfer_size = MAX_PACKET_SIZE-10;
              else
                transfer_size = size;
              size -= transfer_size;

              /* Send read ack command */
              send_selectmap_byte(2);
              /* location */
              send_selectmap_int3(location);
              /* size */
              send_selectmap_int4(transfer_size);
              /* payload */
              for(;transfer_size != 0;transfer_size--) {
                send_selectmap_byte(((unsigned char *) &data)[offset % 4]);
                offset++;
                if(offset % 4 == 0)
                data = XIo_In32(offset);
              }
              intr_selectmap();

            }
          } 
        }
        break;
      case 2 : /* read ack */
        /* get the location. It should be 0 only as we don't read from anything else*/
        location = receive_selectmap_int3();
        if(location != 0) xil_printf("Error: Wrong location\n\r");
        /* get the size in bytes. If it is one, it means that one of our read succedded, and we return the payload */
        size = receive_selectmap_int4();
        if(size == 1) return receive_selectmap_byte();
        /* if we received an error code, we send a new request */
        /* HS should wait a bit before stalling cntrl fpga */
        usleep(100000);
        /* send a "read at location 0" packet to the control FPGA */
        /* Read command */
        send_selectmap_byte(1);
        /* location = 0 */
        send_selectmap_int3(0);
        /* offset = 0 */
        send_selectmap_int4(0);
        /* size = 1 */
        send_selectmap_int4(1);
        /* interrupt */
        intr_selectmap();
        break;
      case 3 : /* write */
        /* get the location */
        location = receive_selectmap_int3();
        /* get the offset */
        offset = receive_selectmap_int4();
        /* get the size */
        size = receive_selectmap_int4();
        /* if location is 0, then this is an error */
        if(location == 0) {
          send_writeack(location, -2);
          /* -- future implementation of error handling here -- */
          /* -- error unwritable -- */
        } else {
          /* check if location is greater than max loc */
          if(location >= MAX_LOC) {
            /* -- future implementation of error handling here -- */
            /* -- error wrong location -- */
            send_writeack(location, -3);
          } else {
            block_size = size_loc(location);
            if(offset+size>block_size) {
              size = block_size - offset;
            }
            if(offset>=block_size) {
                 /* -- future implementation of error handling here -- */
                 /* -- wrong seek -- */
            }
            offset += map_loc(location);
            /* prefetch data for the first read modify write operation */
            data = XIo_In32(offset & 0xFFFFFFFC);
            /* payload processing */
            for(transfer_size = 0;transfer_size < size;transfer_size++) {
              ((unsigned char *) &data)[offset % 4] = receive_selectmap_byte();
              offset++;
              if(offset % 4 == 0) {
                XIo_Out32(offset-4,data);
                /* save some cycles */
                if (size - transfer_size <= 4) {
                  data = XIo_In32(offset & 0xFFFFFFFC);
                }
              }
            }
            if (offset % 4 != 0) {
              XIo_Out32(offset & 0xFFFFFFFC, data);
            }
            /* Send write ack command */
            send_selectmap_byte(4);
            /* location */
            send_selectmap_int3(location);
            /* size */
            send_selectmap_int4(size);
            /* interrupt */
            intr_selectmap();
          }
        }
      case 4 : /* write ack */
        /* get the location */
        location = receive_selectmap_int3();
        /* get the size */
        size = receive_selectmap_int4();
        /* check the size */
        if(size==0) {
          /* last write failed, send it again */
          /* send a "write at location 1" packet to the control FPGA */
          /* Write command */
          send_selectmap_byte(3);
          /* location = 1 */
          send_selectmap_int3(1);
          /* offset = 0 */
          send_selectmap_int4(0);
          /* size = 1 */
          send_selectmap_int4(1);
          /* payload is the character */
          send_selectmap_byte(last_byte_written);
          /* interrupt */
          intr_selectmap();

        }
        break;
      case 17: /* bye */
          /* remove magic from the fifo */
          receive_selectmap_byte();
          receive_selectmap_byte();
          receive_selectmap_byte();
          data = 0x30000000;
          asm("mtdbcr0 %0" :: "r"(data));
        break;
      default : /* unknown packet type */
          /* -- future implementation of error handling here -- */
          /* -- error unknown packet -- */
        break;
    }
  }
}

void send_writeack(unsigned location, int val)
{    
    /* Send write ack command */
    send_selectmap_byte(4);
    /* location */
    send_selectmap_int3(location);
    /* size */
    send_selectmap_int4(val);
    /* interrupt */
    intr_selectmap();
}

void intr_selectmap(void)
{
    XIo_Out32(XPAR_OPB_SELECTMAP_FIFO_0_BASEADDR, 1);
}

void send_selectmap_byte(unsigned char c)
{
  int retry = 0;

  /* block on fifo full */
  while (!SELECTMAP_WFIFO_CNT(GET_STATUS())) {
    if (!(retry & 0xFFFF)) {
      intr_selectmap();
    }
    retry += 1;
  }
  /* send the byte */
  XIo_Out8(XPAR_OPB_SELECTMAP_FIFO_0_BASEADDR+4, c);
}

unsigned char receive_selectmap_byte()
{
  /* block on fifo empty */
  while (!SELECTMAP_RFIFO_CNT(GET_STATUS())) {

  }
  /* read the byte */
  return XIo_In8(XPAR_OPB_SELECTMAP_FIFO_0_BASEADDR+4);
}

unsigned int receive_selectmap_int3()
{
  unsigned int data = 0;
  
  data = receive_selectmap_byte();
  data <<= 8;
  data |= receive_selectmap_byte();
  data <<= 8;
  data |= receive_selectmap_byte();

  return data;
}

void send_selectmap_int3(unsigned int data)
{
  send_selectmap_byte(data >> 16);
  send_selectmap_byte(data >>  8);
  send_selectmap_byte(data >>  0);
}

unsigned int receive_selectmap_int4()
{
  unsigned int data = 0;

  data = receive_selectmap_byte();
  data <<= 8;
  data |= receive_selectmap_byte();
  data <<= 8;
  data |= receive_selectmap_byte();
  data <<= 8;
  data |= receive_selectmap_byte();

  return data;
}

void send_selectmap_int4(unsigned int data)
{
  send_selectmap_byte(data >> 24);
  send_selectmap_byte(data >> 16);
  send_selectmap_byte(data >>  8);
  send_selectmap_byte(data >>  0);
}

Compiling a design

Once the UserFPGA design has been compiled with EDK, the bitfile has to be transformed into a BORPH executable file using the command "mkbof". The syntax of makebof is as follows: 

mkbof -o <output_file> -s <symbol_file> [-p <hard_location>] <bitfile>

where:

  1. <output_file> is the name of the BORPH executable to be produced

  2. <symbol_file> is the file indicating the matching between a ressource and its name, size, and permission. Inside the user has to write a list of TAB separated values (one line per ressource) indicating all the needed data. 

    •   <Ressource name>\TAB<Permission>\TAB<Location>\TAB<Size>

      <Ressource_name> is the name of the file that will be associated with the ressource. <Permission> is 1 for Read only, 2 for Write Only, 3 for Read Write. <Location> is the unique ID of the ressource (it has to match the one defined in the UserFPGA software). <Size> is the size in bytes of the ressource.

  3. <hard_location> is optional and can be 0, 1, 2 or 3. If defined it forces the BORPH executable to be started on a specific FPGA instead. If not defined, the design is floating and BORPH will automatically find a free FPGA to start the design.

  4. <bitfile> is the .bit file compiled by EDK

Obtaining BORPH

The BORPH source tree will be available through the BEE2 CVS soon. In the mean time, you can download the latest snapshot directly from here:

Paper about BORPH

Bee2OperatingSystem (last edited 2006-12-30 16:05:49 by localhost)

Bee2Pins - BEE2wiki

Pin Assignment

In order to use the external peripherals connected to the BEE2 FPGAs, you will need to know the external pin assignment. Fortunately, many of the cores provided in the BEE2 infrastructure package contain the pin information within the cores themselves, which means that using these cores is as simple as dropping them into your design. However, some of the cores require external pin assignment via a UCF file, and there may be times when a user wants access to the external pins directly. In the former case, the easiest way to get the UCF constraints is to view the UCF files contained within our reference examples (see Bee2Reference). In the latter case, we have provided an Excel file that can easily be searched to determine pin information. This document gives a very brief overview of how to find and use this pin database.

Pin Assignment Spreadsheet

All pin assignments for both user FPGAs and the control FPGA can be found in our pin assignment spreadsheet Pin_assign.xls

In the spreadsheet the pin assignments can be found on the sheets labeled ctrlFPGA for the control FPGA and usrFPGA for the user FPGA. The following is an example of what the ctrlFPGA sheet looks like:

The key parts of the spread sheet are the following columns:

Bee2Pins (last edited 2006-06-26 16:12:57 by alschult)

Bee2QuickStart - BEE2wiki

BEE2 Quick Start

The purpose of this document is to walk the user through the use of the BEE2 board from initial bring up, all the way through using the Xilinx tools to build new bitstreams for the board.

  1. BEE2 Quick Start
    1. BEE2 Overview
    2. Cables, Parts, and Connections
    3. Testing BEE2 with Self-Test Suite
    4. Booting Reference Designs
    5. Building Reference Designs
    6. Designing for the BEE2
    7. Getting More Help

BEE2 Overview

Background

The BEE2 system is designed to be a modular, scalable FPGA-based computing platform with a software design methodology that targets a wide range of high-performance applications, such as:

The modular system architecture can not only provide orders of magnitude reduction in overall cost and design time, but it also closely tracks the early adoption of state-of-the-art IC fabrication by FPGA vendors. Users of the BEE2 have the freedom to choose the appropriate number of computational modules needed to tackle the application at hand, and to rapidly reconfigure to switch to a different application.

Module Information

The BEE2 is a general purpose processing module based on five, high-performance Xilinx FPGAs (Virtex II Pro 70). In addition to the large amount of processing fabric provided by the FPGAs, the BEE2 also provides up to 20GB of high-speed, DDR2 DRAM memory. Each of the five FPGAs has four independent channels to DDR2 DIMMs which provides very high memory bandwidth. Finally, the FPGAs on the BEE2 are highly connected with both high-speed, serial and parallel links.

The FPGAs are laid out in a star topology with four user FPGAs in a ring and one control FPGA connected to each user. The user FPGAs each have four independent high speed serial channels (4 bonded MGTs) which are capable of transferring data at 10Gbps through CX4 connectors (both copper and fiber). The user FPGA ring consists of parallel connections of 138 high-speed LVCMOS traces between the FPGAs which can run at a maximum of 400Mbps. The control FPGA has two high-speed serial channels, 64 LVCMOS traces to each user FPGA, and connections to common peripherals such as 10/100 ethernet, USB 1.1, RS232 serial, DVI, and GPIOs.

Detailed information about the BEE2 module, including its architecture, links to data sheets, BOM, and source code can be found here:

http://bee2.eecs.berkeley.edu/module/

Cables, Parts, and Connections

The first step is to acquire all of the necessary cables, power supply, memory, and media for the BEE2. Next, you will need to check that all of the required jumpers are in place, and finally connect the BEE2. Information on all of these steps can be found in the Bee2Setup page.

Testing BEE2 with Self-Test Suite

The next step is to verify that your BEE2 module is operating correctly. Most BEE2 boards will be verified by the assembler before shipping to users. However, it is still a good idea to run the self-test suite upon receiving a new BEE2 board to make sure nothing was damaged in shipping. For instructions on acquiring and running the test suite, see the Bee2TestSuite page.

Booting Reference Designs

Reference Linux System

We have provided a pre-built reference Linux system that makes it easy to bring up the BEE2 with Linux. This reference design has very little gateware outside that required to boot Linux. To use this bitstream, the only requirement is that one 1GB DIMM be placed in control FPGA DIMM socket one.

The first step is to download the pre-built Linux bitstream (system.ace file) from the Bee2Binaries page. The page also has instructions on how to format the CompactFlash card to boot with the bitstream.

Next, you will need to prepare a root filesystem for Linux. To place the root filesystem on a CompactFlash card, read Bee2DebianRootFs and to place the filesystem on a NFS mount (this has much better performance) read Bee2DebianRootNfs.

Once the root filesystem is in place, you will need to configure your BEE2 board's MAC address, baud rate, and boot string. The Bee2LinuxConfig page explains how to use the test-suite to configure the board. Once this is done you are ready to boot the design. Information on booting this design can be found in the Bee2Reference page.

Other Reference Designs

There are several other reference designs that are provided in both binary and source format. These reference designs include:

Building Reference Designs

All of the reference designs on the Bee2Reference page have instructions for building the reference design from source.

Designing for the BEE2

Starting with Reference Designs

When you start to design your own projects for the BEE2, the best resource and starting point is the existing reference designs. If you are designing in XPS, starting with a base design like the Linux reference makes it easy to import common infrastructure like system clocks and constraints.

If you need examples of using other pieces of BEE2 specific infrastructure such as the interchip links or high-speed serial, the DSP and MPI reference designs are both good examples of how to instantiate and use those pieces.

BEE2 Infrastructure Documentation

If you need information on the general operation of BEE2 specific subsystems (such as the memory system, communication infrastructure, or configuration) the best resource is the BEE2 overviews. You can find overviews of all the major subsystems on the homepage of the BEE2 wiki.

For more indepth technical detail on individual hardware cores that have been provided with the BEE2 board you should visit the Bee2Cores page. This contains documents on low-level technical detail of the cores including functional descriptions, register definitions, and timing information. Most users won't need this level of detail, as most of the cores come with drivers to abstract away most of the details.

Finally, for information on specific pin locations for the BEE2 control and user FPGAs you can visit the Bee2Pins page to download a spreadsheet that contains the relevant information. Almost all of the pin locations are either embedded in the specific hardware cores or are available in example UCF files in the reference designs (all designs have their UCF files in data/system.ucf).

BEE2 Errata

Sometimes there are certain tips or tricks that you have to play in order to get things working right. Rather than bury these details in the guts of some other document, we have created the Bee2Errata page that is a quick guide to these tricks. Before embarking on your own design, or if you encounter something weird in your design, this is the first place to look. Also, if you come across any specific details that don't fit anywhere else in the documentation, please dump them in the errata.

Getting More Help

If the Wiki documentation doesn't have the information you need, there also exists a BEE2 users mailing list to which you can post questions. Before posting please check the mailing list archive (http://bee2.eecs.berkeley.edu/lists) to see if your question has already been answered. If you would like to post a question, you must first register for the mailing list. To do so, please send an email to

 majordomo@lists.berkeley.edu 

with the following in the body of the message

 subscribe bee2-users 

To prevent spam the list is not completely open. Your subscribe request will be reviewed by the maintainer of the BEE2 list and you will be granted access to post to the list as soon as that is done. If the maintainer is unaware of your relationship to the BEE2 project, you may receive mail asking who you are.

Finally, if you have comments or questions that can only be answered by the BEE2 maintainers please feel free to send email to "bee2-maintainers at lists dot berkeley dot edu". Please restrict these emails to questions that you feel could not be answered by the larger BEE2 community, problems with the website or other infrastructure, or comments and feedback (or use our Bee2Feedback page to send feedback).

Bee2QuickStart (last edited 2006-07-04 20:12:58 by alschult)

Bee2Readme - BEE2wiki

BEE2 Documentation Readme

Documentation Philosophy

The bulk of the documentation for the BEE2 can be found online in our BEE2 wiki (http://bee2.eecs.berkeley.edu/wiki). For those of you unaccustomed to Wikis, they are essentially web pages that are freely editable by the community of users. Because the BEE2 is maintained by a primarily academic community, using a Wiki is an attractive option which allows the broader BEE2 user community to help improve the quality and breadth of the documentation.

In addition to the online Wiki, the documentation can also be found as a monthly snapshot that can be downloaded in HTML format. The snapshot is provided primarily as a convenience for offline access, and it should be remembered that the most up to date documentation can always be found on the evolving Wiki.

As a BEE2 user, please feel free to contribute to the documentation effort by either fixing bugs in the documentation as you come across them, adding questions and answers to FAQ sections found on most of the documentation pages, or even adding complete walkthroughs or documentation on new features.

Documentation Structure

All documentation for the BEE2 begins at the root page of the Wiki (http://bee2.eecs.berkeley.edu/wiki). From there the documentation is broken down into several sections.

  1. Board Support Package - The board support package documentation provides information on all the software and gateware infrastructure that has been developed for the BEE2. This includes things like the built in self test (BIST), source code repository access, reference designs, pre-compiled bitstreams, and major subsystem overviews. Most users will be interested in the documentation found in this section.

  2. Walkthrough's and Guides - The walkthrough section contains step-by-step guides on performing common tasks with the BEE2. Examples include setting up the board, building a Linux kernel, and setting up a Linux root file system.

  3. Module Hardware Reference - The module reference section contains information pertaining to the BEE2 PCB and low level details of the BEE2 hardware.

Getting More Help

If the Wiki documentation doesn't have the information you need, there also exists a BEE2 users mailing list to which you can post questions. Before posting please check the mailing list archive (http://bee2.eecs.berkeley.edu/lists) to see if your question has already been answered. If you would like to post a question, you must first register for the mailing list. To do so, please send an email to

 majordomo@lists.berkeley.edu 

with the following in the body of the message

 subscribe bee2-users 

To prevent spam the list is not completely open. Your subscribe request will be reviewed by the maintainer of the BEE2 list and you will be granted access to post to the list as soon as that is done. If the maintainer is unaware of your relationship to the BEE2 project, you may receive mail asking who you are.

Finally, if you have comments or questions that can only be answered by the BEE2 maintainers please feel free to send email to "bee2-maintainers at lists dot berkeley dot edu". Please restrict these emails to questions that you feel could not be answered by the larger BEE2 community, problems with the website or other infrastructure, or comments and feedback (or use our Bee2Feedback page to send feedback).

Bee2Readme (last edited 2006-06-28 18:19:51 by alschult)

Bee2Reference - BEE2wiki

BEE2 Reference Designs

  1. BEE2 Reference Designs
    1. Retrieving Reference Designs
    2. Preparing Compact Flash Cards for Booting
    3. Minimal Linux Reference Design
      1. Booting Linux Reference
      2. Builing Linux Reference
    4. MPI Reference Design
      1. Booting MPI Reference

One of the easiest ways to learn how to use the BEE2 and how to design for the BEE2 is to use and examine reference designs. This page lists several reference designs provided with the board support package that are designed to utilize all of the features unique to the BEE2 board.

The following reference designs are included:

Retrieving Reference Designs

All reference base systems are available in either binary or source form. To download a pre-compiled binary of a specific base system, visit the Bee2Binaries page.

To get a copy of the reference design in source form, visit the BEE2 homepage and download the reference source package (you will also probably need the repository and linuxppc-2.4 source packages as well).

Preparing Compact Flash Cards for Booting

Detailed instructions for preparing a CompactFlash for configuration files (ACE files) and for use as a Linux root filesystem can be found in the Bee2Binaries page.

It is also recommended that you setup your CF card with the Default Boot Compact Flash files found on the binaries page. This configuration allows you to easily boot your own design, a "failsafe" Linux design, and the test-suite just by changing a configuration jumper (see Bee2Setup for more information).

Minimal Linux Reference Design

Booting Linux Reference

Hardware Requirements

For more information on specific part numbers and instructions for connecting the BEE2, see the Bee2Setup page.

Instructions

  1. Prepare CompactFlash card via the instructions found on the Bee2Binaries page. Use the instructions on Bee2DebianRootFs to prepare the CF card for a Linux root filesystem, or skip it if you plan to use NFS to mount the root.

    1. We recommend using the Default Boot Compact Flash files as the base for your configuration partition since they allow you quick access to a "failsafe" boot and the test-suite.

    2. To prepare a root filesystem, follow the instructions in Bee2DebianRootFs to boot from the CF card, or from Bee2DebianRootNfs to boot from a NFS mount (this is preferred since it is much faster).

  2. Prepare your board for booting Linux. Follow the instructions found in Bee2LinuxConfig to setup the EEPROM configuration strings.

  3. Download binary of Linux reference design from Bee2Binaries page and install it on the configuration partition of the CF card. You will need the system.ace file.

    1. If you are using the Default Boot Compact Flash setup, you will need to copy the ace file to /MNT/POINT/cf/standard/standard.ace

    2. If you are just using an empty configuration partition, simply copy the file to /MNT/POINT/system.ace

  4. Connect RS232 serial cable to BEE2 and PC and setup terminal emulation program.

    1. Use the following settings: Baud rate = 115200, 8-bit data, no parity, 1 stop bit, no flow control.

  5. (Optional) Connect a LCD monitor via an HDMI to DVI connector. The default system uses the frame buffer and the boot messages will show up when booting.

  6. Apply power to board. As always, before powering on make sure the supply is set to 5V, and if it is a current limited supply, it is a good idea to current limit to ~30A for this configuration.

Builing Linux Reference

  1. Download source packages reference, repository, and linuxppc-2.4 (instructions for downloading can be found in Bee2Cvs page).

    1. Prepare the reference by entering reference/XPS_Ctrlfpga_linux and running ./symlinks.sh /PATH/TO/repository to create pcore symlinks.

  2. Generate the hardware bitstream by running xps -nw system.xmp and then type run init_bram

  3. Generate the software BSP by running run libs from within Platform Studio. Copy the generated BSP files to the linux source tree by running:

    • cp -a ppc405_0/libsrc/linux_mvl31_v1_01_a/* /PATH/TO/linuxppc-2.4

  4. Build the Linux kernel and generate the ACE file (detailed instructions are available on Bee2LinuxKernel).

MPI Reference Design

Booting MPI Reference

Hardware Requirements

For more information on specific part numbers and instructions for connecting the BEE2, see the Bee2Setup page.

Instructions

  1. See "Minimal Linux Reference Design" and use all steps to bring up board. The only change is to use the "MPI Reference" control FPGA bitstreams on the Bee2Binaries page.

Bee2Reference (last edited 2006-06-30 06:44:10 by alschult)

Bee2Setup - BEE2wiki

BEE2 Setup Guide

Introduction

Parts List

Power

5V DC power supply

Should be capable of output >300W @ 5V, optimally with remote sensing

Suggested: Lambda GENH 6-100

Suggested:Xantrex XHR 7.5-130

Acceptable: Meanwell SP-480-5 (Remote sense terminal crimp, Remote sense terminal housing) Please note that this is not an isolated power supply has been shown to be a significant EMI source.

Power Cable

Cable used should be at least 10AWG and be kept as short as possible if power supply has no remote sensing

Crimp terminals: Molex 42815 series -0031 tin 8AWG, -0032 gold 8AWG, -0011 tin 10/12AWG, -0012 10/12AWG

Crimp housing: Molex 42816-0212

Memory

DDR2 SDRAM DIMMs

Should be 1GB unregistered ECC memory rated for 200MHz operation with CAS latency 3

Suggested: Crucial CT12872AA53E

Suggested: Micron MT18HTF12872AY-40E

Suggested: Micron MT18HTF12872AY-53E

Suggested: Micron MT18HTF12872AY-667

Video

HDMI male to DVI male cable

Suggested: LCD Panel Samsung 731B

Example: DigiKey WM19082-ND

Example: DigiKey 290-1915-ND

High Speed Serial

10GbE/InfiniBand cable

Should be 3 meters or shorter

Suggested: Gore IBN6800-0.5 -1 or -3

Suggested: Fujitsu FCD-ZZ00016 or FCD-ZZ00019

10Gb Fiber Optic cable

Requires tranceiver and spool of fiber cable, tested up to 100 meters

Suggested: Fujitsu FPD-010R008-0E + FOC-CCxxxx

Low Speed Serial

RS232 serial cable

Custom null-modem RS232 with DB9 female to 5x1 0.100" (2.54mm) female header connector

Wiring diagram

Storage/Boot/Debug

CompactFlash card

Any size from 16MB up to 2GB from any CF vendor

Suggest at least 512MB for Linux boot from CF

PIV programming cable

9 pins single row, 2.54mm pitch flat ribbon cable

Suggested: DigiKey A9BBG-090xF-ND

Real Time Clock

CR1220 3V 12.5mm coin battery

Suggested: DigiKey N033-ND

Suggested: DigiKey P033-ND

Manual Inspection

Connecting the BEE2

Bee2Setup (last edited 2007-02-21 01:27:29 by hchen05)

Bee2TclRewrite - BEE2wiki

Using Embedded TCL Rewriting on XPS Designs

  1. Using Embedded TCL Rewriting on XPS Designs
    1. Introduction
    2. Overview of Embedded TCL Rewriting
    3. Embedded TCL Rewriting Example
      1. Download the Source
      2. TCLized Files
      3. Example External Parameters
      4. Example TCLized Code
      5. The Rewriter Script
    4. Building the Example (using rewriting)
    5. Using Embedded TCL Rewriting in Other Projects
    6. Frequently Asked Questions

Introduction

For many Xilinx Platform Studio (XPS) designs and hardware cores it is often desirable to be able to change some aspect of the design based on external parameters. For the design of hardware cores with an HDL the majority of parametrization can be done through the use of generics (or parameters) and generate statements. However, for changes to the interface of an HDL design or changes to XPS base system files, there is no standard way to automate design changes.

For example, a XPS design with multiple soft core processors may wish to easily vary the number of cores and other parameters such as connectivity or features without having to cut and paste or muck around with a GUI. Another example is a hardware core that operates as a multiport switch and would like to be able to vary the number of ports.

To address this problem at BWRC, we currently use a simple process we call "embedded TCL rewriting." Other users may have other methods to address the same problem, however several of the cores and reference designs included as part of the board support package use this scheme, so it is useful to explain how it works.

Overview of Embedded TCL Rewriting

Here is a quick, step by step explaination of how TCL rewriting works:

  1. Source code (HDL, MPD files, MHS files, etc) are written as normal except they are given the suffix .tcl For example the MHS file for a XPS project would go from system.mhs to system.mhs.tcl .

    1. Embedded anywhere in the source code the author can place arbitrary TCL variables in the form  ${VAR_NAME} . TCL variables are all strings and the variable will be expanded by preprocessing into a string representation of its value. For example a source line  PORT FSL_Rd_Control_${i}  with a value for  ${i}  of 1 at the time of preprocessing would expand to  PORT FSL_Rd_Control_1 .

    2. Arbitrary TCL code can also be embedded in the source by starting the line with the statement  !TCL! . Any statements after that line prefix will be treated as TCL code. This allows conditional, loop, and other statements to be generated.

  2. Any external parameters are placed in a .ini file which is pulled in by preprocessing code to set TCL variables.

  3. All code with .tcl suffix is preprocessed to generate a TCL rewriter script.

    1. Preprocessing is done by turning each file into an actual TCL script with the new suffix .tcl.tcl . b. Lines with !TCL! prefix are copied directly into new script. c. Lines without prefix are encapsulated in TCL "puts" statements which cause them to be printed by script and expand any embedded variables.

  4. The rewriter script is executed creating the actual source to be used by the tools. For example a file orginally called system.mhs.tcl will generate system.mhs .

Embedded TCL Rewriting Example

The best way to understand how TCL rewriting works, and how to use it yourself, is to examine an existing example. Several examples are available in the BEE2 board support package, so we will examine one that has the most extensive use of TCL rewriting.

Download the Source

First, download the "repository" and "reference" source code packages (see the Bee2Cvs page for instructions on downloading). Unzip both of the source packages and enter the reference/MPI_demo/XPS_Userfpga directory. Next, prepare the design by running

./symlinks.sh /PATH/TO/repository

which will setup symlinks from the IP core repository to the pcores directory in the design.

TCLized Files

If you poke around in the XPS_Userfpga directory you will notice several files with .tcl and .ini suffixes.

Example External Parameters

In the mb.ini file you will see what looks like TCL variable instantiations, which is exactly what the file does. For example: 

# Use XAUI
set USE_XAUI    1
set NUM_XAUIS   4

This code creates two variables $USE_XAUI and $NUM_XAUIS and sets their values. These variables will be availble to the TCLized code that is rewritten. This is the main mechanism for the user to change parameters that will be used to generate the code. Any valid TCL code is permissible in this file because it is simply sourced by the rewriting script.

Example TCLized Code

In the system.mhs.tcl file you will notice the following snippet of code: 

!TCL! if {$USE_XAUI == 1} {
!TCL!   for {set i 0} {$i < $NUM_XAUIS} {incr i} {
##
# XAUI port ${i}
##
 PORT mgt${i}_tx_l0_p          = mgt${i}_tx_l0_p, DIR = O
 PORT mgt${i}_tx_l0_n          = mgt${i}_tx_l0_n, DIR = O
 PORT mgt${i}_tx_l1_p          = mgt${i}_tx_l1_p, DIR = O
 PORT mgt${i}_tx_l1_n          = mgt${i}_tx_l1_n, DIR = O
 PORT mgt${i}_tx_l2_p          = mgt${i}_tx_l2_p, DIR = O
 PORT mgt${i}_tx_l2_n          = mgt${i}_tx_l2_n, DIR = O
 PORT mgt${i}_tx_l3_p          = mgt${i}_tx_l3_p, DIR = O
 PORT mgt${i}_tx_l3_n          = mgt${i}_tx_l3_n, DIR = O
 PORT mgt${i}_rx_l0_p          = mgt${i}_rx_l0_p, DIR = I
 PORT mgt${i}_rx_l0_n          = mgt${i}_rx_l0_n, DIR = I
 PORT mgt${i}_rx_l1_p          = mgt${i}_rx_l1_p, DIR = I
 PORT mgt${i}_rx_l1_n          = mgt${i}_rx_l1_n, DIR = I
 PORT mgt${i}_rx_l2_p          = mgt${i}_rx_l2_p, DIR = I
 PORT mgt${i}_rx_l2_n          = mgt${i}_rx_l2_n, DIR = I
 PORT mgt${i}_rx_l3_p          = mgt${i}_rx_l3_p, DIR = I
 PORT mgt${i}_rx_l3_n          = mgt${i}_rx_l3_n, DIR = I

!TCL!   }
!TCL! }

This code shows an example of how to use conditionals and loops to generate code based on external parameters. In the example there are two external variables ($USE_XAUI and $NUM_XAUIS) which are set via the parameter file. The variables are used to generate an IF statement and FOR loop around some MHS external port declarations. After preprocessing this translates into the following TCL code in the system.tcl.tcl file: 

set line_num 77;  if {$USE_XAUI == 1} {
set line_num 78;    for {set i 0} {$i < $NUM_XAUIS} {incr i} {
set line_num 79; puts $output_file "##"
set line_num 80; puts $output_file "# XAUI port ${i}"
set line_num 81; puts $output_file "##"
set line_num 82; puts $output_file " PORT mgt${i}_tx_l0_p          = mgt${i}_tx_l0_p, DIR = O"
set line_num 83; puts $output_file " PORT mgt${i}_tx_l0_n          = mgt${i}_tx_l0_n, DIR = O"
set line_num 84; puts $output_file " PORT mgt${i}_tx_l1_p          = mgt${i}_tx_l1_p, DIR = O"
set line_num 85; puts $output_file " PORT mgt${i}_tx_l1_n          = mgt${i}_tx_l1_n, DIR = O"
set line_num 86; puts $output_file " PORT mgt${i}_tx_l2_p          = mgt${i}_tx_l2_p, DIR = O"
set line_num 87; puts $output_file " PORT mgt${i}_tx_l2_n          = mgt${i}_tx_l2_n, DIR = O"
set line_num 88; puts $output_file " PORT mgt${i}_tx_l3_p          = mgt${i}_tx_l3_p, DIR = O"
set line_num 89; puts $output_file " PORT mgt${i}_tx_l3_n          = mgt${i}_tx_l3_n, DIR = O"
set line_num 90; puts $output_file " PORT mgt${i}_rx_l0_p          = mgt${i}_rx_l0_p, DIR = I"
set line_num 91; puts $output_file " PORT mgt${i}_rx_l0_n          = mgt${i}_rx_l0_n, DIR = I"
set line_num 92; puts $output_file " PORT mgt${i}_rx_l1_p          = mgt${i}_rx_l1_p, DIR = I"
set line_num 93; puts $output_file " PORT mgt${i}_rx_l1_n          = mgt${i}_rx_l1_n, DIR = I"
set line_num 94; puts $output_file " PORT mgt${i}_rx_l2_p          = mgt${i}_rx_l2_p, DIR = I"
set line_num 95; puts $output_file " PORT mgt${i}_rx_l2_n          = mgt${i}_rx_l2_n, DIR = I"
set line_num 96; puts $output_file " PORT mgt${i}_rx_l3_p          = mgt${i}_rx_l3_p, DIR = I"
set line_num 97; puts $output_file " PORT mgt${i}_rx_l3_n          = mgt${i}_rx_l3_n, DIR = I"
set line_num 98; puts $output_file ""
set line_num 99;    }
set line_num 100;  }

When this TCL code is executed the loop will setup the value of $i and will generate $NUM_XAUIS copies of the port declaration block with $i expanded out to "0 1 2 ...". The resulting system.mhs file will contain the following: 

##
# XAUI port 0
##
 PORT mgt0_tx_l0_p          = mgt0_tx_l0_p, DIR = O
 PORT mgt0_tx_l0_n          = mgt0_tx_l0_n, DIR = O
 PORT mgt0_tx_l1_p          = mgt0_tx_l1_p, DIR = O
 PORT mgt0_tx_l1_n          = mgt0_tx_l1_n, DIR = O
 PORT mgt0_tx_l2_p          = mgt0_tx_l2_p, DIR = O
 PORT mgt0_tx_l2_n          = mgt0_tx_l2_n, DIR = O
 PORT mgt0_tx_l3_p          = mgt0_tx_l3_p, DIR = O
 PORT mgt0_tx_l3_n          = mgt0_tx_l3_n, DIR = O
 PORT mgt0_rx_l0_p          = mgt0_rx_l0_p, DIR = I
 PORT mgt0_rx_l0_n          = mgt0_rx_l0_n, DIR = I
 PORT mgt0_rx_l1_p          = mgt0_rx_l1_p, DIR = I
 PORT mgt0_rx_l1_n          = mgt0_rx_l1_n, DIR = I
 PORT mgt0_rx_l2_p          = mgt0_rx_l2_p, DIR = I
 PORT mgt0_rx_l2_n          = mgt0_rx_l2_n, DIR = I
 PORT mgt0_rx_l3_p          = mgt0_rx_l3_p, DIR = I
 PORT mgt0_rx_l3_n          = mgt0_rx_l3_n, DIR = I

...

The Rewriter Script

The rewriter script gen_ip.tcl is customized to each particular project, so it requires some modification to work in different contexts. The heart of the script is the rewrite_file function. This function takes a TCLized source file and generates the TCL script that will output the rewritten file.

If you examine the gen_ip.tcl file you will see a section marked:

###### Main flow ######

The code following this marker is the customized code for the particular project. In this example the code does the following steps:

  1. Parse arguments and read in the INI file (common code)

  2. Rewrite the XPS project files (common code that needs to be slightly modified)

  3. Rewrite hardware cores that have variable interfaces (common code with heavier modifications)

  4. Rewrite the bootloader code (custom code)

Much of this code can be reused in other applications, and any specific steps you require for your particular project can be added as custom TCL code.

Building the Example (using rewriting)

The next step to understanding TCL rewriting is to actually build the example project. This will give you a feel for how the TCL rewriting process actually operates.

Thats it. Keep in mind that any time you make changes to the INI file, you need to rerun the gen_ip.tcl script and that it will change the timestamps on source code (which means the XPS tools will probably force a recompile).

Using Embedded TCL Rewriting in Other Projects

The general idea behind TCL rewriting will work with pretty much any text file. If you want to use TCL rewriting in your own core, project files, or other text source you mainly need to modify the gen_ip.tcl file to suit your particular needs.

If you are new to TCL, or if you just need a good reference, we suggest using the TCL Reference Manual. The whole process just involves normal TCL code, so no special syntax outside the use of the !TCL! prefix is required.

Frequently Asked Questions

None so far.

Bee2TclRewrite (last edited 2006-06-28 16:57:45 by alschult)

Bee2TestSuite - BEE2wiki

BEE2 Self-Test Suite

  1. BEE2 Self-Test Suite
    1. Performing initial power-up test
    2. Acquiring Self-Test Suite
    3. Using Self-Test Suite

This page describes the BEE2 self-test suite (STS). The STS has a series of tests and utilities that can be used to verify the proper operation of your BEE2 and aid in its configuration. This document describes how to download and run the STS, and also how to build it from source.

Performing initial power-up test

The test procedure for starting a completely new, untested board can be found here. All boards are passed through this test before shipping out.

Acquiring Self-Test Suite

We have provided a binary version of the self test suite for those of you who don't like spending hours waiting for tools to run. You can download test_suite.zip which contains all of the files needed to run the test suite.

Formatting the CF

The SystemACE chip that is used on the BEE2 requires special formatting options to properly read the files on the FAT16 partition. Once you have acquired a CF card you need to format it using the following command (assuming you are in Linux): 

mkdosfs -s 2 -F 16 -R 1 /dev/sda1  (16MB CF)
mkdosfs -s 8 -F 16 -R 1 /dev/sda1  (128MB CF)
mkdosfs -s 16 -F 16 -R 1 /dev/sda1 (256MB/512MB CF)
mkdosfs -s 64 -F 16 -R 1 /dev/sda1 (1GB CF)

We have tested all of these parameters on CFs at Berkeley, however they may not be right for your particular CF. More information can be found in the XUP documentation (search for "mkdosfs"). You can also download "mkdosfs" for Windows which should be run with the same options (the only difference is "/dev/sda1" would be replaced with "DRV:/" where DRV is the driver letter of the CF).

Copying the Files

The next step is to copy all of the files in "test_suite.zip" onto the CF. The zip contains the following files:

To perform the copy in Windows simply drag and drop the files from the zip to the CF. In Linux you need to unzip the file, mount the CF, and then copy the files: 

unzip test_suite.zip 

mount /dev/sda1 /mount/path

cp test_suite/* /mount/path

umount /mount/path

Make sure you properly unmount the CF in both Windows and Linux otherwise you may lose some of the files. Once you've copied all the files over, your copy of the test suite is ready to go.

Using Self-Test Suite

Detailed instructions on the use of the self-test suite can be found in BIST_procedure.pdf. Here is a quick highlight of important facts.

Setting up for the test

Connect to the board with a RS232 serial cable and setup your terminal emulation program to run the serial port with "8N1, 115200, No flow control". You should also connect a monitor to the DVI connector via an HDMI cable (see Bee2Setup), as some of the tests require more compicated output.

Getting help

At any time you can type help to see a list of commands at your disposal. In addition, tab completion works for the names of commands. Finally, to get information on the parameters a command takes, first type the name of the command and then type ? to get a printout of the parameters.

Complete testing

The testall command will run though all of the tests to verify the functionality of your board. This test requires you to connect some cables before hand, including a loopback on the Ethernet jack and all of the Infiniband connectors. The detailed instructions describe this in more detail.

Testing the memory DIMMs

Before running memory tests, all memory banks should be reset using ddroff followed by ddron.

Testing the XAUI links

Start the XAUI tester using the xauistart command. Each FPGA's XAUI links can be turned on using:

xauireset <refclock> <loopback> <mask>

The basic test for 10Gbps communications is:

xauireset 1 0 xff

which gives you a 156MHz reference clock, no loopback, and masks with 0xff.

Bee2TestSuite (last edited 2006-11-21 19:55:50 by hchen05)

BEE2wiki - BEE2wiki

BEE2 Documentation

To tighten up security on the wiki, you are now required to have your account added to a list of users who are allowed to modify content on the wiki. Please email the BEE2 maintainers with you account name in order to be granted access to modify the wiki.

For more information on the structure of the BEE2 documentation, please see the README file.

  1. BEE2 Documentation
    1. News Items
    2. BEE2 Board Support Package
    3. Walk-throughs and Guides
    4. Module Hardware Documentation
    5. Matlab/Simulink/Sysgen/EDK (MSSGE) Toolflow
    6. User Guide (Preliminary)

News Items

BEE2 Board Support Package

Getting Started

Feedback

Overviews

Developer Information

Walk-throughs and Guides

General Setup and Testing

Tools and Infrastructure

Linux

BORPH

Module Hardware Documentation

Matlab/Simulink/Sysgen/EDK (MSSGE) Toolflow

User Guide (Preliminary)

RAMP Core Selection Matrix RampCoreSelectionMatrix

BEE2wiki (last edited 2007-01-22 03:12:00 by alschult)

BorphGettingStart - BEE2wiki

Getting Started with BORPH

  1. Introduction
  2. Setup
  3. Creating Your Design
  4. Generting BOF Files from Your Design
  5. Running Your Design
  6. Conclusion

Introduction

In this tutorial, you will create a simple Simulink design using both standard Xilinx system generator blockset, as well as library blocks specific to BEE2. At the end of this tutorial, you will have a BORPH executable file, a BOF file, and you will know how to interact with your running hardware design using BORPH.

Setup

Before you start, you have to make sure you have set up your path variable in Matlab correctly. Make sure it includes <BEE_LIBRARY_PATH>/mlib/xps_library and <BEE_LIBRARY_PATH>/mlib/bee_library, where <BEE_LIBRARY_PATH> is the directory where you have installed your matlab library scripts downloaded for BEE2.

/!\ In our BWRC setup environment, note the following 3 things:

  1. Set <BEE_LIBRARY_PATH> to /tools/designs/BEE

  2. Most of the latest work are located in the mlib_devel directory instead of mlib

  3. You can have these path setup automatically if you start Matlab using the Windows batch file (Matlab7sp2.bat) from \\hitz\designs\BEE\mlib_devel

Once Matlab is started, you can start Simulink by typing simulink in the Matlab prompt. If your path is setup correctly, you should see among other libraries, the BEE2 System Blockset and Xilinx Blockset.

Creating Your Design

  1. Create a new model:

  2. Select Xilinx Blockset:

  3. Add 1 instance of Counter and 1 instance of System Generator

  4. Double-click on Counter

    1. Set Number of Bits to 32

    2. Check the box next to Provide Enable Port

    3. Select OK

    You should have a design that looks like this:

  5. It is a good time to save this new design. In this tutorial, we will call it "testborph".

  6. Now, select BEE2 System Blockset:

  7. Add 1 instace of XSG core config and 2 instances of software register

    Name the instance of sofware register on the left of Counter as cnt_en, while naming the other instance as cnt_val.

  8. Double-click on the software rigster named cnt_en and select I/O direction as From Processor.

    Note the field Data bitwidth is greyed out with a value 32. It is because all software registers have a fixed data bitwidth of 32 bits.

  9. Since we want to control the en port of Counter, which takes a Boolean input, we need a way to extract 1 bit out of this 32-bits software register. That's why we need to add one more block, a Slice from the Xilinx Blockset. Add an instance of Slice from the Xilinx Blockset to our design, connecting it between the cnt_en software register and the counter.

  10. Double-click on the newly added Slice block to set it's parameter:

  11. In order to generate a BOF file from this Simulink design using our MSSGE flow, we will need to add one final block: a XSG core cofing block from the BEE2 System Blockset. Furthermore, for sake of simulating your design withing Simulink, as well as to make our MSSGE flow to run correctly, you will need to connect up the sim_in/sim_out port of any software registers. (If you don't intend to simulate your design in Simulink, simply connect a constant block to the input of any software register.) You now have a design that looks like this:

  12. Save your work, you now have a fully functional design there is ready to be run on BEE2.

Generting BOF Files from Your Design

To generate a BOF file from your design, you must first specify the target platform and the synthesis tool to be used.

  1. Double-click the XSG core config block. For a design to be run on a user FPGA on BEE2, select BEE2_usr. Selecting XST for synthesis tool is sufficient for most designs.

  2. Once that's done, click OK and save your work.

  3. Now, go to the Matlab prompt, and type bee_xps: 

    matlab>> bee_xps

  4. You should see a new window pops up like this:

  5. Make sure the name showing on the top of this new window corresponds to the design you want to generate your BOF file. (If it is not, click anywhere on your design such that it is the highlighted window, then click gcs.)

  6. Finally, click Run XPS

Once the MSSGE script has finished, it should have created a subdirectory with your design name in the directory where you save your design. For example, if our design is saved in a directory FOO, then if you list the content of the directory, you will see: 

user@local$ ls -lF FOO
drwxrwxrwx  7 user grp  4096 May 15 12:12 testborph/
-rwxrwxrwx  1 user grp 36370 May 15 13:21 testborph.mdl

Inside the directory testborph is a directory called bit_files, which contains 1 .bit file and 5 BOF files. For this tutorial, focus only on the one with name <design_name>_floating_<date_time>.bof. This "floating" BOF file is what we will use now. Feel free to rename it to a shorter name if you want.

Running Your Design

Running your design is as simple as running a compiled software program from a compiler: All you need is to execute the floating BOF file within BORPH as if it is any other executable file in the system such as firefox.

The exact way of transfering a BOF file to a BEE2 system depends on your system setup.

/!\ For BWRC setup, the easiest way is to copy BOF files into BEE2 systems by using scp from wright.eecs.berkeley.edu: 

user@wright$ scp testborph.bof user@beeopen:

In any case, once you have copied your BOF files, log on to your BEE2, and execute your BOF file like this (using beeopen as an example): 

user@wright$ ssh user@beeopen

user@beeopen$ ls
testborph.bof
user@beeopen$ ./testborph.bof

Congratulations! You have just launched a hardware process in BORPH. If you have access to the physical BEE2 platform, you should see one of the user FPGA get configured automatically as a result of the BOF file execution. You can also see if your Simulink hardware is running by the command ps: 

user@beeopen$ ps
  PID TTY          TIME CMD
26427 pts/6    00:00:00 bash
26488 pts/6    00:00:00 testborph.bof
26525 pts/6    00:00:00 ps

Once your hardware process is running, you can interact with it through the ioreg interface of BORPH. Without going into the detail, assume your hardware process is runnign with process ID (PID) of 26488 as shown above, issue the following commands: 

user@beeopen$ cd /proc/26488/hw
user@beeopen$ ls
ioreg  ioreg_mode  region
user@beeopen$ echo 0 > ioreg_mode

By default, the values are accessed as binary values, and ioreg_mode is set to 1. By setting ioreg_mode to 0, hexadecimal I/O values will be used. Then, the following commands can be issued: 

user@beeopen$ cd ioreg
user@beeopen$ ls
cnt_en cnt_val
user@beeopen$

You see, the two "software registers" you put in your design now shows up automatically on Linux side. You can check the current value of by: 

user@beeopen$ cat cnt_val
00AC1000
user@beeopen$ cat cnt_val
00BD2590
user@beeopen$

According to our Simulink design, we can disable or enable the counter by setting cnt_en to 0 or 1 respectively: 

user@beeopen$ echo 0 > cnt_en
user@beeopen$ cat cnt_val
0C1F8346
user@beeopen$ cat cnt_val
0C1F8346
user@beeopen$ echo 1 > cnt_en
user@beeopen$ cat cnt_val
20BF0A99
user@beeopen$ cat cnt_val
3AB012F0
user@beeopen$

Conclusion

In this tutorial, you have leaned how to create an executable BOF file from Simulink. You have also learned the basic of running a hardware design in BORPH and interating with it using BORPH's ioreg interface.

To learn more about BORPH and how to use a on-chip memory on user FPGA has a shared memory betwen software and hardware, please see another tutorial, BorphUsingIoreg.

BorphGettingStart (last edited 2006-11-13 23:15:31 by hchen05)

BorphTutorials - BEE2wiki

http://bee2.eecs.berkeley.edu/img/BEE2_logo_mini.png

BORPH

Tutorials

Created: 2006-07-14

  1. Introduction
  2. Tutorials

Introduction

This page contains links to tutorials about BORPH. For now, all of them center around our Simulink based design flow. More tutorial on how to design for BORPH using plain HDL will be online soon.

Tutorials

BorphTutorials (last edited 2006-07-14 06:44:57 by HaydenSo)

embedded - BEE2wiki

Embedded RAMP Workshop (8/23/06)

10:00-10:15

Introductions

10:15-11:00

Wawrzynek, Asanovic (UCB)

RAMP Vision and Infrastructure (PPT)(PPT)

11:00-11:30

Uli Ramacher (Infineon)

Mass Market Applications Driving MPSoC and Design Challenges (PDF)

11:30-12:00

Ulrich Rueckert (HNI, Paderborn University)

High-level Description of Instructions Sets and Compiler Generation (PDF)

12:00-12:30

Wolfgang Raabs (Infineon)

Virtual Prototype and Design Flow (PDF)

12:30-1:30

Lunch

1:30-2:00

Kurt Keutzer (UCB)

Mapping task graphs to processors in large multiprocessor systems (PPT)

2:00-2:30

Chen Chang (BEECube)

Hardware and Tools for Architecture Exploration

2:30-3:30

Free Discussion

embedded (last edited 2006-08-30 17:30:26 by BrianRichards)

FindPage - BEE2wiki

You can use this page to search all entries in this WikiWikiWeb. Searches are not case sensitive.

Good starting points to explore a wiki are:

Here's a title search. Try something like help:

Here's a full-text search.

You can also use regular expressions and other search modifiers (see HelpOnSearching), an example:

    regex:seriali[sz]e

Or go direct to a page, or create a new page by entering its name here:

FindPage (last modified 2006-04-06 18:05:05)

HelpContents - BEE2wiki

Here is a tour of the most important help pages:

(!) If you like something for a presentation, look at WikiCourse.

These pages contain information only important to wiki administrators and developers:

If you don't find what you're looking for in the above, try these:

If you find any errors on the help pages, describe them on HelpErrata.

[Please do not edit or create help pages in other wikis than MoinMaster (see HelpContents), because the pages from MoinMaster will overwrite any other changes on wiki engine upgrades. Please follow the established structure of help pages if you want to change pages in MoinMaster. Before doing any major or widespread changes please discuss that on the mailing list or MoinMoin wiki.]

HelpContents (last modified 2006-04-06 18:05:05)

HelpOnFormatting - BEE2wiki

General

Typeface

Name/Sample

Markup

Notes

italic

''italic''

Double single quotes.

bold

'''bold'''

Triple single quotes.

monospace

`monospace`

Single backticks. Wiki markup is ignored.

code

{{{code}}}

Example. Wiki markup is ignored.

underline

__underline__

superscript

^superscript^

subscript

,,subscript,,

smaller

~-smaller-~

larger

~+larger+~

stroke

--(stroke)--

MoinMoin Version 1.5+

Colorized Code

There are several ways to display colorized code formatting:

  1. Start a special code block containing the parser's name: {{{#!parsername

  2. Embed a file attachment bearing a supported extension (such as ".py") with inline:

  3. Begin a page with the format processing instruction: #format parsername

Example.

To see the list of supported languages see HelpOnParsers.

Examples

Mixing ''italic'' and '''bold'''

Markup

Result

'''''Mix''' at the beginning''

Mix at the beginning

'''''Mix'' at the beginning'''

Mix at the beginning

'''Mix at the ''end'''''

Mix at the end

''Mix at the '''end'''''

Mix at the end

Code

{{{
10 PRINT "Hello, world!"
20 GOTO 10
}}}

Result: 

10 PRINT "Hello, world!"
20 GOTO 10

Superscript & Subscript

You might recall ''a''^2^ + ''b''^2^ = ''c''^2^ from your math lessons, unless your head is filled with H,,2,,O.

Result:

You might recall a2 + b2 = c2 from your math lessons, unless your head is filled with H2O.

Colorized Code, Method #1

{{{#!python
from colors import palette
palette.colorize('python')
}}}

Result: 

   1 from colors import palette
   2 palette.colorize('python')

HelpOnFormatting (last modified 2006-04-06 18:05:05)

HelpOnSearching - BEE2wiki

Queries

With the MoinMoin search engine the same search patterns are allowed in the search and title search input fields as in the parameters for the FullSearch and the PageList macros.

Examples

title:Help macro

searches for help pages that contain the word "macro". 

apple (computer or "operating system")

searches for pages containing the word "apple" and at least one of "computer" or "operating system". 

windows winamp or linux xmms

searches for pages containing both "windows" and "winamp", and also for pages containing both "linux" and "xmms". 

"is text"

Will match "this text" or "is texts". Quotes are used only to include whitespace, and do not mean "exactly this phrase". 

linkto:WindowsPage title:Linux

searches for pages that have "Linux" in the page name and that link to WindowsPage

r:\bdog\b

searches for the word "dog" and does not find e.g. the word "doggy"

TitleSearch and PageList

HelpOnSearching (last modified 2006-04-06 18:05:05)

IbobFaq - BEE2wiki

IBOB Board FAQ

  1. IBOB Board FAQ
    1. Links
    2. Frequently Asked Questions
      1. What is naming nomenclature of ADC ports ?
      2. Can the CX4 connector at the non-iBOB end of a CX4 link have chassis ground connected to digital ground ?
      3. What is the acceptable reference frequency range for the non-iBOB end of a CX4 link? Is it 156.25 MHz +/- 0.01%? Can the link run with one end using 156.24 MHz ?
      4. I'm using Pierre's XAUI_interface_v1_00 pcore. What do I need to know about the clock frequencies and data rates of the inputs and outputs ?
      5. How full is the fifo when rx_almost_full goes active ?
      6. How big is the fifo ?
      7. If I have the same app_clk on both ends and it's substantially less than 156.25 MHz, can I tie rx_get and tx_valid to '1' and ignore (i.e. leave open) rx_almost_full, rx_valid, rx_empty, and tx_full? Would this effectively give the appearance of a fully synchronous connection with some unknown (but measurable) latency ?
      8. If I use the xaui_if.ngc file from mlib_devel, will I have to synthesize/map/par/bitgen on beehive ?
      9. Why does this pcore's transceiver.vhd file have "-- synthesis translate_off" and "-- synthesis translate_on" around the gt_xaui_2's generic map? Did Core Generator create it that way ?
      10. How do I program the PROM on the IBOB for automatic startup?

Links

Other useful FAQs:

Frequently Asked Questions

What is naming nomenclature of ADC ports ?

The ADC closer to the iBOB power connector (J23 on iBOB) is named adc1 and the one further away (J22 on iBOB) is adc0.

Can the CX4 connector at the non-iBOB end of a CX4 link have chassis ground connected to digital ground ?

This does not present any problem, as the chassis ground on the iBOB CX4 connector is left floating. However, make sure you use the digital ground and not a filtered ground, such as an analog ground or the MGTs ground, because the cable is going to act as an antenna and inject a lot of noise in this ground plane.

What is the acceptable reference frequency range for the non-iBOB end of a CX4 link? Is it 156.25 MHz +/- 0.01%? Can the link run with one end using 156.24 MHz ?

The V2P datasheet states +- 100ppm mismatch (or +-0.01%), and the crystal on the iBOB is +-50ppm. It leaves 50ppm margin, and 156.24 is at 60ppm. So theorically it doesn't work, but practically I think it could do. It's worth trying ...

I'm using Pierre's XAUI_interface_v1_00 pcore. What do I need to know about the clock frequencies and data rates of the inputs and outputs ?

How full is the fifo when rx_almost_full goes active ?

How big is the fifo ?

If I have the same app_clk on both ends and it's substantially less than 156.25 MHz, can I tie rx_get and tx_valid to '1' and ignore (i.e. leave open) rx_almost_full, rx_valid, rx_empty, and tx_full? Would this effectively give the appearance of a fully synchronous connection with some unknown (but measurable) latency ?

If I use the xaui_if.ngc file from mlib_devel, will I have to synthesize/map/par/bitgen on beehive ?

Why does this pcore's transceiver.vhd file have "-- synthesis translate_off" and "-- synthesis translate_on" around the gt_xaui_2's generic map? Did Core Generator create it that way ?

How do I program the PROM on the IBOB for automatic startup?

IbobFaq (last edited 2007-01-02 22:05:23 by BrianRichards)

MoinMoin - BEE2wiki

MoinMoin is a Python WikiClone, based on PikiPiki. The name is a common German slang expression (see MoinMoinEtymology for more about that). If you run a Wiki using MoinMoin, please add it to the MoinMoinWikis page. Contributed code is on the MacroMarket, ActionMarket and ParserMarket pages.

The following pages are about the development of MoinMoin:

These pages provide information about using and installing MoinMoin:

Other pages about MoinMoin:

External links:

Connect to IRC for meeting the author and other MoinMoin users and developers:

opensource-110x95
Open Source

MoinMoin (last modified 2006-04-06 18:05:05)

MssgeFaq - BEE2wiki

MSSGE Toolflow FAQ

Links

Other useful FAQs:

Frequently Asked Questions

What does MSSGE mean ?

MSSGE stands for Matlab/Simulink/System Generator/EDK toolflow.

What do I need to use the MSSGE flow ?

Software

As suggested by its name, the MSSGE flow requires Matlab, Simulink, System Generator, and EDK. The following versions are currently supported:

Optional but recommended:

Only the listed versions of the software are supported. Others may work but your results may vary.

Licenses

Some of the functionality supported by the toolflow require licensed cores from Xilinx. Currently, they include:

BWRC users should use the following servers if any of the above cores are needed:

How do I access the MSSGE libraries ?

If you are a user within BWRC, start Matlab using the Matlab7sp2.bat script located in \\hitz\designs\BEE\mlib and all of the system and design libraries will be available to you in Simulink.

If you are an external user, you must first download all the libraries and base systems. They are available on a CVS repository via anonymous access. The CVS root is located at :pserver:anonymous:@alien.ssl.berkeley.edu:2402/home/cvs/casper_cvsroot. For example, to checkout module xps_library from the repository, you would use:

cvs -d :pserver:anonymous:@alien.ssl.berkeley.edu:2402/home/cvs/casper_cvsroot checkout xps_library

Doing a plain checkout or update will get you the latest development versions of the source. To get the latest stable versions, get the tagged versions using cvs checkout -r <tag> or cvs update -r <tag>.

The current modules available are:

Note that to use some of the library blocks you may need to get additional blocksets for Simulink. Currently, to use the ADC interface block, you will need to get the Signal Processing Blockset and to simulate designs you will need the Fixed-Point Toolbox.

All libraries are released under the GNU General Public License

Setting up the toolflow environment

Once the libraries are downloaded, you will need to add the astro_library, bee_library, and xps_library directories to your Matlab path. This can be done using File -> Set Path if you have control over your Matlab installation.

If you do not have control over your Matlab installation, you can write a simple Matlab script using to add the libraries to your path automatically during startup using addpath. To do this, put your addpath commands into a file named startup.m. Create a Windows shortcut to %MATLABPATH%\win32\Matlab.exe and under the "Shortcut" tab of the shortcut's properties set the "Start in" field to the directory where you have your startup.m file.

The following Windows environment variables need to be set:

Lastly, the location of astro_library must also be added to the Windows path.

How do I add software to the PowerPC

The first time bee_xps is run on a Simulink design, a .\design_name\src directory will be created for you to put your source files in. The software platform runs on a full PowerPC 405 hard core compiled with gcc, so any kind of standard C code and libraries will work. The core lacks a floating-point unit, however, but has floating-point emulation.

The toolflow acts on your source code based on comment lines immediately following the function definition header and before the opening brace. For example: 

void function_name ()
/* toolflow directives */
{
    function body
          .
          .
          .
}

To make the function a command accessible from the TinySH command prompt use: 

void function_name (int argc, char **argv)
/* command = "command_name"                                              */
/* help    = "command description displayed with '?'"                    */
/* params  = "<list> <of> <arguments> <to> <be> <passed> <to> <command>" */
{
    .
    .
    .
}

To have the function called at power-up initialization use: 

/* init */

To have the function loop continuously use: 

/* repeat */

Where do I locate the Matlab script to retrieve data from/send data to the serial port ?

There are two functions, called write_xps and read_xps in the xps_library directory, they are what you want. They are in the path, so you can use them directly.

syntax:

write_xps(<data>, <exact block name as it appears in simulink>, <com port>); 
read_xps(<exact block name as it appears in simulink>, <com port>);

for example:
write_xps(uint32(3), 'my register', 'COM1'); will write 3 to "my register" read_xps('my register', 'COM1'); will read from "my register"

data has to be a uint32 array with the correct length (you can use the uint32 function to convert an array of double to this format). Your design has to be the current system (the last simulink design that had the focus).

What does the following error suggest ?

''ERROR:MDT - :MapLib:661 - LUT2 symbol 
   "opb_adcinterface_0/opb_adcinterface_0/USER_LOGIC_I/adcreset_sig1" (output 
   signal=opb_adcinterface_0/opb_adcinterface_0/USER_LOGIC_I/adcreset_sig) 
   has input signal "opb_adcinterface_0_adc_usr_ddr_rst" which will be trimmed. 
 
See the trim report for details about why the input signal will become undriven. 

Error found in mapping process, exiting... 
Errors found during the mapping phase.''

This error happens if you put Xilinx input gateways in your design. Only XPS GPIO blocks should be used as inputs to guarantee that the boundary between the Xilinx part of the design (synthesized part) and the simulation part is clean. The version 1 of the toolflow enforces this constraint and gives you an error in the early stage of the compilation. Output gateways can be used.

Why do I get the following error when the base system is extracted from the zip file ?

Warning: Directory Y:\BEE\temp\test\XPS_iBOB_base\system.mhs could not be removed.
Warning: Directory Y:\BEE\temp\test\XPS_iBOB_base\system.mhs.bac could not be removed.
Warning: Directory Y:\BEE\temp\test\XPS_iBOB_base could not be removed.
replace XPS_iBOB_base/system.mhs? [y]es, [n]o, [A]ll, [N]one, [r]ename:

Matlab has the bad habit of not closing files properly when a script crashes. Unfortunately, once Matlab has locked the file, the only way to unlock it is to restart Matlab. You should restart Matlab when this error occurs. In addition to that, the unzip program used to unzip the base system can keep running in the background, even if Matlab was closed. This process, called "unzip.exe" should be manually killed when this happens.

Where do I find the mapping of IP base addresses accessible from the PowerPC ?

The IP address mappings visible to the PowerPC can be found in the xparameters.h file located, from the directory where your Simulink model is, in project_name\XPS_iBOB_base\ppc405_0\include.

The new revision of the toolflow, released December 8, 2005, also builds it directly into the software compiled for the PowerPC. Using the listdev command at the TinySH prompt will give all of the PPC-accessible blocks, listed by their Simulink design name, and PPC memory address.

Why does System Generator crash with a "no match" error ?

This has not been seen since the ver_2_1_0 release of astro_library, and is considered fixed. If you encounter it while using that or newer versions of the library, please e-mail the bee2-mssge list and let us know.

This is one of the secret mysteries of Simulink/SysGen, but there is a temporary workaround that seems to be successful. There is presumably a setting somewhere within one of the blocks in the signal processing libraries that Simulink and System Generator can't agree on. If your XSG generation fails with a no match statement, and projectname\sysgen\sysgen.log complains about an output block having no driver, then this fix might work.

Simply delete the offending block and drag in a new one from the library. DO NOT do a CTRL-D or use the "Update System" option from bee_xps. If you find that you need to update the design, delete the block and put it back in again right before you try to compile. So far the fft block is known to need this workaround.

MssgeFaq (last edited 2006-09-28 21:32:47 by hchen05)

MssgeTodo - BEE2wiki

MssgeTodo (last edited 2006-04-07 07:11:40 by alschult)

OrphanedPages - BEE2wiki

A list of pages no other page links to:

  1. BEE2wiki
  2. BEE3
  3. BEE3/BEE3Group
  4. Bee2CorrPhotos
  5. RampWorkshopJan2006
  6. Temp
  7. XilinxUpload

OrphanedPages (last modified 2006-04-06 18:05:05)

PageHits - BEE2wiki

This page shows how often a page was requested since the beginning of logging. It has no intelligence, every view counts as hit.

  1.   6322 BEE2wiki
  2.   1192 Bee2DebianRootFs
  3.   1096 Bee2Binaries
  4.    968 Bee2Setup
  5.    894 RampCoreSelectionMatrix
  6.    824 MssgeFaq
  7.    750 Bee2QuickStart
  8.    663 embedded
  9.    612 Bee2OperatingSystem
  10.    605 Bee2Memory
  11.    588 Bee2Reference
  12.    563 Bee2TestSuite
  13.    508 Bee2LinuxKernel
  14.    507 RecentChanges
  15.    475 Bee2LinuxConfig
  16.    391 MoinMoin/InstallDocs
  17.    389 Bee2Cvs
  18.    376 RampWorkshopJan2007
  19.    370 Bee2Cores
  20.    315 BorphGettingStart
  21.    294 Bee2Faq
  22.    284 BorphTutorials
  23.    268 IbobFaq
  24.    260 FindPage
  25.    235 HelpContents
  26.    228 UserPreferences
  27.    226 Bee2Errata
  28.    210 Bee2DebianRootNfs
  29.    207 BcFaq
  30.    186 Bee2TclRewrite
  31.    175 AdcFaq
  32.    159 Bee2Readme
  33.    145 SystemPagesGroup
  34.    137 Bee2CoreOpbSelectMapV101a
  35.    131 Bee2Pins
  36.    114 WhyWikiWorks
  37.    111 MssgeTodo
  38.    106 Bee2Feedback
  39.     73 TitleIndex
  40.     65 WordIndex
  41.     59 HelpOnFormatting
  42.     49 BEE3
  43.     48 HelpOnLinking
  44.     48 Bee2CoreTemplate
  45.     43 PageSize
  46.     41 SyntaxReference
  47.     41 PageHits
  48.     41 HelpForBeginners
  49.     40 HelpOnMacros
  50.     37 HelpMiscellaneous/FrequentlyAskedQuestions
  51.     36 HelpOnParsers
  52.     36 HelpOnAdministration
  53.     35 HelpOnAccessControlLists
  54.     33 WikiName
  55.     33 WantedPages
  56.     33 HelpOnAutoAdmin
  57.     32 HelpOnTemplates
  58.     31 Temp
  59.     31 HelpOnEditing
  60.     30 SiteNavigation
  61.     30 HelpOnActions
  62.     30 Bee2CorrPhotos
  63.     29 HelpOnPageCreation
  64.     29 HelpOnLanguages
  65.     29 CategoryTemplate
  66.     28 WikiSandBox
  67.     28 SlideShowTemplate
  68.     28 RampWorkshopJan2006
  69.     28 MoinMoin/TextFormatting
  70.     28 HelpOnInstalling/ApacheWithModPython
  71.     27 MoinMoin
  72.     27 HelpOnInstalling/FastCgi
  73.     27 HelpMiscellaneous
  74.     26 XilinxUpload
  75.     26 SystemPagesInEnglishGroup
  76.     26 HelpOnThemes
  77.     26 HelpOnNavigation
  78.     26 AutoAdminGroup
  79.     25 WikiWikiWeb
  80.     25 HelpOnVariables
  81.     25 HelpOnProcessors
  82.     25 HelpOnPackageInstaller
  83.     24 WikiCourse
  84.     24 LocalSpellingWords
  85.     24 HelpOnInstalling/TroubleShooting
  86.     24 HelpOnInstalling/ApacheOnMacOsx
  87.     24 HelpOnConfiguration/ApacheVoodoo
  88.     24 HelpIndex
  89.     23 SystemInfo
  90.     23 HelpOnXmlPages
  91.     23 HelpOnTables
  92.     23 HelpOnInstalling/InternetInformationServer
  93.     23 HelpOnHeadlines
  94.     23 HelpForDevelopers
  95.     23 FrontPage
  96.     22 HelpOnRules
  97.     22 HelpOnParsers/ReStructuredText
  98.     22 HelpOnInstalling
  99.     22 BEE3/BEE3Group
  100.     21 OrphanedPages
  101.     21 CategoryHomepage
  102.     20 RandomPage
  103.     20 HelpOnSpellCheck
  104.     20 HelpOnSearching
  105.     20 HelpOnProcessingInstructions
  106.     20 HelpOnInstalling/WebLogic
  107.     20 HelpOnAuthentication
  108.     20 CategoryCategory
  109.     19 HelpOnSmileys
  110.     19 HelpOnSlideShows
  111.     19 HelpOnSkins
  112.     19 HelpOnLists
  113.     19 HelpOnInstalling/BasicInstallation
  114.     19 HelpOnConfiguration
  115.     19 HelpOnCategories
  116.     19 HelpMiscellaneous/ExperimentalFeatures
  117.     18 WikiCourse/BasicIntroduction/210 Organisation and Structure
  118.     18 HelpOnUpdatingPython
  119.     18 HelpOnUpdating
  120.     18 HelpOnSlideShows/000 Introduction
  121.     18 HelpOnParsers/ReStructuredText/RstPrimer
  122.     18 HelpOnInstalling/WikiInstanceCreation
  123.     18 HelpOnInstalling/ApacheOnWin32
  124.     18 HelpOnInstalling/ApacheOnLinux
  125.     18 HelpOnEditing/SubPages
  126.     18 HelpOnConfiguration/IntegratingWithApache
  127.     18 HelpOnConfiguration/FileAttachments
  128.     18 AbandonedPages
  129.     17 HelpTemplate
  130.     17 HelpOnSlideShows/100 Creating the slides
  131.     17 HelpOnMacros/Include
  132.     17 HelpOnInstalling/TwistedWeb
  133.     17 HelpOnInstalling/StandaloneServer
  134.     17 HelpOnInstalling/ApacheOnLinuxFtp
  135.     17 HelpOnConfiguration/SurgeProtection
  136.     17 HelpOnActions/AttachFile
  137.     16 HelpOnInstalling/AolServer
  138.     16 HelpOnConfiguration/SecurityPolicy
  139.     16 HelpOnConfiguration/CascadingStyleSheets
  140.     15 InterWiki
  141.     14 WikiCourse/BasicIntroduction/050 First Steps
  142.     14 FortuneCookies
  143.     13 WikiCourse/BasicIntroduction/900 Exercises
  144.     13 WikiCourse/BasicIntroduction/180 Macros
  145.     13 WikiCourse/BasicIntroduction/130 Lists
  146.     13 WikiCourse/BasicIntroduction/100 Text markup
  147.     13 HelpOnSlideShows/900 Last but not least: Running your presentation.
  148.     13 EventStats/HitCounts
  149.     12 WikiHomePage
  150.     12 WikiCourse/BasicIntroductionHandOut
  151.     12 WikiCourse/BasicIntroduction/150 Tables
  152.     12 WikiCourse/BasicIntroduction/060 How do I navigate?
  153.     12 SystemPagesSetup
  154.     12 MissingHomePage
  155.     12 HomepageTemplate
  156.     12 HelpOnUserPreferences
  157.     12 BadContent
  158.     11 XsltVersion
  159.     11 WikiCourse/BasicIntroduction/200 Wikiquette
  160.     11 WikiCourse/BasicIntroduction/195 Actions
  161.     11 WikiCourse/BasicIntroduction/191 Creating new Pages
  162.     11 WikiCourse/BasicIntroduction/110 Headlines and Paragraphs
  163.     11 WikiCourse/BasicIntroduction
  164.     11 MissingPage
  165.     11 EventStats
  166.     11 DesktopEdition/HowToConfigure
  167.     10 WikiCourse/BasicIntroduction/000 What is a Wiki?
  168.     10 SlideTemplate
  169.     10 SlideShowHandOutTemplate
  170.     10 LocalBadContent
  171.      8 HelpOnPageDeletion
  172.      8 HelpOnGraphicalEditor
  173.      8 HelpOnEditLocks
  174.      7 HelpOnConfiguration/EmailSupport
  175.      6 EventStats/UserAgents
  176.      6 EditedSystemPages
  177.      6 DesktopEdition
  178.      5 WikiCourse/BasicIntroduction/091 Tips on the Editor
  179.      5 WikiCourse/BasicIntroduction/090 The Editor
  180.      5 MoinPagesEditorGroup
  181.      5 HelpOnMacros/MailTo

PageHits (last modified 2006-04-06 18:05:05)

PageSize - BEE2wiki
Charts are not available!

List of all pages, sorted by their size:

  1.  49585 BadContent
  2.  28072 WhyWikiWorks
  3.  23656 Bee2OperatingSystem
  4.  22448 HelpOnConfiguration
  5.  16928 Bee2CoreOpbSelectMapV101a
  6.  15997 HelpOnInstalling/ApacheOnLinux
  7.  15088 HelpOnAccessControlLists
  8.  13954 Bee2TclRewrite
  9.  13837 HelpOnUpdating
  10.  13772 Bee2Memory
  11.  13301 HelpMiscellaneous/FrequentlyAskedQuestions
  12.  13122 HelpOnInstalling/ApacheOnLinuxFtp
  13.  12944 HelpOnInstalling/ApacheOnWin32
  14.  12352 Bee2Setup
  15.  11520 HelpOnParsers/ReStructuredText/RstPrimer
  16.  11374 HelpOnInstalling/InternetInformationServer
  17.  11151 HelpOnMacros
  18.   9764 MssgeFaq
  19.   9720 HelpOnInstalling/BasicInstallation
  20.   9541 HelpOnInstalling/ApacheWithModPython
  21.   9431 Bee2QuickStart
  22.   8980 HelpOnInstalling/WikiInstanceCreation
  23.   8679 BorphGettingStart
  24.   7813 HelpOnAuthentication
  25.   7790 Bee2DebianRootFs
  26.   7308 HelpMiscellaneous
  27.   7127 HelpOnInstalling/FastCgi
  28.   7002 HelpOnParsers/ReStructuredText
  29.   6975 Bee2LinuxKernel
  30.   6705 HelpOnLanguages
  31.   6692 HelpOnTables
  32.   6587 HelpOnActions/AttachFile
  33.   6156 Bee2LinuxConfig
  34.   6019 LocalSpellingWords
  35.   5899 SyntaxReference
  36.   5888 Bee2Reference
  37.   5879 HelpOnParsers
  38.   5689 Bee2Errata
  39.   5576 HelpOnInstalling/TroubleShooting
  40.   5569 HelpOnLinking
  41.   5472 Bee2Binaries
  42.   5372 RampWorkshopJan2007
  43.   5267 HelpOnUserPreferences
  44.   5254 HelpOnConfiguration/FileAttachments
  45.   5130 HelpOnInstalling/StandaloneServer
  46.   5098 HelpOnInstalling/ApacheOnMacOsx
  47.   4943 HelpOnInstalling
  48.   4873 MoinMoin/InstallDocs
  49.   4838 HelpOnPackageInstaller
  50.   4716 HelpOnThemes
  51.   4689 HelpOnConfiguration/IntegratingWithApache
  52.   4563 SystemPagesInEnglishGroup
  53.   4520 HelpOnActions
  54.   4369 HelpOnNavigation
  55.   4282 Bee2TestSuite
  56.   4226 BcFaq
  57.   4111 HelpOnEditLocks
  58.   4084 HelpOnProcessingInstructions
  59.   3906 HelpOnXmlPages
  60.   3818 HelpOnMacros/MailTo
  61.   3684 Bee2Cvs
  62.   3505 HelpOnAutoAdmin
  63.   3499 Bee2CoreTemplate
  64.   3491 Bee2Readme
  65.   3456 HelpOnInstalling/TwistedWeb
  66.   3378 IbobFaq
  67.   3333 HelpOnFormatting
  68.   3314 HelpOnConfiguration/ApacheVoodoo
  69.   3253 HelpOnLists
  70.   3132 BEE2wiki
  71.   3053 HelpOnVariables
  72.   2983 MoinMoin
  73.   2953 HelpOnGraphicalEditor
  74.   2949 HelpOnMacros/Include
  75.   2864 HelpOnConfiguration/CascadingStyleSheets
  76.   2825 MoinMoin/TextFormatting
  77.   2619 HelpOnSpellCheck
  78.   2565 HelpOnConfiguration/EmailSupport
  79.   2558 HelpOnConfiguration/SurgeProtection
  80.   2504 HelpOnPageCreation
  81.   2466 HelpOnSearching
  82.   2423 DesktopEdition/HowToConfigure
  83.   2417 RampCoreSelectionMatrix
  84.   2297 HelpOnInstalling/WebLogic
  85.   2201 HelpForBeginners
  86.   2027 HelpOnEditing/SubPages
  87.   1973 HelpContents
  88.   1965 Bee2Pins
  89.   1846 WikiName
  90.   1841 UserPreferences
  91.   1758 HelpOnEditing
  92.   1682 Bee2Cores
  93.   1597 HelpOnSlideShows
  94.   1575 SystemPagesGroup
  95.   1536 HelpOnUpdatingPython
  96.   1524 HelpOnCategories
  97.   1467 HelpMiscellaneous/ExperimentalFeatures
  98.   1443 HelpOnPageDeletion
  99.   1428 HelpOnSkins
  100.   1424 WikiCourse/BasicIntroduction/100 Text markup
  101.   1342 InterWiki
  102.   1334 WikiSandBox
  103.   1311 FrontPage
  104.   1310 HelpOnHeadlines
  105.   1261 WikiCourse/BasicIntroductionHandOut
  106.   1227 WikiCourse/BasicIntroduction/000 What is a Wiki?
  107.   1220 WikiWikiWeb
  108.   1188 HelpOnConfiguration/SecurityPolicy
  109.   1137 WikiCourse/BasicIntroduction/110 Headlines and Paragraphs
  110.   1135 HelpOnAdministration
  111.   1134 HelpOnInstalling/AolServer
  112.   1134 HelpOnTemplates
  113.   1134 MissingHomePage
  114.   1117 FortuneCookies
  115.   1111 FindPage
  116.   1093 Bee2DebianRootNfs
  117.   1090 WikiCourse/BasicIntroduction/200 Wikiquette
  118.   1055 HelpForDevelopers
  119.   1054 RecentChanges
  120.   1035 WikiCourse/BasicIntroduction/091 Tips on the Editor
  121.   1033 WikiCourse/BasicIntroduction/191 Creating new Pages
  122.   1032 CategoryCategory
  123.   1017 WikiCourse/BasicIntroduction/090 The Editor
  124.   1011 embedded
  125.    988 WikiCourse/BasicIntroduction/050 First Steps
  126.    964 WikiCourse/BasicIntroduction/060 How do I navigate?
  127.    918 HelpOnSlideShows/100 Creating the slides
  128.    913 WikiHomePage
  129.    911 SiteNavigation
  130.    906 HelpOnSlideShows/900 Last but not least: Running your presentation.
  131.    901 HelpOnRules
  132.    894 XsltVersion
  133.    859 WikiCourse/BasicIntroduction/180 Macros
  134.    825 WikiCourse/BasicIntroduction
  135.    807 HelpOnSlideShows/000 Introduction
  136.    803 WikiCourse/BasicIntroduction/195 Actions
  137.    788 WikiCourse/BasicIntroduction/210 Organisation and Structure
  138.    785 BorphTutorials
  139.    769 WikiCourse/BasicIntroduction/150 Tables
  140.    675 WikiCourse
  141.    672 WikiCourse/BasicIntroduction/900 Exercises
  142.    653 WikiCourse/BasicIntroduction/130 Lists
  143.    634 MissingPage
  144.    634 SystemPagesSetup
  145.    625 AdcFaq
  146.    593 SlideShowHandOutTemplate
  147.    548 HelpOnSmileys
  148.    538 DesktopEdition
  149.    512 Bee2Feedback
  150.    486 CategoryTemplate
  151.    479 TitleIndex
  152.    461 SlideShowTemplate
  153.    453 WordIndex
  154.    445 HelpOnProcessors
  155.    445 EditedSystemPages
  156.    443 CategoryHomepage
  157.    439 AutoAdminGroup
  158.    429 AbandonedPages
  159.    428 PageHits
  160.    401 HelpIndex
  161.    387 WantedPages
  162.    380 HelpTemplate
  163.    375 EventStats
  164.    371 MssgeTodo
  165.    366 PageSize
  166.    357 RandomPage
  167.    343 OrphanedPages
  168.    323 SlideTemplate
  169.    320 Bee2Faq
  170.    310 EventStats/UserAgents
  171.    309 EventStats/HitCounts
  172.    298 SystemInfo
  173.    150 HomepageTemplate
  174.    136 Bee2CorrPhotos
  175.    102 BEE3/BEE3Group
  176.     72 XilinxUpload
  177.     52 BEE3
  178.     50 MoinPagesEditorGroup
  179.     29 LocalBadContent
  180.     23 RampWorkshopJan2006
  181.     21 Temp

PageSize (last modified 2006-04-06 18:05:05)

RampCoreSelectionMatrix - BEE2wiki

IBM

Freescale

Leon3

OpenSPARC T1 (Niagara)

ProtoFlex

Simply RISC S1

QEMU/FAST functional

MicroBlaze (v5.0)

ISA

PPC405

PPC

SPARC V8

UltraSPARC Arch 2005 (SPARC V9+)

SPARC V9

UltraSPARC Arch 2005 (SPARC V9+)

x86

MIPS-like RISC (w/o MMU)

FPU

no

no (available)

Yes (no source code)

Yes

not yet

Yes

software

partial IEEE 754 single precision

microarchitecture

5-stage, in-order, single-issue

7-stage, in-order?

7-stage, in-order pipeline

8-core, 32-thread, 6-stage pipe (1 core/1 thread in initial FPGA version)

ISA only

1-core, 4-thread derivative of OpenSPARC T1

ISA

3-stage in-order

licensing

restricted

yes

LGPL

GPL

SIMICS

GPL

LGPL

Xilinx EDK

speed

30MHz

25MHz

50MHz (0.85 MIPS/MHz)

25 MHz (Virtex-II)

<10MIPS

_?_

5MIPS

>100 MHz (0.5 MIPS/MHz)

size, in 4-input LUTs (w/o FPU)

20K

33.5K

8K

135K (full 8-Core), 48K (1 thread/1 core, placed&routed)

13K (partial core)

_?_

PowerPC

2.8K

HDL

Verilog

Verilog

VHDL

Verilog

Bluespec

Verilog

Verilog

Encrypted VHDL

verification suite

no

no

yes

Niagara (OpenSPARC)

Niagara

Niagara (OpenSPARC)

no

no

application base

ok

ok

ok

ok

Solaris Apps

_?_

everything

poor

operating system(s)

ok

ok

Linux 2.6

Solaris, Linux, *BSD

Solaris

Solaris, Linux, *BSD

Windows, Linux, Solaris, ...

uClinux 2.4

hardcore

yes

yes

no

no

no

no

no

no

64 bit

no

no

no

yes, full 64-bit

yes

yes, full 64-bit

yes (speed)

no

SMP support

no

no

Snoopy (w/o MMU)

CMT

not yet

CMT

_?_

no

virtualizability

no

no

no

yes (Hypervisor, LDOMs)

no

yes? (via Hypervisor)

_?_

no

bus interface

64-bit PLB

64-bit AMBA AHB2.0v6

32-bit AMBA (64-bit soon)

128-bit

64-bit (virtualized)

Opencores wishbone

_?_

32-bit OPB/MCH

Leon3 report on Virtex-2 and Virtex-5 (section 1.3 and 1.4) - http://radlab.cs.berkeley.edu/wiki/LEON3_area

ProtoFlex-SPARC follows a hybrid execution model that splits execution between FPGA emulation (a subset of the functionality) and SIMICS software simulation.

RampCoreSelectionMatrix (last edited 2006-09-28 22:34:47 by DavidWeaver)

RampWorkshopJan2006 - BEE2wiki

[RampWorkshopJan2007]

RampWorkshopJan2006 (last edited 2007-01-10 23:49:57 by GregGibeling)

RampWorkshopJan2007 - BEE2wiki

RAMP Workshop

Wednesday, January 10

Presentation

Speaker

2:00pm

3:30pm

Informal Reception (for early comers)

3:30pm

5:00pm

First Session

Welcome to the Retreat (PPT)

John Wawrzynek, UC Berkeley

RAMP Vision and Overview (PPT)

Dave Patterson, UC Berkeley

RAMP Blue: A 256-core Message Passing Machine (PPT)

Andrew Schultz, UC Berkeley

5:00pm

5:30pm

Break

5:30pm

6:30pm

Second Session

RAMP White, A Distributed Shared-Memory Machine (PPT)

Derek Chiou, UT Austin

Break-Out Topics Introduced

James Hoe, CMU

6:30pm

8:00pm

Dinner/Tables Organized by breakout topics

8:00pm

9:00pm

After Dinner Talk: Reflections on 3 years of Open Source
Hardware Experience, and the Future of Leon (PDF)

Jiri Gaisler, Gaisler Research

Thursday, January 11

8:00am

9:00am

Breakfast

9:00am

10:30am

Third Session

RAMP Red: Programming and Performance Tuning (PPT)

Sewook Wee, Stanford

Brief Xilinx V5 XUP Update

Kees Vissers, Xilinx

High-level Design of the RAMP2 Hardware: BEE3 (PPT)

Chuck Thacker, Microsoft Research

10:30am

11:00am

Break

11:00am

12:15pm

Fourth Session

RAMP Description Language (RDL): Applications
and Debugging (PDF)

Greg Gibeling, UC Berkeley

C++ Smash (PPT)

Krste Asanovic, MIT

New Techniques for Time Dilation Emulation (PPT)

Zhangxi Tan, UC Berkeley

12:15pm

1:35pm

Lunch organized by breakout topics

1:35pm

3:00pm

Fifth Session

Reports from Breakouts (PPT)

Open SPARC on FPGAs (PPT)

Durgam Vahia, Sun Microsystems

3:00pm

3:30pm

Break

3:30pm

4:45pm

Sixth Session

Low-cost Silicon Production (PDF)

Martha Mercaldi, U Washington

A Shared Memory Microblaze (PPT)

Murali Vijayaraghavan, MIT

ProtoFlex Hybrid Simulation (PPT)

Eric Chung, CMU

4:45pm

6:30pm

Posters & Demos

5:30pm

6:30pm

(PI meeting)

6:30pm

8:00pm

Dinner

8:00pm

9:00pm

Open-mike/spontaneous great ideas

Friday, January 12

8:00am

9:00am

Breakfast

9:00am

10:30am

Seventh Session

A Disk Emulation Model for the Leon Processor (PPT)

Zhangxi Tan, UC Berkeley

An Efficient Architecture for Security Analysis (PPT)

Michael Dalton, Stanford

RAMPant-to-Visitor Summary (PPT)

10:30am

11:00am

Break

11:00am

12:30pm

Visitor Feedback Session (PDF) (PDF)

Liquid Architecture – Results of Optimization of the LEON (PPT)

John W Lockwood, Stanford

12:30pm

1:45pm

Box lunch, Informal discussion

1:45pm

3:00pm

(PI Meeting)

RampWorkshopJan2007 (last edited 2007-01-12 21:35:17 by GregGibeling)

RandomPage - BEE2wiki

A list of 25 random pages (out of 208 total):

RandomPage (last modified 2006-04-06 18:05:05)

RecentChanges - BEE2wiki

Hint: get email notification when this page changes, by clicking Subscribe.

[RSS]

2007-02-21
[DIFF] Bee2Setup 01:27 Info hchen05
2007-01-22
[DIFF] BEE2wiki 03:12 Info alschult
2007-01-19
[DELETED] Xotop Reno/Big black ass/hairy mature slit/big tit 14:37 Info localhost [1-75]
GregGibeling [76-149]		 #01 Upload of attachment 'wife.html'.
#02 Upload of attachment 'webcam.html'.
#03 Upload of attachment 'voyeur.html'.
#04 Upload of attachment 'virgin.html'.
#05 Upload of attachment 'vagina.html'.
#06 Upload of attachment 'upskirt.html'.
#07 Upload of attachment 'uniform.html'.
#08 Upload of attachment 'tits.html'.
#09 Upload of attachment 'teen.html'.
#10 Upload of attachment 'sucking.html'.
#11 Upload of attachment 'stripping.html'.
#12 Upload of attachment 'squirt.html'.
#13 Upload of attachment 'slut.html'.
#14 Upload of attachment 'slit.html'.
#15 Upload of attachment 'shemale.html'.
#16 Upload of attachment 'shaved.html'.
#17 Upload of attachment 'sex.html'.
#18 Upload of attachment 'pregnant.html'.
#19 Upload of attachment 'pornstar.html'.
#20 Upload of attachment 'porn.html'.
#21 Upload of attachment 'pissing.html'.
#22 Upload of attachment 'petite.html'.
#23 Upload of attachment 'panties.html'.
#24 Upload of attachment 'nudism.html'.
#25 Upload of attachment 'naked.html'.
#26 Upload of attachment 'movies.html'.
#27 Upload of attachment 'more1.html'.
#28 Upload of attachment 'milf.html'.
#29 Upload of attachment 'mature.html'.
#30 Upload of attachment 'male.html'.
#31 Upload of attachment 'lingerie.html'.
#32 Upload of attachment 'lesbian.html'.
#33 Upload of attachment 'legs.html'.
#34 Upload of attachment 'latina.html'.
#35 Upload of attachment 'interracial.html'.
#36 Upload of attachment 'index.html'.
#37 Upload of attachment 'incest.html'.
#38 Upload of attachment 'hot.html'.
#39 Upload of attachment 'hentai.html'.
#40 Upload of attachment 'hardcore.html'.
#41 Upload of attachment 'handjob.html'.
#42 Upload of attachment 'hairy.html'.
#43 Upload of attachment 'group.html'.
#44 Upload of attachment 'gay.html'.
#45 Upload of attachment 'free.html'.
#46 Upload of attachment 'fisting.html'.
#47 Upload of attachment 'fetish.html'.
#48 Upload of attachment 'femdom.html'.
#49 Upload of attachment 'female.html'.
#50 Upload of attachment 'fat.html'.
#51 Upload of attachment 'famous.html'.
#52 Upload of attachment 'erotica.html'.
#53 Upload of attachment 'ebony.html'.
#54 Upload of attachment 'drunk.html'.
#55 Upload of attachment 'dildo.html'.
#56 Upload of attachment 'creampie.html'.
#57 Upload of attachment 'coed.html'.
#58 Upload of attachment 'closeup.html'.
#59 Upload of attachment 'cheerleader.html'.
#60 Upload of attachment 'celebrity.html'.
#61 Upload of attachment 'cartoon.html'.
#62 Upload of attachment 'boobs.html'.
#63 Upload of attachment 'blowjob.html'.
#64 Upload of attachment 'bikini.html'.
#65 Upload of attachment 'bigdick.html'.
#66 Upload of attachment 'bdsm.html'.
#67 Upload of attachment 'barelylegal.html'.
#68 Upload of attachment 'babe.html'.
#69 Upload of attachment 'ass.html'.
#70 Upload of attachment 'asian.html'.
#71 Upload of attachment 'anal.html'.
#72 Upload of attachment 'amateur.html'.
#73 Upload of attachment 'adult.html'.
#74 Attachment 'KLM.html' deleted.
#75 Upload of attachment 'KLM.html'.
#77 Attachment 'wife.html' deleted.
#78 Attachment 'webcam.html' deleted.
#79 Attachment 'voyeur.html' deleted.
#80 Attachment 'virgin.html' deleted.
#81 Attachment 'vagina.html' deleted.
#82 Attachment 'upskirt.html' deleted.
#83 Attachment 'uniform.html' deleted.
#84 Attachment 'tits.html' deleted.
#85 Attachment 'teen.html' deleted.
#86 Attachment 'sucking.html' deleted.
#87 Attachment 'stripping.html' deleted.
#88 Attachment 'squirt.html' deleted.
#89 Attachment 'slut.html' deleted.
#90 Attachment 'slit.html' deleted.
#91 Attachment 'shemale.html' deleted.
#92 Attachment 'shaved.html' deleted.
#93 Attachment 'sex.html' deleted.
#94 Attachment 'pregnant.html' deleted.
#95 Attachment 'pornstar.html' deleted.
#96 Attachment 'porn.html' deleted.
#97 Attachment 'pissing.html' deleted.
#98 Attachment 'petite.html' deleted.
#99 Attachment 'panties.html' deleted.
#100 Attachment 'nudism.html' deleted.
#101 Attachment 'naked.html' deleted.
#102 Attachment 'movies.html' deleted.
#103 Attachment 'more1.html' deleted.
#104 Attachment 'milf.html' deleted.
#105 Attachment 'mature.html' deleted.
#106 Attachment 'male.html' deleted.
#107 Attachment 'lingerie.html' deleted.
#108 Attachment 'lesbian.html' deleted.
#109 Attachment 'legs.html' deleted.
#110 Attachment 'latina.html' deleted.
#111 Attachment 'interracial.html' deleted.
#112 Attachment 'indian.html' deleted.
#113 Attachment 'incest.html' deleted.
#114 Attachment 'hot.html' deleted.
#115 Attachment 'hentai.html' deleted.
#116 Attachment 'hardcore.html' deleted.
#117 Attachment 'handjob.html' deleted.
#118 Attachment 'hairy.html' deleted.
#119 Attachment 'group.html' deleted.
#120 Attachment 'gay.html' deleted.
#121 Attachment 'free.html' deleted.
#122 Attachment 'fisting.html' deleted.
#123 Attachment 'fetish.html' deleted.
#124 Attachment 'femdom.html' deleted.
#125 Attachment 'female.html' deleted.
#126 Attachment 'fat.html' deleted.
#127 Attachment 'famous.html' deleted.
#128 Attachment 'erotica.html' deleted.
#129 Attachment 'ebony.html' deleted.
#130 Attachment 'drunk.html' deleted.
#131 Attachment 'dildo.html' deleted.
#132 Attachment 'creampie.html' deleted.
#133 Attachment 'coed.html' deleted.
#134 Attachment 'closeup.html' deleted.
#135 Attachment 'cheerleader.html' deleted.
#136 Attachment 'celebrity.html' deleted.
#137 Attachment 'cartoon.html' deleted.
#138 Attachment 'boobs.html' deleted.
#139 Attachment 'blowjob.html' deleted.
#140 Attachment 'bikini.html' deleted.
#141 Attachment 'bigdick.html' deleted.
#142 Attachment 'bdsm.html' deleted.
#143 Attachment 'barelylegal.html' deleted.
#144 Attachment 'babe.html' deleted.
#145 Attachment 'ass.html' deleted.
#146 Attachment 'asian.html' deleted.
#147 Attachment 'anal.html' deleted.
#148 Attachment 'amateur.html' deleted.
#149 Attachment 'adult.html' deleted.
[DELETED] XotopReno 06:13 Info GregGibeling [1-2] #02 Attachment 'Big_black_ass' deleted.
[DELETED] Xotop Reno/Big black ass 06:13 Info GregGibeling [1-2] #02 Attachment 'hairy_mature_slit' deleted.
[DELETED] Xotop Reno/Big black ass/hairy mature slit 06:13 Info GregGibeling [1-2] #02 Attachment 'big_tit' deleted.
2007-01-12
[DIFF] Ramp Workshop Jan2007 21:35 Info GregGibeling [1-11]
2007-01-10
[DIFF] Ramp Workshop Jan2006 23:49 Info GregGibeling [1]
JohnW [2]		 #02 Upload of attachment 'Welcome.ppt'.
2007-01-02
[DIFF] IbobFaq 22:05 Info BrianRichards [1-2] #01 Upload of attachment 'ibob_prom_proc.pdf' .
2006-12-30
[DIFF] Bee2 Operating System 16:05 Info localhost Upload of attachment '1'.

[DIFF]

marks older pages that have at least one backup version stored (click for an author diff)

[UPDATED]

marks pages edited since you set your bookmark (click for a bookmark diff)

[NEW]

marks pages created since you set your bookmark, and were not edited after creation

[DELETED]

marks page deletions

This page contains a list of recent changes in this wiki. More system information on SystemInfo. For changes on other wikis, see WikiSites/Aggregation.

RecentChanges (last modified 2006-04-06 18:05:05)

SiteNavigation - BEE2wiki

SiteNavigation is the central place to explore this wiki. MoinMoin supports these IndexingSchemes:

On each page, there are actions that allow to navigate to other pages related to the current page:

Additionally, there are the [[PageList]], [[FullSearch('text')]] and [[TableOfContents]] macros, which allow you to automatically generate indices for cohesive parts of a wiki.

SiteNavigation (last modified 2006-04-06 18:05:06)

SystemInfo - BEE2wiki
Python Version
2.3.4 (#1, Sep 26 2006, 17:25:54) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)]
MoinMoin Version
Release 1.5.2 [Revision release]
4Suite Version
N/A
Number of pages
187
Number of system pages
149
Accumulated page sizes
716335
Entries in edit log
898 (106548 bytes)
Event log
6705410 bytes
Global extension macros
AbandonedPages, Action, AttachInfo, AttachList, BR, EditTemplates, EditedSystemPages, FootNote, FullSearch, FullSearchCached, GetText, Include, LikePages, MonthCalendar, Navigation, NewPage, OrphanedPages, PageHits, PageSize, RandomPage, RandomQuote, RecentChanges, ShowSmileys, StatsChart, SystemAdmin, TableOfContents, TeudView, Verbatim, WantedPages
Local extension macros
NONE
Global extension actions
AttachFile, DeletePage, Despam, LikePages, LocalSiteMap, MyPages, PackagePages, RenamePage, RenderAsDocbook, SpellCheck, SubscribeUser, backup, fckdialog, fullsearch, links, newpage, rss_rc, titleindex
Local extension actions
NONE
Global parsers
CSV, cplusplus, docbook, irc, java, pascal, plain, python, rst, wiki, xslt
Local extension parsers
NONE
Installed processors (DEPRECATED -- use Parsers instead)
NONE
Lupy search
Disabled
Active threads
11

SystemInfo (last modified 2006-04-06 18:05:05)

SystemPagesGroup - BEE2wiki

This is a list of all group pages grouping system pages of one language each:

If you do a new translation, please add your group page here.

/!\ The first level list for the group must only contain the names of the pages in that group. No English original names, no comments - better put that stuff onto a 2nd-level list item below the 1st-level one. Moin has functions to make use of the group pages, but they do only work if the 1st-level list is "clean". There should be no other 1st-level lists on the pages.

/!\ Please do not translate this page.

SystemPagesGroup (last modified 2006-04-06 18:05:05)

Temp - BEE2wiki

Temporary Stuff

Temp (last edited 2006-09-14 21:04:11 by temp)

Bee2Memory - BEE2wiki

http://bee2.eecs.berkeley.edu/img/BEE2_logo_mini.png

Overview

DDR2 Memory System

Created: 2006-06-09

  1. Introduction
  2. Physical Memory
  3. DDR2 Controller
  4. User Memory Interface
  5. Frequently Asked Questions
  6. Revision History

Introduction

The purpose of this document is to give an overview of the DDR2 memory system supported by the BEE2. In addition to a brief overview of the physical memory support on each BEE2 module, this document also describes the custom memory interface logic created for the BEE2 at the Berkeley Wireless Research Center.

Overview

Access to the raw DDR2 memory has been implemented through a set of interfaces which build upon one another. The following figure gives a high level implementation of this layered approach.

At the lowest level is the actual DDR2 memory controller. Each DIMM has its own independent DDR2 controller, each of which is heavily pipelined and supports simple bank management. On top of the low-level DDR2 controller is the user memory interface. The user memory interface is a simple, common interface that user logic can use to access memory. The interface is implemented as a series of asynchronous command FIFOs which provide command buffering and decouple the user clock domain from the 200MHz DDR2 controller clock domain. Finally, on top of the user memory interface, any arbitrary user logic can be implemented.

Multi-port Access

To provide multi-port access to each DIMM, we have provided a simple arbiter to the user memory interface for each DIMM. The switch is completely configurable in the number of ports, and has different modes of arbitration. The basic arbitration is priority round-robin. This gives a good balance between the needs of a priority based arbiter and provides starvation free arbitration. In addition to the basic mode, the arbiter also supports bursting. Bursting allows a requester to maintain arbitrated status while it holds down the request line up to a configurable window of cycles. This enables efficient bursting for applications which require bursting to maintain sufficient performance. Finally, in addition to these two modes of arbitration, the arbitration logic itself is highly self contained with a consistent interface, allowing users to easily implement their own arbitration scheme to suit their particular needs.

The multi-port switch provides each port the same user memory interface as is provided by the asynchronous command FIFO block. This means that any logic design to work directly with the user memory interface will work without modification with the multi-port switch. An example of a system which uses the multi-port switch can be seen below.

This example is similar to the setup of the reference Linux base system provided with the BSP. In this example the multi-port switch provides two ports. One is connected to a PLB attachment that allows the host processor to access the physical memory. The second port is attached to a frame buffer device (note that the OPB attachment for the frame buffer is not for data transfer, it is simply for control registers). In this example, bursting is turned on to meet the timing requirements of the framebuffer's DVI output.

Physical Memory

Each BEE2 module has five Virtex-II Pro 70 FPGAs, each of which are connected to four fully independent DDR2 DIMM modules. At present the maximum memory capacity of each module is 1GB (although higher density DIMMs could bring this to 2GB or above) giving a total memory capacity of 20GB per BEE2 module. The FPGA is wired to accept a 72-bit data path, allowing the use of ECC storage bits as well.

For more information on the details of the physical connections to memory, please see the BEE2 module documentation which contains links to schematics, and data sheets. Additionally the Bee2Setup page has information about part numbers for DIMMs that have been verified to work with the BEE2.

DDR2 Controller

Overview

The heart of the BEE2 memory system is the DDR2 controller. The controller is responsible for all of the low-level DRAM management data transfer tasks. The controller was originally based on the data path generated from the Xilinx MIG007 tool and then heavily modified at BWRC. The tasks performed by the controller include:

As of now, the controller allows access to ECC storage bits, but does not actually implement ECC. For more detailed information on the controller implementation, please see the core documentation directly for the ddr2_controller_v2_00_a core.

Interface

Although the DDR2 controller has independent data paths for read and write data, the controller does not allow simultaneous issuance of both read and write commands. However, the controller is highly pipelined and can issue a command every other cycle. The interface provided by the controller is fairly simple, although it runs at 200MHz and therefore can introduce timing problems if interacted with directly. The preferred way to interact with this interface is through the asynchronous command FIFO block (described below), but the lowest latency option is to use this interface directly. The following diagram shows the signals that comprise the interface.

Please note that although there are separate user_read and user_write signals, they may not be asserted at the same time, and therefore only a single read or write can be issued at a time.

Functional Description

Issuing a command to the controller is controlled by the user_ready signal. When this signal is high, it means that in that cycle it is possible to issue a new command. Because of the single cycle turn around on this signal, it often shows up on the critical path for this interface. The transaction happens in two phases. First the address is accepted, and second the data is fetched (for a write) or returned (for a read).

Phase 1: Address

When user_ready is high the user can assert either user_read or user_write (but not both) along with a valid 32-bit address. Note that although you present a 32-bit address, the lower 4-bits of the address will be unused because the controller transfers data aligned on 128-bit boundaries (actually it is 144-bits if you count the extra ECC storage bits). The transaction is accepted on the rising edge that sees both user_ready and user_read or user_write asserted. Ready will always go low for at least one cycle after accepting an address. An additional signal, user_half_burst is also sampled at issue time. If this signal is high, it means that the controller will only accept or generate one 144-bit data value. If it is low then it means the controller will accept or generate two 144-bit data values.

Phase 2: Data

Timing

The following timing diagrams describe the behavior of the DDR2 controller interface.

Write Transactions

If the user_half_burst signal is asserted when issuing the command, then the user_get_data signal will only be asserted for one cycle and the controller only expects one 144-bit data value.

Read Transactions

If the user_half_burst signal is asserted when issuing the command, then the user_data_valid signal will only be asserted for one cycle and the controller only sends one 144-bit data value.

User Memory Interface

Overview

Although interacting with the DDR2 controller interface directly is the highest performance, lowest latency option to access memory, most applications will have logic operating in a different clock domain than the 200MHz controller. To address this issue, we have provided a easier to use and clock decoupled interface called the user memory interface. The implementation of this interface is the async_ddr2_v2_00_a core which contains block RAM based asynchronous FIFOs to buffer commands and provide clock domain crossing.

The interface has several different modes of operation which are set by two parameters:

Finally, the asynchronous command FIFO core also give the user the option to utilize a command tag FIFO that will maintain a 32-bit tag that corresponds to each read transaction. This makes certain applications easier given the split phase operation of commands.

Interface

The following diagram shows all the signals that comprise the user memory interface.

The interface is comprised of roughly three components. The command (Cmd) signals are involved with issuing a read or write command. The write (Wr) signals carry data and byte enables for writes, and the read (Rd) signals carry data and tag information from reads.

Functional Description

Just like the DDR2 controller, the asynchronous command FIFO block does only allows a single read or write command per cycle and no reordering of commands is done within the block. This is an important point for consistency and coherence issues for multi-core systems, as this means that this core acts as a synchronization point for all commands. It is possible to augment this core to perform reordering and optimization, but at this time it is safe to assume the same order in and out of the core.

Phase 1: Command Issue

To issue a command the user will assert Mem_Cmd_Valid and will present a valid address on Mem_Cmd_Address. The cycle in which the command is accepted the core will assert Mem_Cmd_Ack (this may be asserted during the first cycle Mem_Cmd_Valid is asserted).

Phase 2: Read data

When the read data has returned from the controller the controller will assert Mem_Rd_Valid and the Mem_Rd_Dout and Mem_Rd_Tag buses will be valid. The user can acknowledge the data at any time by asserting Mem_Rd_Ack for a single cycle.

Special Case: Narrow data mode and full burst mode

The only case where the description above differs is when the core has been configured with C_WIDE_DATA=0 and C_HALF_BURST=0. This case corresponds to utilizing the full bandwidth of the DDR2 controller, but without using the internal block RAM muxes. In this case the user is required to issue two commands for a write and will need to acknowledge two read data values for a read.

Frequently Asked Questions

None so far.

Revision History

Click the Info link below to see the revision history.

Bee2Memory (last edited 2006-06-26 16:08:43 by alschult)

Bee2Memory - BEE2wiki

http://bee2.eecs.berkeley.edu/img/BEE2_logo_mini.png

Overview

DDR2 Memory System

Created: 2006-06-09

  1. Introduction
  2. Physical Memory
  3. DDR2 Controller
  4. User Memory Interface
  5. Frequently Asked Questions
  6. Revision History

Introduction

The purpose of this document is to give an overview of the DDR2 memory system supported by the BEE2. In addition to a brief overview of the physical memory support on each BEE2 module, this document also describes the custom memory interface logic created for the BEE2 at the Berkeley Wireless Research Center.

Overview

Access to the raw DDR2 memory has been implemented through a set of interfaces which build upon one another. The following figure gives a high level implementation of this layered approach.

At the lowest level is the actual DDR2 memory controller. Each DIMM has its own independent DDR2 controller, each of which is heavily pipelined and supports simple bank management. On top of the low-level DDR2 controller is the user memory interface. The user memory interface is a simple, common interface that user logic can use to access memory. The interface is implemented as a series of asynchronous command FIFOs which provide command buffering and decouple the user clock domain from the 200MHz DDR2 controller clock domain. Finally, on top of the user memory interface, any arbitrary user logic can be implemented.

Multi-port Access

To provide multi-port access to each DIMM, we have provided a simple arbiter to the user memory interface for each DIMM. The switch is completely configurable in the number of ports, and has different modes of arbitration. The basic arbitration is priority round-robin. This gives a good balance between the needs of a priority based arbiter and provides starvation free arbitration. In addition to the basic mode, the arbiter also supports bursting. Bursting allows a requester to maintain arbitrated status while it holds down the request line up to a configurable window of cycles. This enables efficient bursting for applications which require bursting to maintain sufficient performance. Finally, in addition to these two modes of arbitration, the arbitration logic itself is highly self contained with a consistent interface, allowing users to easily implement their own arbitration scheme to suit their particular needs.

The multi-port switch provides each port the same user memory interface as is provided by the asynchronous command FIFO block. This means that any logic design to work directly with the user memory interface will work without modification with the multi-port switch. An example of a system which uses the multi-port switch can be seen below.

This example is similar to the setup of the reference Linux base system provided with the BSP. In this example the multi-port switch provides two ports. One is connected to a PLB attachment that allows the host processor to access the physical memory. The second port is attached to a frame buffer device (note that the OPB attachment for the frame buffer is not for data transfer, it is simply for control registers). In this example, bursting is turned on to meet the timing requirements of the framebuffer's DVI output.

Physical Memory

Each BEE2 module has five Virtex-II Pro 70 FPGAs, each of which are connected to four fully independent DDR2 DIMM modules. At present the maximum memory capacity of each module is 1GB (although higher density DIMMs could bring this to 2GB or above) giving a total memory capacity of 20GB per BEE2 module. The FPGA is wired to accept a 72-bit data path, allowing the use of ECC storage bits as well.

For more information on the details of the physical connections to memory, please see the BEE2 module documentation which contains links to schematics, and data sheets. Additionally the Bee2Setup page has information about part numbers for DIMMs that have been verified to work with the BEE2.

DDR2 Controller

Overview

The heart of the BEE2 memory system is the DDR2 controller. The controller is responsible for all of the low-level DRAM management data transfer tasks. The controller was originally based on the data path generated from the Xilinx MIG007 tool and then heavily modified at BWRC. The tasks performed by the controller include:

As of now, the controller allows access to ECC storage bits, but does not actually implement ECC. For more detailed information on the controller implementation, please see the core documentation directly for the ddr2_controller_v2_00_a core.

Interface

Although the DDR2 controller has independent data paths for read and write data, the controller does not allow simultaneous issuance of both read and write commands. However, the controller is highly pipelined and can issue a command every other cycle. The interface provided by the controller is fairly simple, although it runs at 200MHz and therefore can introduce timing problems if interacted with directly. The preferred way to interact with this interface is through the asynchronous command FIFO block (described below), but the lowest latency option is to use this interface directly. The following diagram shows the signals that comprise the interface.

Please note that although there are separate user_read and user_write signals, they may not be asserted at the same time, and therefore only a single read or write can be issued at a time.

Functional Description

Issuing a command to the controller is controlled by the user_ready signal. When this signal is high, it means that in that cycle it is possible to issue a new command. Because of the single cycle turn around on this signal, it often shows up on the critical path for this interface. The transaction happens in two phases. First the address is accepted, and second the data is fetched (for a write) or returned (for a read).

Phase 1: Address

When user_ready is high the user can assert either user_read or user_write (but not both) along with a valid 32-bit address. Note that although you present a 32-bit address, the lower 4-bits of the address will be unused because the controller transfers data aligned on 128-bit boundaries (actually it is 144-bits if you count the extra ECC storage bits). The transaction is accepted on the rising edge that sees both user_ready and user_read or user_write asserted. Ready will always go low for at least one cycle after accepting an address. An additional signal, user_half_burst is also sampled at issue time. If this signal is high, it means that the controller will only accept or generate one 144-bit data value. If it is low then it means the controller will accept or generate two 144-bit data values.

Phase 2: Data

Timing

The following timing diagrams describe the behavior of the DDR2 controller interface.

Write Transactions

If the user_half_burst signal is asserted when issuing the command, then the user_get_data signal will only be asserted for one cycle and the controller only expects one 144-bit data value.

Read Transactions

If the user_half_burst signal is asserted when issuing the command, then the user_data_valid signal will only be asserted for one cycle and the controller only sends one 144-bit data value.

User Memory Interface

Overview

Although interacting with the DDR2 controller interface directly is the highest performance, lowest latency option to access memory, most applications will have logic operating in a different clock domain than the 200MHz controller. To address this issue, we have provided a easier to use and clock decoupled interface called the user memory interface. The implementation of this interface is the async_ddr2_v2_00_a core which contains block RAM based asynchronous FIFOs to buffer commands and provide clock domain crossing.

The interface has several different modes of operation which are set by two parameters:

Finally, the asynchronous command FIFO core also give the user the option to utilize a command tag FIFO that will maintain a 32-bit tag that corresponds to each read transaction. This makes certain applications easier given the split phase operation of commands.

Interface

The following diagram shows all the signals that comprise the user memory interface.

The interface is comprised of roughly three components. The command (Cmd) signals are involved with issuing a read or write command. The write (Wr) signals carry data and byte enables for writes, and the read (Rd) signals carry data and tag information from reads.

Functional Description

Just like the DDR2 controller, the asynchronous command FIFO block does only allows a single read or write command per cycle and no reordering of commands is done within the block. This is an important point for consistency and coherence issues for multi-core systems, as this means that this core acts as a synchronization point for all commands. It is possible to augment this core to perform reordering and optimization, but at this time it is safe to assume the same order in and out of the core.

Phase 1: Command Issue

To issue a command the user will assert Mem_Cmd_Valid and will present a valid address on Mem_Cmd_Address. The cycle in which the command is accepted the core will assert Mem_Cmd_Ack (this may be asserted during the first cycle Mem_Cmd_Valid is asserted).

Phase 2: Read data

When the read data has returned from the controller the controller will assert Mem_Rd_Valid and the Mem_Rd_Dout and Mem_Rd_Tag buses will be valid. The user can acknowledge the data at any time by asserting Mem_Rd_Ack for a single cycle.

Special Case: Narrow data mode and full burst mode

The only case where the description above differs is when the core has been configured with C_WIDE_DATA=0 and C_HALF_BURST=0. This case corresponds to utilizing the full bandwidth of the DDR2 controller, but without using the internal block RAM muxes. In this case the user is required to issue two commands for a write and will need to acknowledge two read data values for a read.

Frequently Asked Questions

None so far.

Revision History

Click the Info link below to see the revision history.

Bee2Memory (last edited 2006-06-26 16:08:43 by alschult)

TitleIndex - BEE2wiki

This is an index of all pages in this Wiki.

See also:

A | B | E | I | M | R | S | T | X
Include system pages | Plain title index | XML title index

A

AdcFaq

B

BcFaq
Bee2Binaries[18 attachments]
Bee2CoreOpbSelectMapV101a
Bee2Cores
Bee2CorrPhotos
Bee2Cvs
Bee2DebianRootFs
Bee2DebianRootNfs
Bee2Errata[6 attachments]
Bee2Faq
Bee2Feedback[3 attachments]
Bee2LinuxConfig
Bee2LinuxKernel
Bee2Memory[8 attachments]
Bee2OperatingSystem[4 attachments]
Bee2Pins[3 attachments]
Bee2QuickStart[2 attachments]
Bee2Readme
Bee2Reference
Bee2Setup[24 attachments]
Bee2TclRewrite
Bee2TestSuite[4 attachments]
BEE2wiki[4 attachments]
BEE3
BEE3/BEE3Group
BorphGettingStart[13 attachments]
BorphTutorials

E

embedded[7 attachments]

I

IbobFaq[2 attachments]

M

MssgeFaq
MssgeTodo

R

RampCoreSelectionMatrix
RampWorkshopJan2006[2 attachments]
RampWorkshopJan2007[2 attachments]

S

SystemPagesGroup

T

Temp[3 attachments]

X

XilinxUpload[2 attachments]

TitleIndex (last modified 2006-04-06 18:05:05)

UserPreferences - BEE2wiki
Name (Use FirstnameLastname)
Password
Password repeat (Only when changing passwords)
Email

First time

Please fill out Name, Password, Password repeat and Email.

(!) It is best to choose a WikiName (like FirstnameLastname) as username to get your changes and signatures link back to your WikiHomepage. Your email is needed for you to be able to get notifications on page changes and to recover lost login data.

If you click on Create Profile, a user profile will be created for you and you will be logged in immediately.

Logging in

If want to re-login, just use Name and Password and click on Login.

Resetting password

If you forgot your password, provide your email address and click on Mail me my account data.

The email you get contains the encrypted password (so even if someone intercepts the mail, he won't know your REAL password). Just copy and paste it into the login mask into the password field and log in.

Then change your password to a known value and save your settings.

Changing settings

Save updates your profile (stored on the wiki server).

Logging out

Logout clears the cookie created at login.

The Cookie

The cookie will expire next midnight - except if you choose Remember login information (after being logged in), then the cookie will not expire. After the cookie has expired, you have to login again.

UserPreferences (last modified 2006-04-06 18:05:05)

WantedPages - BEE2wiki

A list of non-existing pages including a list of the pages where they are referred to:

Include system pages
  1. Bee2Communication: BEE2wiki
  2. Bee2Configuration: BEE2wiki
  3. Bee2CoreAsyncDdr2V200a: Bee2Cores, Bee2Memory
  4. Bee2CoreDdr2ControllerV200a: Bee2Cores, Bee2Memory
  5. Bee2CoreInterchipBlockV100a: Bee2Cores
  6. Bee2CoreMultiportDdr2V200a: Bee2Cores
  7. Bee2CoreOpbFifoV100a: Bee2Cores
  8. Bee2CoreOpbFramebufferV200a: Bee2Cores
  9. Bee2CoreOpbSelectMapFifoV101a: Bee2CoreOpbSelectMapV101a, Bee2Cores
  10. Bee2CoreOpbSoftwareIicV100a: Bee2Cores
  11. Bee2CorePlbDdr2V200a: Bee2Cores
  12. Bee2CoreXauiInterfaceV200a: Bee2Cores
  13. Bee2Peripherals: BEE2wiki
  14. BobBrodersen: BEE3/BEE3Group
  15. BorphUsingIoreg: BorphGettingStart
  16. BrianRichards: BEE3/BEE3Group, Bee2CorrPhotos, IbobFaq, embedded
  17. Chen Chang: BEE3
  18. ChenChang: BEE3/BEE3Group
  19. DavidWeaver: RampCoreSelectionMatrix
  20. GregGibeling: RampWorkshopJan2006, RampWorkshopJan2007
  21. HaydenSo: Bee2OperatingSystem, BorphTutorials
  22. JohnWawrzynek: BEE3/BEE3Group
  23. MicroBlaze: RampCoreSelectionMatrix
  24. ProtoFlex: RampCoreSelectionMatrix
  25. SystemPagesInCzechGroup: SystemPagesGroup
  26. SystemPagesInDanishGroup: SystemPagesGroup
  27. SystemPagesInDutchGroup: SystemPagesGroup
  28. SystemPagesInFinnishGroup: SystemPagesGroup
  29. SystemPagesInFrenchGroup: SystemPagesGroup
  30. SystemPagesInGermanGroup: SystemPagesGroup
  31. SystemPagesInHebrewGroup: SystemPagesGroup
  32. SystemPagesInHungarianGroup: SystemPagesGroup
  33. SystemPagesInItalianGroup: SystemPagesGroup
  34. SystemPagesInJapaneseGroup: SystemPagesGroup
  35. SystemPagesInKoreanGroup: SystemPagesGroup
  36. SystemPagesInLatvianGroup: SystemPagesGroup
  37. SystemPagesInNorwegianBokmalGroup: SystemPagesGroup
  38. SystemPagesInPolishGroup: SystemPagesGroup
  39. SystemPagesInPortugueseGroup: SystemPagesGroup
  40. SystemPagesInRomanianGroup: SystemPagesGroup
  41. SystemPagesInRussianGroup: SystemPagesGroup
  42. SystemPagesInSerbianGroup: SystemPagesGroup
  43. SystemPagesInSimplifiedChineseGroup: SystemPagesGroup
  44. SystemPagesInSpanishGroup: SystemPagesGroup
  45. SystemPagesInSwedishGroup: SystemPagesGroup
  46. SystemPagesInTraditionalChineseGroup: SystemPagesGroup
  47. SystemPagesInTurkishGroup: SystemPagesGroup
  48. alschult: BEE2wiki, BcFaq, Bee2Binaries, Bee2CoreOpbSelectMapV101a, Bee2Cores, Bee2Cvs, Bee2DebianRootFs, Bee2DebianRootNfs, Bee2Errata, Bee2Faq, Bee2Feedback, Bee2LinuxConfig, Bee2LinuxKernel, Bee2Memory, Bee2Pins, Bee2QuickStart, Bee2Readme, Bee2Reference, Bee2TclRewrite, Bee2TestSuite, MssgeTodo, Temp
  49. aparsons: AdcFaq
  50. droz: XilinxUpload
  51. hchen05: Bee2Setup, BorphGettingStart, MssgeFaq

WantedPages (last modified 2006-04-06 18:05:05)

WikiSandBox - BEE2wiki

Feel free to experiment here, after the four dashes below. Please do not create new pages without any meaningful content just to try it out!

You may want to open HelpOnEditing in a new window or tab while you edit.

Formatting

italic bold typewriter

backtick typewriter (configurable)

bigger smaller 

preformatted some more
and some more lines too


   1 def syntax(highlight):
   2     print "on"
   3     return None

   1   public void main(String[] args]){
   2      System.out.println("Hello world!");
   3   } 
   4

Linking

HelpOnEditing InterWiki

http://moinmoin.wikiwikiweb.de/ Python

someone@example.com

Image Link

wiki

Smileys

/!\ Alert

Lists

Bullet

Glossary

Term

Definition

Drawing

http://moinmaster.wikiwikiweb.de/ http://moinmoin.wikiwikiweb.de/ Edit drawing mytest.png Edit drawing mytest.png Edit drawing mytest.png Edit drawing mytest.png mytest

Heading 1

Heading 2

Heading 3

Heading 4

WikiSandBox (last modified 2006-04-06 18:05:05)

WikiWikiWeb - BEE2wiki

The first ever wiki site was founded 1995-03-25 as an automated supplement to the PortlandPatternRepository (see History). The site was immediately popular within the pattern community, largely due to the newness of the internet and a good slate of InvitedAuthors. The site was, and remains, dedicated to PeopleProjectsAndPatterns.

WardCunningham created the site and his WikiWikiWeb machinery that operates it. He chose wiki-wiki as an alliterative substitute for quick and thereby avoided naming this site quick-web. An early page, WikiWikiHyperCard, traces wiki ideas back to a HyperCard stack he wrote in the late 80's.

See also one of these links:

WikiWikiWeb (last modified 2006-04-06 18:05:05)

WordIndex - BEE2wiki

This is an index of all words occuring in page titles.

See also:

A | B | C | D | E | F | G | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X
Include system pages

A

Adc

B

BcBee2BinariesBorph

C

ConfigCoreCoresCorrCvs

D

Debian

E

E2wikiE3Errata

F

FaqFeedbackFs

G

GettingGroup

I

Ibob

J

Jan2006Jan2007

K

Kernel

L

Linux

M

MapMatrixMemoryMssge

N

Nfs

O

OpbOperating

P

PagesPhotosPins

Q

Quick

R

RampReadmeReferenceRewriteRoot

S

SelectSelectionSetupStartSuiteSystem

T

TclTempTestTodoTutorials

U

Upload

V

V101a

W

Workshop

X

Xilinx

WordIndex (last modified 2006-04-06 18:05:04)

XilinxUpload - BEE2wiki

Describe XilinxUpload here.

Upload from Xilinx file.zip

XilinxUpload (last edited 2006-08-24 00:48:17 by droz)