Recent Changes

Monday, July 3

  1. page Guitar Hero on FPGA edited The Autocaster: An FPGA-Based Embedded System This page has been moved to Autonomously Play M…

    The Autocaster: An FPGA-Based Embedded SystemThis page has been moved to Autonomously Play Music Video Games
    The Autocaster is an embedded system based around a Digilent Atlys FPGA board, developed by Russell Joyce as a final year project for
    the MEng Computer Science with Embedded Systems Engineering course.
    The project's original title was 'Guitar Hero on FPGA', which evolved into a system that can autonomously play both Rock Band and Guitar Hero games running on a PlayStation 3.
    Source code, including build instructions, is available on GitHub at
    {autocaster-with-pcb.jpg} The
    new system hardware (with PCB) - Atlys FPGA board on left, Teensy USB controller board on right
    {board.jpg} The old system hardware - Atlys FPGA board on left, Teensy USB controller board on right
    The system is fairly straightforward to use, once programmed with the correct bitstream and software, and connected to the console.
    Before programming the system, connect the following cables:
    Micro-USB for programming the Atlys
    Micro-USB for serial UART to the Atlys (optional)
    HDMI input from the PS3, via Component-to-HDMI converter (use socket
    wiki, at top of Atlys)
    HDMI output to a display, works with HDMI or HDMI-to-DVI cable (use socket at top of Atlys)
    Micro-USB for controller output to PS3 from Teensy
    Turn the PlayStation 3 and converter box on before programming the board, so HDMI signal is already present. The PS3 must be outputting to component video at 720p for the system to recognise the HDMI connection.
    Once the PS3 and converted box are on and connected, turn on the Atlys board (the Teensy will already be powered from the USB connection). Make sure all the switches are off on the Atlys, to avoid messing with the PS3 menus.
    If the Atlys has the project already loaded in its flash memory, the HDMI input will be mirrored to the output display and the system will be ready to use. If not, or the latest system version needs to be loaded, follow the instructions on GitHub for synthesising the XPS project, exporting to Xilinx SDK and running.
    The PS3 menus can be controlled using the buttons on the PCB, or another connected controller or keyboard. The green, red, yellow, blue and orange buttons correspond fret buttons on the guitar neck and translate to X, O, Square, Triangle and L1 buttons on a standard PS3 controller.
    Insert the game disc into the PS3, navigate to the disc icon in the 'Game' menu, and press Green/X/Enter to start the game.
    Once the game has loaded, the video input will probably break, due to the brief loss of HDMI signal. To fix this (or any other visual glitches) press the red reset button on the Atlys board or reprogram the FPGA.
    Once the game has loaded, the menus can be navigated using the controller buttons on the PCB and a song can be launched. Once a song has loaded, use the switches to enable the game player core, as shown in the table below.
    The switches and buttons on the Atlys are mapped to the following functions:
    Freeze the output image (does not affect player)
    Draw markers on output for positions of note detectors
    Enable the player when on (turn off for navigating menus)
    Continually output player status over UART (if filters disabled)
    Stream video over Ethernet to PC* (if filters disabled)
    Enable each level of image filtering - each switch adds to previous filters, turn all on for mix with unfiltered input (if filters enabled)
    Increase player delay (prints delay to UART)
    Decrease player delay (prints delay to UART)
    Captures and outputs a series of consecutive video sub-frames over Ethernet
    Outputs the current video frame buffer over Ethernet (freeze first!)
    Attempts to reset VDMA core - often results in sync issues, use reset button to fix
    *Use the EthernetStream C# program (or the separate RTSScreen program) to view the video feed.
    **Use the EthernetImage C# program to capture these images.
    System Design
    The system is based around a Digilent Atlys FPGA development board, which contains a Xilinx Spartan-6 FPGA, and has connections for HDMI video input/output, USB UART and custom peripherals.
    The Atlys board is connected to the console using HDMI, allowing for a 720p image to be used for analysis by the system. Due to the HDCP encryption on the HDMI output of the PlayStation 3, a Component-to-HDMI converter is used to capture HD video. The Atlys also uses an HDMI output for connection to a display, in order to monitor the operation of the system.
    Control of the PlayStation 3 console is achieved using a USB connection, with a Teensy 3.0 USB development board emulating an off-the-shelf guitar controller. The Teensy is connected to the Atlys on its VHDC interface, translating control signals from the FPGA into the appropriate USB signals for sending to the console.
    As well as the connection to the Teensy, the PCB has several LEDs, corresponding to buttons on the emulated guitar controller, which can be used for monitoring the operation of the system.
    {system-interfaces+component.png} System structure and connections
    FPGA Cores
    The majority of processing is performed by dedicated cores on the FPGA, including HDMI decoding/encoding, image analysis and control logic. The FPGA also contains a MicroBlaze soft processor, which is used to control the synthesised hardware cores.
    The FPGA code is written in a mixture of VHDL, Verilog and Bluespec SystemVerilog (BSV), and is based around a Xilinx Platform Studio 14.3 project.
    The structure of the custom FPGA core code is as follows:
    HDMI Core
    The HDMI encoder/decoder core is based on the axi_hdmi core from the Digilent Atlys DSD-0000332 reference designs (available at The decoder modules of the core were modified to expose additional HDMI control signals, as well as making it compatible with the HDMI input from the component-to-HDMI converter unit (which outputs HDMI with audio, rather than the DVI-style video expected by the original core).
    Each frame of video is buffered in DDR-RAM, using an axi_vdma core, before being outputted to a display, allowing for image manipulation using the MicroBlaze software. Video is also streamed to the player core in real-time, so it can analyse each pixel as it is received. An optional image filter core intercepts the AXI stream bus between the HDMI and VDMA cores, in order to apply real-time image filters to the video feed.
    Player Core
    The gh_player core contains the image analysis and player control logic, and performs the majority of the processing required by the system.
    {gh-player.png} Structure of the gh_player core and its I/O ports
    The core is defined over several files, in a mixture of VHDL, Verilog and Bluespec SystemVerilog (BSV) code. The top-level interface with XPS is written in VHDL, which is then linked to a Verilog module (user_logic) that controls the core's registers. The user_logic module also creates an instance of either the standard of filtered player modules, which is used to control the game.
    The player module contains instances of the following BSV modules (compiled to Verilog) for low-level operation:
    mkFret (x5) - Monitors a position on the screen and outputs a signal corresponding to whether a note is present for the corresponding fret
    mkStrum - Calculates whether the strum bar needs pressing, based on the output of the mkFret modules
    mkWhammy - Constantly moves the whammy bar output (between 0->255->0) at a fixed rate
    mkTilt - Activates the tilt output at a fixed interval
    mkDelay - Adds a configurable delay to the mkFret and mkStrum outputs, allowing for detection to take place further up the screen than the target zone for playing the notes
    The gh_player core has I/O ports for connection to the HDMI input (through the image_filter core) and to output pins for the Teensy and LEDs.
    The player core has several software-accessible registers for controlling the following:
    Note detection thresholds
    Note detector positions
    Enabling/disabling controller output
    Switching between standard and filtered note detector
    Receiving status information about the current player state (e.g. what notes are detected)
    These registers are accessed from MicroBlaze code using the functions in the gh_player driver C file.
    Image Filter Core
    The image filter core applies real-time image filtering to the video input, allowing for pre-processing before the image is received by the player core. The image_filter core intercepts the AXI stream bus connecting the axi_hdmi core and axi_vdma cores, in order to modify the image being written to RAM (for the monitor output), as well as the image data stream being received by the gh_player core.
    The following filters are applied, based on offline image analysis work:
    The image filter core is not enabled by default (this can be controlled from the MicroBlaze code) as it currently reduces the accuracy of the system. However, with further work the image filters could potentially improve the system accuracy by reducing interference from other graphical elements on the game screen.
    The image filter core has software-accessible registers for enabling it and setting the desired level of filtering for processing and display, as well as controlling certain filter parameters. These registers are accessed from MicroBlaze code using the functions in the image_filter driver C file.
    Screen Detector
    This core allows for certain pixels to me monitored on the screen to detect certain events within a game, such as a song finishing. This can be used to automatically progress to the next song via MicroBlaze control logic.
    MicroBlaze Software
    A MicroBlaze soft core processor is used to control the main FPGA cores, through the use of software-accessible registers. This allows for tuning of parameters and modifications to certain elements of the system operation without the need to resynthesise hardware.
    The MicroBlaze software is written in C, using the Xilinx SDK.
    The software consists of several components, each controlling a different aspect of the system. The main program initialises the hardware, including the HDMI connections and player core, then waits in a loop monitoring the buttons and switches on the Atlys board and responding to changes appropriately.
    Performs the setup of the player core, and calls functions to set up the rest of the hardware.
    Thresholds for note detection are defined here.
    Contains definitions of what switches do, and function for drawing crosses on video buffer.
    Contains functions for controlling the hardware timer.
    Not currently used (no timer implemented on FPGA).
    Contains functions for setting up global interrupts.
    Sets up and controls the Ethernet core.
    Functions for controlling HDMI core output resolution.
    Contains functions and interrupt controller for sending EDID over I2C bus.
    The EDID used is defined in the header file.
    Sets up VDMA core for reading and storing data from HDMI.
    This file performs the majority of what is required to receive and transmit HDMI video in the system.
    Helper functions for bit operations.
    Handles Atlys button press interrupts.
    Contains and defines any parts of the system that can be modified by button presses. This currently includes note locations and player delay value.
    Basic input functions for Atlys switches.
    Basic output functions for Atlys LEDs.
    Teensy Software
    The Teensy controls the USB output of the system, translating basic signals from the FPGA to an output that is recognised by the PlayStation 3 console.
    The Teensy software is written in C and C++, using the Arduino IDE with Teensyduino extensions and a custom USB device type.
    The software polls each Teensy input pin around 200 times per second, and outputs the appropriate controller state data over the USB connection. The following table shows the mapping of Teensy pins to controller buttons:
    Pin Number
    Orange Fret
    Blue Fret
    Yellow Fret
    Red Fret
    Green Fret
    Up (Strum)
    Select Button (Tilt)
    Start Button
    Whammy Bar 0 (LSB)
    Whammy Bar 1
    Whammy Bar 2
    Whammy Bar 3
    Whammy Bar 4
    Whammy Bar 5
    Whammy Bar 6
    Whammy Bar 7 (MSB)
    USB Device
    The emulated controller is based on the guitar bundled with Guitar Hero Warriors of Rock, using the same VID, PID, product name and manufacturer name, but with a slightly altered USB descriptor to remove the proprietary endpoints used for communication with the PS3. This causes the device to display as a standard USB game controller on a PC, while still being recognised as a guitar controller by the PS3.
    Hardware Design (PCB)
    The physically constructed hardware of the system consists of a single PCB connected to the VHDC interface of the Atlys, with the Teensy board mounted on it.
    The main purpose of the physical hardware is to supply a connection between the Atlys and Teensy boards. It is also used to allow input from the user, and to output the status of the system using coloured LEDs.
    Each LED represents a control output from the player core, which are independent of the control outputs (they will still light when the player is disabled). The first five LEDs are coloured like the fret buttons on the guitar controller, and each lights up whenever the system detects that its respective button should be pressed. The sixth LED is white and represents the strum bar output, the seventh is green and represents the most significant bit of the whammy output, and the eighth is yellow and represents the tilt control output.
    The buttons on the PCB can be used to control the PS3 system independently of the FPGA.
    The jumper on the PCB marked POW is used to connect a 5V power supply to the Teensy from the Atlys board, allowing it to be powered with the rest of the system rather than through its USB connection. Before connecting this jumper, ensure that the 5V USB power pads have been cut on the Teensy, as described at
    The Aux Out pins on the PCB can be used to connect an external controller instead of the Teensy board, and have the following connections:
    Pin Number
    1 (top)
    Whammy MSB
    Green Fret
    Red Fret
    Yellow Fret
    Blue Fret
    Orange Fret
    9 (bottom)
    {autocaster-pcb.jpg} The PCB with LEDs, buttons and Teensy
    The PCB design is shown below, with the Eagle design file available in the project Git repository.
    {autocaster-pcb-design.png} PCB Design (click for PDF)
    {autocaster-pcb-schematic.png} PCB Schematic (click for PDF)
    Old Hardware Designs
    Before the PCB was created, a series of breadboard were used to connect the Teensy and LEDs to the Atlys. The details of this have been left below to assist with setting up a system without a PCB. The hardware is connected to two I/O interfaces of the Atlys board: the VHDCI and the Pmod connector.
    The VHDC interface is connected to a VmodBB breadboard, which has the Teensy mounted on it. A second breadboard is connected to this, for the user to override the input to the Teensy, allowing for manual control of the PlayStation 3.
    {vmodbb.jpg} The VmodBB breadboard, with Teensy and control buttons
    {vhdci-circuit.png} VHDCI Circuit - Atlys to Teensy (click for PDF)
    The Pmod connector is attached to eight coloured LEDs, mounted on a breadboard, with each representing a control output from the player core. The first five LEDs are coloured like the fret buttons on the guitar controller, and each lights up whenever the system detects that its respective button should be pressed. The sixth LED is white and represents the strum bar output, the seventh is green and represents the most significant bit of the whammy output, and the eighth is yellow and represents the tilt control output.
    {leds.jpg} Status LEDs connected to the Pmod interface
    {pmod-circuit.png} Pmod Circuit - Atlys to LEDs (click for PDF)
    Final hardware playing expert guitar on 'No One Knows' in Rock Band 3
    Playing expert guitar on 'Walk of Life' in Rock Band 3
    Demonstration of real-time image filtering
    (view changes)
    12:47 pm
  2. page Experiment Source Code edited Experiment Source Code and Raw Data This This page has been migrated moved to the new wik…

    Experiment Source Code and Raw Data
    This page has been migratedmoved to the new wiki and can be foundwiki, at

    (view changes)
    10:44 am

Monday, March 6

  1. page home edited We are currently in the process of migrating this wiki to the York Wiki Service, at https://wiki…

    We are currently in the process of migrating this wiki to the York Wiki Service, at
    Real-Time Systems Lab Wiki
    This wiki contains the documentation for all the components and systems in the Real-Time Systems Research Group Laboratory at the University of York. We are part of the Department of Computer Science and are located on the Heslington East campus. Our publications are listed by Google Scholar.
    (view changes)
    3:53 am
  2. page edited ... Blueshell Xilinx Workarounds EMBS EMBS 2015 Microblaze API Vivado HLS Knowledge Base Re…
    Xilinx Workarounds
    EMBS 2015
    Microblaze API
    Vivado HLS Knowledge Base
    Remote working

    Student projects
    (view changes)
    3:51 am
  3. page Projects edited List of interesting projects done in This page has been moved to the lab: Robot Ultrasonic A…
    List of interesting projects done in
    This page has been moved to
    the lab:
    Robot Ultrasonic Array - Phil Greenland (2013)
    Guitar Hero on FPGA - Russell Joyce (2013)
    new wiki, at
    (view changes)
    3:50 am
  4. page Xilinx Workarounds edited This This page has been migrated moved to the new wiki, at…
    page has been migratedmoved to the new wiki, at

    (view changes)
    3:49 am
  5. page Poindexter edited Poindexter is an ABB IRB 340 FlexPicker robot, originally controlled by an RTSJ system developed b…
    Poindexter is an ABB IRB 340 FlexPicker robot, originally controlled by an RTSJ system developed by Sun Microsystems and Lund University.

    This page
    has now moved to the RTS lab, and is currently having its control software re-written in C++.
    The original RTSJ controller code is available at, and the newer C++ controller code is at
    A YouTube video from JavaOne 2007 shows Poindexter in its prime as the "World's First Java-Controlled Industrial Robot".
    Papers describing the original Java-based controller can be found here and here.
    Safe Operating Procedure:
    Please adhere to these instructions when operating the Flexpicker robot:
    1) Ensure that all controls on the front panel are in the "off" position (servo amplifier power off, aux power off, enable switch OUT).
    2) Connect three-phase power and switch on (turn the switch to the right). Note that the socket has an interlock; power cannot be enabled without a plug being connected, and the plug cannot be removed when power is on.
    3) Switch on 24V aux power (black switch). Await servo drives booting and wait until the display shows the power of the servo drive (either 20 or 05):
    4) Start control software on the target PC. Ensure correct communications can be established.
    5) Prepare for startup. Ensure Poindexter's doors are closed and the microswitches have
    been correctly depressed. Ensure the area inside Poindexter's cage is free of extra items. Ensure the area around Poindexter is clear.
    6) Enable servo amplifier power (red switch). Observe that the servo drives now have a 'P' (Powered) to the left of the display:
    7) Push in the enable switch on the control panel. Observe that the yellow "active" light has illuminated on the bottom of Poindexter:
    NOTE: This light signifies that Poindexter is ready for operation, and that the hardware safety has been disabled. Poindexter can now be freely controlled from software. NEVER APPROACH POINDEXTER WHILE THIS LIGHT IS ON. DO NOT OPEN THE DOORS WHILE THIS LIGHT IS ILLUMINATED.
    8) Control Poindexter from software as usual. When Poindexter is active and under software control, the 'P' at the left of each servo drive will change to an 'E' (Enabled).
    The shutdown procedure for Poindexter is largely the inverse of the startup procedure. REMEMBER TO POWER DOWN POINDEXTER BEFORE LEAVING THE LAB.
    1) Perform a switch-off from software and cease all software control of Poindexter. Observe that the servo drive has a 'P' at the left, not an 'E'.
    2) Pull out the enable switch. Observe that Poindexter's active lamp has been extinguished.
    3) Disable servo amplifier power (red switch). Observe that the servo drive no longer has a 'P' on the display.
    4) Switch off 24V aux power. Ensure all servo drives power down.
    5) Switch off three-phase supply. Optionally unplug Poindexter.
    Note: If the expected behaviour (lights changing state, servo drive display not updating correctly) does not occur, power down Poindexter immediately and report the problem to someone in CSE/120 and/or faults.
    Manually Moving Poindexter's Arms
    Poindexter's arms can be
    moved manually if required. Do not attempt to move the arms against the servo brakes which are engaged when the robot is disabled and/or powered down. ONLY EVER MOVE POINDEXTER'S ARMS WITH THE 415V SERVO AMPLIFIER POWER OFF.
    1) Ensure that the 24V aux power is ON and that the enable switch is OFF (out) and that the servo drive (415V) power is OFF.
    2) Open Poindexter's doors.
    3) In the centre of Poindexter is a black push button. Press and hold this button. This causes the brakes to release. It will also enable the fan, this is normal.
    4) Move Poindexter's end effector to the required position.
    Emergency Stop
    If an emergency stop of Poindexter is required, disable either the servo drive (415V) power or the 24V aux supply. Poindexter will also perform an emergency stop if the doors are opened.
    There are a few known errors which can occur when using Poindexter:
    Warning n17 appears on servo drive screen: This signifies the servo drive has lost sync with the host computer in a non safety-critical context. This is normal when the drive is in PREOP state, since PDOs are not mapped and hence data cannot be supplied to the drive (and thus a sync cannot occur). This is also normal in SAFEOP when the master is starting to send data and synchronise with the drive. The drive will not move into OP state while this warning is active. Note that the drive will report this if data is arriving too late OR too early. Check that data is being sent
    new wiki, at the rate programmed into SDO <TODO: SDO NUMBER>.
    Error E28 appears on servo drive screen: The slave lost sync with the master. This will cause the drive to cease functioning and fall back to the SAFEOP state. This error will appear if data is not provided to the drive at a given rate in the OP state, or after a timeout in the SAFEOP state. This error must be cleared before the drive will operate again. This error will also appear if the controlling program quits without resetting the drive state to PREOP or INIT.
    Error E29 appears on servo drive screen: The EtherCAT registers have not been configured correctly when attempting to change state. This is normally caused when a PDO SyncManager length does not match the expected PDO length EXACTLY.
    The robot acts...strangely: The robot has before done weird behaviour when misconfigured. If strange behaviour occurs, ensure that the FMMU lengths match the respective SyncManager lengths exactly. It is not sufficient to write zeros to the remainder of the FMMU space.
    Error(s) F04 and F06 appear on the servo drive screen: This is typically caused when the servo drive has lost feedback with the servo. Check the X1 resolver cables (the serial cables) and ensure they are plugged in.
    The orange active light never illuminates: The enable circuit could not be closed. This could indicate the doors are not correctly closed, the door interlock is not connected to the control box, or the control box's enable switch is not depressed. This could also indicate a failure in any of these components.
    The servo drives never turn on: Check the three-phase socket is turned on. If so, there are a set of circuit breakers in the back of Poindexter's control box. See Pete to get the keys to this to reset them.

    (view changes)
    3:48 am
  6. page The EMBS VGA Core edited This page has been moved to the new wiki, at …

    This page has been moved to the new wiki, at
    The EMBS VGA core provides a 3-bit (eight colour) display output at 640x480, 800x600 or 1024x768 for the Spartan-3E Starter Boards.
    Please read this entire page before using the VGA core in your design (I know it's long, but it'll help, I promise).
    If you find any issues with the core, ask a demonstrator or email
    Tips on using VGA in the labs
    The VGA connection on some lab monitors is connected through a KVM switch to both the FPGA board and the chute PC (used in ARTS). In order to use these, you must also plug the PS/2 keyboard connection into the FPGA board as the KVM uses this for power. You may also need to change the input source - to do this, connect a PS/2 keyboard (available under the desk, or ask hardware technicians) to the purple socket on the switch, then double press 'Scroll Lock' and press up/down - the light on the KVM should be on if it is working.
    The '4:3 in Wide' button on the lab monitors can be used to stop the image stretching to an incorrect aspect ratio.
    If the image flickers or does not line up correctly with the edges of the screen, try using the 'Auto' button while the display is filled with non-black graphics that touch all four edges of the screen (the test images should work for this).
    If the monitor complains that the resolution is unsupported, double check that your pixel clock value matches the resolution you've selected (see the table below). The lab monitors should correctly identify the three valid resolutions available with the core as: 640x480@61Hz, 800x600@60Hz and 1024x768@60Hz.
    Adding the core to your design
    Download the core and extract it to the 'pcores' directory within the root of your XPS project:
    cd {your XPS project}/pcores/
    tar xzf embs_vga.tar.gz
    rm embs_vga.tar.gz
    Load your project in XPS
    Select Project | Rescan User Repositories.
    Select the 'IP Catalog' tab on the left-hand side, and expand 'Project Local PCores' then 'EMBS'. You should see a component called 'VGA Core'.
    Double click this component and answer 'Yes' then 'OK' (the sections below on resolution and pixel width explain how the settings here can be changed, but for now the defaults are fine).
    Select the 'System Assembly View' tab then 'Bus Interfaces'.
    Find the 'embs_vga_0' component and expand it by clicking the +
    It has two bus connections, MPLB (master PLB) and SPLB (slave PLB). Use the drop down boxes to connect these both to mb_plb.
    Click the 'Addresses' tab and click the 'Generate Addresses' button. (A yellow icon on its own in the top right)
    Click the 'Ports' tab and expand the 'embs_vga_0' component by clicking the +
    Select the 'Red', 'Green', 'Blue', 'HSync' and 'VSync' connections (NOT 'Pixel_Clk'), right click and select 'Make External' from the menu. The 'Connected Port' column for each signal should automatically fill in with a value starting with 'External Ports::embs_vga_0_' followed by the signal name and '_pin'. This connects the five VGA signals to external ports (it routes them to outside the FPGA).
    Now select Hardware | Launch Clock Wizard
    A dialogue may appear telling you "The following clock ports are editable...". Click OK.
    Find the 'embs_vga_0' component and set its 'Pixel_Clk' frequency to 40.000000 MHz (you may have to type this if it is not in the drop down list). This value will be different if a different output resolution is chosen (see below).
    Click Validate Clocks. It should say "Clock Validations were successful!".
    Click OK. Click OK on the "Please make sure..." box that appears.
    We have finished connecting up the VGA component inside the FPGA. The last thing we need to do it to tell the tools which pins on the FPGA to use for the Red, Green, Blue, HSync and VSync signals, and to relax the timing constraints between the PLB and pixel clocks (so the static timing analysis phase doesn't moan at us).
    Open your project's User Constraints File by double-clicking 'UCF File' in the 'Project Files' list of the 'Project' window in XPS (alternatively, open <your XPS project>/data/system.ucf in a text editor).
    Scroll to the bottom of the file and copy and paste the following in to it:
    # EMBS VGA Core
    NET "embs_vga_0_Red_pin" LOC = "H14" | IOSTANDARD = LVTTL | DRIVE = 8 | SLEW = FAST ;
    NET "embs_vga_0_Green_pin" LOC = "H15" | IOSTANDARD = LVTTL | DRIVE = 8 | SLEW = FAST ;
    NET "embs_vga_0_Blue_pin" LOC = "G15" | IOSTANDARD = LVTTL | DRIVE = 8 | SLEW = FAST ;
    NET "embs_vga_0_HSync_pin" LOC = "F15" | IOSTANDARD = LVTTL | DRIVE = 8 | SLEW = FAST ;
    NET "embs_vga_0_VSync_pin" LOC = "F14" | IOSTANDARD = LVTTL | DRIVE = 8 | SLEW = FAST ;
    PIN "embs_vga_0.MPLB_Clk" TNM_NET = clk1;
    PIN "embs_vga_0.Pixel_Clk" TNM_NET = clk2;
    TIMESPEC TS_clk1_clk2 = FROM "clk1" TO "clk2" 10 ns DATAPATHONLY;
    TIMESPEC TS_clk2_clk1 = FROM "clk2" TO "clk1" 10 ns DATAPATHONLY;
    Save and close the UCF file.
    Click Hardware | Generate Bitstream.
    Re-export your design to SDK.
    In SDK, right click on your BSP and select Board Support Package Settings.
    Select Drivers. 'embs_vga_0' should be in the list. If it is not, close and re-open SDK.
    Set the driver of 'embs_vga_0' to 'generic' and click OK.
    Core options
    The following options can be changed from the peripheral settings in XPS (accessed by double clicking the instance in your project).
    Output resolution
    The EMBS VGA core supports three display resolutions: 640x480, 800x600 and 1024x768, all running at approximately 60Hz (i.e. the image is refreshed 60 times per second).
    The resolution must be set in XPS before synthesis. In order to change the resolution of the core, the desired value must be selected and the correct clock speed for 'Pixel_Clk' set in the Clock Wizard.
    Clock speeds are:
    Pxl_Clk frequency (MHz)
    If you have the wrong combination of clock speed and resolution, your project will either fail to meet timing constraints during synthesis or the monitor will complain that the VGA signal is unsupported.
    Pixel data width in DDR
    The core can be set to read either 4 or 8 bits from memory for each pixel (i.e. two or one pixels per byte). This does not affect the image output (as each pixel always has only 3 bits of data), but does affect how data should be written to the frame buffer from the MicroBlaze.
    Keeping the core set to 8 bits-per-pixel is the easiest option, as each pixel can be individually written in DDR. If changed to 4 bits-per-pixel, two pixels (one byte) must be written at the same time (or a byte read, one pixel changed, then re-written).
    The advantages of using 4 bits-per-pixel are a smaller frame buffer and lower PLB and DDR utilisation, however the awkwardness of writing two pixels at once means that 8 bits-per-pixel is more practical unless there are speed or bandwidth concerns.
    A note on memory bandwidth
    While a VGA core set to 1024x768 resolution at 8 bits-per-pixel will function fine if it is the only part of the system accessing DDR, it uses a lot of memory and PLB bandwidth. If your system is experiencing delays accessing the PLB or DDR, or the graphics output has problems, try reducing the resolution or bits-per-pixel values.
    As a rough guide to relative PLB and memory utilisation, the following table shows the number of bytes read from DDR per second for each configuration.
    Bits per pixel
    Bytes read per second
    ChipScope debug ports
    One of the choices in the peripheral options is to include ChipScope debug ports. This adds several extra output ports to the core for monitoring internal signals using ChipScope Pro software, and should be left set to 'FALSE' unless ChipScope is being used to debug the core's operation.
    Using the EMBS VGA core
    The VGA core designates a given chunk of DDR memory as a video frame buffer. It reads the frame from this memory and draws it on the screen. The MicroBlaze can write graphics data into this memory for the VGA core to draw.
    The first location in the frame buffer corresponds to the top-left of the image, with subsequent locations moving right until the end of a line, then moving to the far left of the line below. At the end of each frame, the read location will reset to the start of the frame buffer. The size of the frame buffer varies depending on the core settings used, as shown in the following table.
    Bits per pixel
    Decimal size (bytes)
    Hex size (bytes)
    The VGA core includes two software-accessible registers:
    XPAR_EMBS_VGA_0_BASEADDR - Frame Buffer Base Address Register
    XPAR_EMBS_VGA_0_BASEADDR + 1 - Control Register
    Important: the frame buffer location must be set to a valid address in DDR before the core is enabled, otherwise graphics may not be aligned correctly on the display.
    Setting the frame buffer location
    The first register sets the location in DDR that the core reads the frame buffer from.
    For example, to set the frame buffer at the start of DDR, you can use the following C code:
    *((volatile unsigned int *) XPAR_EMBS_VGA_0_BASEADDR) = XPAR_DDR_SDRAM_MPMC_BASEADDR;
    The location of the frame buffer can be changed at any time by writing a different value to the register.
    Controlling the core
    Writing a 1 to the control register will enable graphics output from the core, and writing a 0 will disable it.
    The default state is disabled, so before the core will output graphics it must be enabled by setting the control register to 1:
    *((volatile unsigned int *) XPAR_EMBS_VGA_0_BASEADDR + 1) = 1;
    When the core is disabled it will not read any data from DDR, and it will hold the three colour output signals low and the two sync signals high.
    Pixel format
    The core uses a three-bit pixel value to produce a total of eight possible colours. This limitation is due to the way the FPGA board is wired up, with only a digital output connected to each of the red, green and blue VGA pins instead of an analogue one.
    The lower three bits of each 4- or 8-bit pixel are the values of red, green and blue, as follows.
    8-bit pixel width
    Byte 1 | Byte 2 | Byte 3 | Byte 4
    Px1 Px2 Px3 Px4
    4-bit pixel width
    Byte 1 | Byte 2 | Byte 3 | Byte 4
    Px1 Px2 Px3 Px4 Px5 Px6 Px7 Px8
    So, for example the following C code sets four pixels (starting at location 'x') to red, green, blue and white respectively, for either 4 or 8 bits-per-pixel.
    // For 8 bits-per-pixel
    *((volatile unsigned char *) x) = 0b00000100; // Red pixel
    *((volatile unsigned char *) x + 1) = 0b00000010; // Green pixel
    *((volatile unsigned char *) x + 2) = 0b00000001; // Blue pixel
    *((volatile unsigned char *) x + 3) = 0b00000111; // White pixel
    // For 4 bits-per-pixel
    *((volatile unsigned char *) x) = 0b01000010; // Red and green pixels
    *((volatile unsigned char *) x + 1) = 0b00010111; // Blue and white pixels
    The available eight colours are:
    0b0000 or 0x0: Black
    0b0001 or 0x1: Blue
    0b0010 or 0x2: Green
    0b0011 or 0x3: Cyan
    0b0100 or 0x4: Red
    0b0101 or 0x5: Magenta
    0b0110 or 0x6: Yellow
    0b0111 or 0x7: White
    Example code
    The following two examples can be used to test the EMBS VGA core.
    Example 1: Display image from UART
    The following C program can be used to copy an image received over the UART to the frame buffer. This can be useful to test that the core is set up correctly.
    To transmit a binary image (see below) over the UART, the following command can be used in a Linux terminal (make sure all other screen sessions to the serial port have been closed):
    cat image.bin > /dev/ttyS0
    Where 'image.bin' is the name of the image file downloaded below.
    The following images can be used for each resolution and pixel width setting:
    Bits per pixel
    vgatest640x4.bin {vgatest640x4.bin}
    vgatest640x8.bin {vgatest640x8.bin}
    vgatest800x4.bin {vgatest800x4.bin}
    vgatest800x8.bin {vgatest800x8.bin}
    vgatest1024x4.bin {vgatest1024x4.bin}
    vgatest1024x8.bin {vgatest1024x8.bin}
    Example 2: Generating patterns in C
    The following C program generates several test patterns and displays them using the VGA core. It will progress to the next pattern whenever it receives a byte over the UART (the easiest way to do this is to open a screen session and press any key to advance). It also prints out its current status over the UART.
    The file contains functions for 4- and 8-bit output, and allows the screen resolution to be set, so make sure the constants at the top of the file are correct before use.
    FPGA Resource Usage
    On a Spartan-3E xc3s500e (the FPGA that is on the Starter Board), ISE estimates the core usage at:
    Logic Utilisation
    Number of Slices
    Number of Slice Flip Flops
    Number of 4 input LUTs
    Number of bonded IOBs
    Number of BRAMs

    (view changes)
    3:46 am

Monday, January 23

  1. page edited ... List of FPGAs JUNIPER Rack Lab Demos Mason Pegasus ... Poindexter SMBH AnvilJ Blu…
    List of FPGAs
    JUNIPER Rack
    Lab Demos
    Xilinx Workarounds
    (view changes)
    5:38 am