|
|
 |
How to install Ubuntu 7.04 using VMware Fusion in Mac OS X
Parallels Desktop has not proven to be the perfect solution for running Linux on my MacBook as I thought from the beginning. I have the same experience as described here, plus I was never able to mount an usb stick. It seems to me that Parallels has concentrated on getting the Windows application to run smoothly and left us Linux users out in the cold. What to do? Let's try VMware Fusion instead.
About VMware
VMware is the leader in virtual infrastructure technology. Until just recently they didn't have a solution for us Mac users but when Apple moved to Intel X86 processors that changed everything.
VMware Fusion for Mac
VMware Fusion enables you to run any PC application on your Intel-based Mac. Using VMware Fusion, you can run Windows, Linux, Solaris and other PC operating systems right alongside Mac OS X, safely and easily, without the need to reboot your computer.
Download and install VMware Fusion 1.0
The first official release of VMware Fusion is now available. We will download build 51348 from here and install it on our MacBook.
Download Ubuntu 7.04
Here is the download page for Ubuntu 7.04.
Creating a virtual machine using VMware Fusion
Start VMware Fusion.
Click the New button.
 Click Continue We choose the operating system and click Continue. Select name and location. Specify disk size.
Select the disc image file and click Finish. The Ubuntu installation will start.
We go through a normal Ubuntu installation and answer a few questions before the installation starts. It takes less than 20 minutes to finish.
When the installation has finished we will shut down the system and before we reboot we will make sure that we have the CD ROM set to cdrom0.
Now we are ready to boot Ubuntu.
 Ubuntu login screen.
VMware ToolsWhen VMware Fusion really starts to shine is after we have installed the VMware tools package. To install the package the Linux OS must be up and running and we have to be logged in. We also have to make sure we have the gcc compiler installed. To install gcc use the following command: sudo apt-get install build-essential
VMware Tools installation
Follow these steps to install the VMware Tools package.
- Select from the VMware menu: Virtual Machine->Install VMware Tools
- The following files will be downloaded
 You must use the tar installer to install VMware Tools in Ubuntu Linux.- Copy VMwareTools-e.x.p-51348.tar.gz to a temporary directory
- Open a terminal window
- Unpack the file using the command tar zxfv VMwareTools-e.x.p-51348.tar.gz
- Move to the directory vmware-tools-distrib: cd vmware-tools-distrib
- Execute the perl script as root: sudo ./vmware-install.pl
Printout from installationsvenand@svenand-desktop:~/temp/vmware-tools-distrib$ sudo ./vmware-install.pl
Installing VMware Tools. This may take from several minutes to over an hour
depending upon its size.
In which directory do you want to install the binary files?
[/usr/bin]
What is the directory that contains the init directories (rc0.d/ to rc6.d/)?
[/etc]
What is the directory that contains the init scripts?
[/etc/init.d]
In which directory do you want to install the daemon files?
[/usr/sbin]
In which directory do you want to install the library files?
[/usr/lib/vmware-tools]
The path "/usr/lib/vmware-tools" does not exist currently. This program is
going to create it, including needed parent directories. Is this what you want?
[yes]
In which directory do you want to install the documentation files?
[/usr/share/doc/vmware-tools]
The path "/usr/share/doc/vmware-tools" does not exist currently. This program
is going to create it, including needed parent directories. Is this what you
want? [yes]
The installation of VMware Tools e.x.p build-51348 for Linux completed
successfully. You can decide to remove this software from your system at any
time by invoking the following command: "/usr/bin/vmware-uninstall-tools.pl".
Before running VMware Tools for the first time, you need to configure it by
invoking the following command: "/usr/bin/vmware-config-tools.pl". Do you want
this program to invoke the command for you now? [yes]
Stopping VMware Tools services in the virtual machine:
Guest operating system daemon: done
Trying to find a suitable vmmemctl module for your running kernel.
None of the pre-built vmmemctl modules for VMware Tools is suitable for your
running kernel. Do you want this program to try to build the vmmemctl module
for your system (you need to have a C compiler installed on your system)?
[no] yes
Using compiler "/usr/bin/gcc". Use environment variable CC to override.
What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.20-15-generic/build/include]
Extracting the sources of the vmmemctl module.
Building the vmmemctl module.The vmemctl module will now be built
The configuration of VMware Tools e.x.p build-51348 for Linux for this running
kernel completed successfully.
You must restart your X session before any mouse or graphics changes take
effect.
You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an X server session.
To use the vmxnet driver, restart networking using the following commands:
/etc/init.d/networking stop
rmmod pcnet32
rmmod vmxnet
depmod -a
modprobe vmxnet
/etc/init.d/networking start
If you wish to configure any experimental features, please run the following
command: "vmware-config-tools.pl --experimental".
Enjoy,
--the VMware team
After restarting our system we can start enjoying all the nice features of VMware Fusion. The network connection was disabled during VMware Tools installation but will be reconnected after a reboot of the system. Every time there is a Linux kernel update we have to rerun this process.
Comparing Parallels Desktop and VMware Fusion when running Ubuntu Linux
Here is a comparison between Parallels Desktop 3.0 and VMware Fusion 1.0 and the winner is VMware Fusion. After Parallels release of Parallels tools for Linux Parallels Desktop now have almost the same features as VMware Fusion.
| Feature | Parallels Desktop
| VMware Fusion
| Drag and drop files between Mac OS X and the virtual machine
| No | Yes
| Displaying progress bar during bootup and shutdown
| No | Yes | Copying and pasting text between Mac OS X and the virtual machine
| No | Yes | Moving the cursor between Mac OS X and the virtual machine
| Yes
| Yes
| | Support for Airport Wireless network | Yes | Yes | Mounting usb devices
| Yes (Not working in Ubuntu)
| Yes | Coherence mode
| No
| No
| Taking snapshots
| Yes
| Yes
| Snapshot manager
| Yes
| No
| Resizing the virtual machine window
| Yes
| Yes
| Price
| $79.99
| $59.99
|
Useful tips
- If you are using a bluetooth keyboard and/or mouse make sure you have disconnected the Apple Bluetooth Adapter in the VMware Settings otherwise you can not use the bluetooth keyboard or mouse.
File sharing between Ubuntu and Mac OS X
You can setup a shared folder in VMware Fusion or you can just drag and drop files.
The shared folder will show up in Ubuntu under: /mnt/hgfs/...
Network connection
I am sharing the host's internet connection (NAT). I works fine for me.
Problem log
I will report all problems found in this problem log. There can be many causes to a problem and sometimes VMware is not to blame.
| Slogan | Note
| Release | Date | Fixed | Printing to an usb printer connected to an Airport Express
| 1
| 1.0b3
| 2007-05-21 | Fixed in RC1
| Unmounting a Western Digital usb disk
| 2
| 1.0b3
| 2007-05-21 | This is an Ubuntu 7.04 problem.
| | |
| | | | | |
| | | |
Note 1. I can't see the usb printer connected to my Airport Express when trying to setup a new printer from the System->Administration->Printing setup window. See Customizing Ubuntu Linux for more information.
Running nmap shows the following ports and their usage:
==> nmap -P0 10.0.1.200
Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-21 22:16 CEST
Interesting ports on 10.0.1.200:
Not shown: 1693 filtered ports
PORT STATE SERVICE
53/tcp open domain
5000/tcp open UPnP
9100/tcp open jetdirect
10000/tcp open snet-sensor-mgmt
Nmap finished: 1 IP address (1 host up) scanned in 33.455 seconds
Note 2. When trying to unmount (eject) my Western Digital usb disk I get the follwing message and the disk will not unmount. The disk is formatted as a MacOS Extended disk.
We can use the command lsusb to list all usb device that are connected.
==> lsusb
Bus 002 Device 003: ID 1058:0901 Western Digital Technologies, Inc.
Bus 002 Device 002: ID 05ac:8501 Apple Computer, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
We can also look at the end of the /var/log/messages file using the command dmesg.
==> dmesg | grep usb
[16586.068162] usbcore: registered new interface driver usbfs
[16586.068179] usbcore: registered new interface driver hub
[16586.068203] usbcore: registered new device driver usb
[16586.069444] usb usb1: configuration #1 chosen from 1 choice
[16587.619562] usb usb2: configuration #1 chosen from 1 choice
[16587.938243] usb 2-1: new high speed USB device using ehci_hcd and address 2
[16588.075327] usb 2-1: configuration #1 chosen from 1 choice
[20057.730075] usb 2-2: new high speed USB device using ehci_hcd and address 3
[20057.881311] usb 2-2: configuration #1 chosen from 1 choice
[20058.015269] usbcore: registered new interface driver libusual
[20058.097910] usbcore: registered new interface driver usb-storage
[20058.098520] usb-storage: device found at 3
[20058.098523] usb-storage: waiting for device to settle before scanning
[20062.516934] usb-storage: device scan complete
Manually unmounting
The usb-disk can be unmounted using the following command: sudo umount "/media/My Book"
Discussion forums
Here you can discuss everything around VMware Fusion. You must register as a user before posting.
Frequently asked questions
The FAQ is found here.
More information
YouTube Videos
Top
Posted at 08:31 pm by svenand
Permalink
FPGA design from scratch. Part 25
Implementing the hardware platform
After more than 5 month of hard work we have reached the point of no return, it is time to program the FPGA. After completing hardware platform design entry, we are ready to: - Specify design constraints
- Generate the bitstream (BIT) file that represents the completed hardware platform
User Constraints File
To create the BIT file for downloading and implement the design, we must first set up our User Constraints File (UCF). As in ISE, an FPGA design implemented using EDK requires a UCF. Primarily, the UCF specifies pinouts and timing constraints. It can also control a variety of other hardware implementation features, such as the configurable electrical characteristics of our FPGA I/O signals. Setting up our User Constraints File To access the UCF file for our XPS project: - Click the Project tab in the Project Information Area of the main window and look for the UCF file under the Project Files heading.
- Double-click the UCF file to open it in the System Assembly panel.
The UCF has the same base filename as the Xilinx Microprocessor Project (XMP) file, and it must reside in the data subfolder of our project directory. 
Specifying Pin Constraints We must often provide a Location (LOC) constraint to define the FPGA pin location for each external port. To view the list of the external ports, do the following: - In the XPS main window, click the System Assembly tab.
- Select the Ports filter.
LOC constraints take the following form: NET RS232_RX_pin LOC=U4; Specifying Timing Constraints For most embedded processor designs, we need only specify the input (reference) clock period to ensure that your system meets performance requirements. In some cases, our design might contain off-chip peripherals, such as memory controllers, that have particular input and output timing requirements. We should also declare Timing IGnore (TIG) constraints on signals that are not timing critical to allow better place and route tools to optimize other timing paths. The following are typical of the basic timing constraints we must provide in our UCF file: Net sys_clk_pin PERIOD = 20000 ps;
Net sys_rst_pin TIG; The implementation directory
The result from netlist generation is stored in the implemenation directory. All the NGC files from the synthesis runs are collected here. The bitstream generation program will include all the netlist files to generate the final bitstream. We have to make sure all netlist files can be found in the implementation directory before we start the bitstream generation. When we generated the ETC_DUAL_PORT_1024x32 memory using Coregen (see part 4) the netlist file ETC_DUAL_PORT_1024x32.edn was created. This file will also be copied to the implementation directory.
Start bitstream generation
From the XPS Hardware menu we choose Generate Bitstream to start the bitstream generation.
Here is a printout from the startup of the program.
At Local date and time: Fri May 25 16:18:25 2007
make -f ETC_system.make bits started...
*********************************************
Running Xilinx Implementation tools..
*********************************************
xflow -wd implementation -p xc4vfx12ff668-10 -implement xflow.opt ETC_system.ngc
Release 9.1.02i - Xflow J.30
Copyright (c) 1995-2007 Xilinx, Inc. All rights reserved.
xflow -wd implementation -p xc4vfx12ff668-10 -implement xflow.opt ETC_system.ngc
Using Flow File: /home/svenand/root/projects/ETC/xps/implementation/fpga.flw
Using Option File(s):
/home/svenand/root/projects/ETC/xps/implementation/xflow.opt
Creating Script File ...
#----------------------------------------------#
# Starting program ngdbuild
# ngdbuild -p xc4vfx12ff668-10 -nt timestamp -bm ETC_system.bmm
"/home/svenand/root/projects/ETC/xps/implementation/ETC_system.ngc" -uc
ETC_system.ucf ETC_system.ngd
#----------------------------------------------#
Release 9.1.02i - ngdbuild J.33
Copyright (c) 1995-2007 Xilinx, Inc. All rights reserved.
Command Line: ngdbuild -p xc4vfx12ff668-10 -nt timestamp -bm ETC_system.bmm
/home/svenand/root/projects/ETC/xps/implementation/ETC_system.ngc -uc
ETC_system.ucf ETC_system.ngd
Bitstream generation flow
The Bitstream generation uses the XFLOW program to setup and run the complete program flow. XFLOW is a command line program that automates Xilinx synthesis, implementation, and simulation flows. XFLOW reads a design file as input as well as a flow file and an option file. Xilinx provides a default set of flow files that automate which Xilinx programs are run to achieve a specific design flow. For example, a flow file can specify that NGDBuild, MAP, PAR, and TRACE are run to achieve an implementation flow for an FPGA. Here is the xflow log file from our bitstream generation run.
For more information about XFLOW read the Xilinx Development System Reference Guide.
(Courtesy of Xilinx)
The NGC files are processed, along with the system constraints, through Xilinx tools (NGDBuild, MAP, PAR, and TRACE) when XPS invokes the XFlow command-line program.
Script file to run XFlow
Here is the script file that are generated when we start the bitstream generation.
#!/bin/csh -f
###########################################
# Script file to run the flow
#
###########################################
#
# Command line for ngdbuild
#
ngdbuild -p xc4vfx12ff668-10 -nt timestamp -bm ETC_system.bmm "/home/svenand/root/projects/ETC/xps/implementation/ETC_system.ngc" -uc ETC_system.ucf ETC_system.ngd
#
# Command line for map
#
map -o ETC_system_map.ncd -pr b ETC_system.ngd ETC_system.pcf
#
# Command line for par
#
par -w -ol high ETC_system_map.ncd ETC_system.ncd ETC_system.pcf
#
# Command line for post_par_trce
#
trce -e 3 -xml ETC_system.twx ETC_system.ncd ETC_system.pcf
Bitstream generation result
During the bitstream generation a number of files have been generated.
File Name
| Description | Readable | | ETC_system.bgn | Bitgen log file
| Yes | | ETC_system.bit | Bitstream download file
| No | | ETC_system.bld | Ngdbuild log file
| Yes | | ETC_system.bmm | Address map bram
| Yes | | ETC_system.drc | Drc log file
| Yes | | ETC_system.ncd | Mapping output file
| No | | ETC_system.ngc | XST synthesis output file
| No | | ETC_system.ngd | Xilinx native generic database format
| No | | ETC_system.pad | Pin definition file (spreadsheet import file) | Yes | ETC_system.par
| Placer report file
| Yes
| ETC_system.pcf
| Map report file
| Yes
| ETC_system.twr
| Trace report file (timing constraints)
| Yes
| ETC_system.twx
| Trace XML file
| Yes
| ETC_system.ucf
| User constraints file (copied from data dir)
| Yes
| | ETC_system.unroutes | Displays unrouted nets | Yes
| ETC_system_pad.cvs
| Pin definition file (spreadsheet import file)
| Yes
| ETC_system_pad.txt
| Pin definition file (text format)
| Yes
| ETC_system_map.mrp
| Mapping report file
| Yes
|
Configuration of the FPGA
Virtex-4 devices are configured by loading application-specific configuration data�the bitstream�into internal memory. Because Xilinx FPGA configuration memory is volatile, it must be configured each time it is powered-up. The bitstream is loaded into the device through special configuration pins. These configuration pins serve as the interface for a number of different configuration modes:
- Master-serial configuration mode
- Slave-serial configuration mode
- Master SelectMAP (parallel) configuration mode
- Slave SelectMAP (parallel) configuration mode
- In addition, the bitstream can be loaded through the JTAG interface
Read more in the Virtex-4 Configuration Guide.
Using the Platform Cable USB
Platform Cable USB is a high-performance download cable attaching to user hardware for the purpose of programming or configuring any of the following Xilinx devices:
- ISP Configuration PROMs
- CPLDs
- FPGAs
Platform Cable USB attaches to the USB port on a desktop or laptop PC with an off-the-shelf Hi-Speed USB A-B cable. It derives all operating power from the hub port controller. No external power supply is required. A sustained slave-serial FPGA configuration transfer rate of 24 Mb/s is possible in a Hi-Speed USB environment. Actual transfer rates can vary if bandwidth of the hub is being shared with other USB peripheral devices. Platform Cable USB attaches to target systems using a 14-conductor ribbon cable designed for high-bandwidth data transfers.
ML403 evaluation board
(Courtesy of Xilinx)
Read the ML403 user guide to find out what the numbers stand for. Here are some known issues with this board. Here is all the documentation about the ML403 board.
ML403 block diagram
(Courtesy of Xilinx)
ML403 blocks and busses
(Courtesy of Xilinx)
Installing cable drivers
In the Xilinx answers database we find answer #22648: 9.1i iMPACT - Installing Xilinx cable drivers on Linux operating system/kernel version 2.6. We will install the drivers in our Ubuntu Linux 7.04 system. To find out which version of the kernel we have installed we use the command:
==> uname -a
Linux svenand-desktop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
When I was out on the web looking for information about installing the cable drivers I came across the following link: http://www.rmdir.de/~michael/xilinx/XILINX JTAG tools on Linux without proprietary kernel modules When using Xilinx JTAG software like Impact, Chipscope and XMD on Linux, the proprietary kernel module windrvr from Jungo is needed to access the parallel- or usb-cable. As this module does not work with current linux kernel versions (> 2.6.18) a library was developed, which emulates the module in userspace and allows the tools to access the JTAG cable without the need for a proprietary kernel module.
Let's give it a try. To me it sounds like a much better solution than the one Xilinx provides. We will follow the instructions found in this README file.
- Install the libusb-dev package using the command: sudo apt-get install libusb-dev
- Download usb-driver-HEAD.tar.gz and save the file in a temp directory
- Goto the temp directory cd .../temp
- Unpack the file using the command: tar zxvf usb-driver-HEAD.tar.gz
- Goto the usb-driver directory: cd usb-driver
- Install the package build-essential (contains make) sudo apg-get install build-essential
- Build the libusb-driver.so library file using the command: make
- Copy libusb-driver.so to the /usr/lib directory: sudo cp libusb-driver.so /usr/lib/.
- To use this library we have to preload it before starting impact:
- export LD_PRELOAD=/usr/lib/libusb-driver.so (sh and bash)
- setenv LD_PRELOAD /usr/lib/libusb-driver.so (csh and tcsh)
Setting up the USB cable
- To use the device as an ordinary user, put the following line in the file /etc/udev/rules.d/50-xilinx-usb-pav.rules (or use any file name you like) ACTION=="add",BUS=="usb",SYSFS{idVendor}=="03fd",MODE="666"
- sudo gedit /etc/udev/rules.d/50-xilinx-usb-pav.rules and add the line above
- Restart udev: sudo /etc/init.d/udev restart
- Execute the command: lsusb
- Bus 002 Device 002: ID 03fd:000f Xilinx, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
- If your cable does not have the ID 03fd:0008 in the output of lsusb the initial firmware has not been loaded (loading it changes the product-ID from another value to 0008
- To load the firmware follow these steps:
- If you have no /etc/udev/rules.d/xusbdfwu.rules file, copy it from /ISE_install_dir/bin/lin/xusbdfwu.rules
- Install the package fxload using the command: sudo apt-get install fxload
- Copy the file /ISE_install_dir/bin/lin/xusbdfwu.hex to /usr/share/xusbdfwu.hex
- Restart udev: sudo /etc/init.d/udev restart
- Execute the command: lsusb
- Bus 002 Device 001: ID 0000:0000
Bus 001 Device 003: ID 0e0f:0002
Bus 001 Device 002: ID 03fd:0008 Xilinx, Inc.
Bus 001 Device 001: ID 0000:0000
- The ID is 03fd:0008
- Replug the usb cable
- Make sure the green status light is on. The USB cable interface must be connected during VMware Fusion Ubuntu bootup. WMware will detect the USB cable interface and automatically connect it.
Permission denied. Change owner
Can't open /dev/parport0: Permission denied
If this message is displayed in the terminal when starting iMPACT, we have to change the owner of this file from root to the current user. Like this: sudo chown svenand /dev/parport0. This has to repeated every time after we have booted the Linux OS.
Unlocking the cable interface
Use the following commands to unlock the cable interface if needed:
==> impact -batch
> setMode -bscan
> cleancablelock
> quit
iMPACT FPGA configuration tool
iMPACT allows designers to easily perform device configuration and programming either as a batch operation or through a convenient graphical user interface. iMPACT is a full featured software tool used for configuration and programming of all Xilinx PLDs (FPGAs and CPLDs) and PROMs. iMPACT features a series of design wizards that easily guide the user through each step of the configuration process.
Starting iMPACT
==> impact & (xilinx_install_dir/bin/lin/impact)
 We will create a new project in iMPACT and give it a name ETC_system.icf
We will use Boundary-Scan (JTAG) to configure the FPGA.
When we click Finish the program connects to our evaluation board. Here is the printout from iMPACT:
Connecting to cable (Usb Port - USB21).
Checking cable driver.
File version of /home/svenand/cad/xilinx91i/bin/lin/xusbdfwu.hex = 1025(dec), 0x0401.
File version of /usr/share/xusbdfwu.hex = 1025(dec), 0x0401.
libusb-driver.so version: 2007-05-27 00:37:02.
Cable PID = 0008.
Max current requested during enumeration is 280 mA.
Cable Type = 3, Revision = 0.
Cable Type = 0x0605.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1025.
CPLD file version = 0012h.
CPLD version = 0006h.
WARNING:iMPACT:2356 - Platform Cable USB firmware must be updated. This operation may take up to 10 minutes on a USB 2.0 port or up to 30 minutes on a USB 1.1 port.
Please do not stop the process or disconnect the cable prior to completion. The cable
STATUS LED will be RED for the duration of the update process.
Updating the cable firmware...
PROGRESS_START - Starting Operation.
Firmware update completed successfully.
PROGRESS_END - End Operation.
Elapsed time = 1943 sec.
Attempting to identify devices in the boundary-scan chain configuration...// *** BATCH CMD : Identify
PROGRESS_START - Starting Operation.
Identifying chain contents ....'1': : Manufacturer's ID =Xilinx xc95144xl, Version : 5
INFO:iMPACT:1777 -
Reading /home/svenand/cad/xilinx91i/xc9500xl/data/xc95144xl.bsd...
INFO:iMPACT:501 - '1': Added Device xc95144xl successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'2': : Manufacturer's ID =Xilinx xc4vfx12, Version : 2
INFO:iMPACT:1777 -
Reading /home/svenand/cad/xilinx91i/virtex4/data/xc4vfx12.bsd...
INFO:iMPACT:501 - '1': Added Device xc4vfx12 successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'3': : Manufacturer's ID =Xilinx xcf32p, Version : 15
INFO:iMPACT:1777 -
Reading /home/svenand/cad/xilinx91i/xcfp/data/xcf32p.bsd...
INFO:iMPACT:501 - '1': Added Device xcf32p successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'4': : Manufacturer's ID =Xilinx xccace, Version : 0
INFO:iMPACT:1777 -
Reading /home/svenand/cad/xilinx91i/acecf/data/xccace.bsd...
INFO:iMPACT:501 - '1': Added Device xccace successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
done.
PROGRESS_END - End Operation.
Elapsed time = 4 sec.
// *** BATCH CMD : identifyMPM
Congratulations! We have a working cable connection to our evaluation board. Thanks Michael, you saved our day.
Top Next Previous
Posted at 11:34 am by svenand
Permalink
FPGA design from scratch. Part 24
System simulations
System simulation is an effective method for verifying that software drivers are compatible with the hardware. Using a simulator for that purpose offers several advantages over GDB. For example, no physical link to the hardware is required and internal system signals may be easily monitored. In addition, the hardware does not need to be run through the implementation tools to run a system simulation, allowing the quick analysis of the effects of changes to the code or the generics. The flow presented here can easily be modified to support structural and timing simulation.
The EDK System Simulation guide presents Xilinx idea about system simulations. They use Modelsim and the setup is to complicated for my taste. We will stay with NCSIM and the simulation strategy we formulated in part 23. We will specify testcases to verify all interfaces in our system. Each testcase will include a c-program to access the peripheral and it's registers. Here is our system.
DDR SDRAM controller
The DDR SDRAM controller (opb_ddr) connects the DDR SDRAM to the OPB. The DDR SDRAM is a Micron MT46V16M16P-6T.
Features
- OPB interface
- Performs device initialization sequence upon power-up and reset conditions for ~200uS. Provides a parameter to adjust this time for simulation purposes only.
- Performs auto-refresh cycles
- Supports CAS latencies of 2 or 3 set by a design parameter
- Supports 16, 32 and 64 bits DDR data widths set by a designparameter
- Supports indeterminate burst length
- Provides big-endian connections to memory devices
- Supports multiple (up to 4) DDR memory banks.
DDR SDRAM Initialization
Prior to normal operation, DDR SDRAMs must be powered up and initialized in a predefined manner. Operational procedures, other than those specified, may result in undefined operation. To ensure device operation, the DRAM must be initialized as described in the following steps:
- Simultaneously apply power to VDD and VDDQ
- Apply VREF and then VTT power. VTT must be applied after VDDQ to avoid device latchup, which may cause permanent damage to the device. Exept for CKE, inputs are not recognized as valid until after VREF is applied.
- Assert and hold CKE at a LVCMOS logic LOW. Maintaining an LVCMOS LOW level on CKE during power-up is required to ensure that the DQ and DQS outputs will be in the High-Z state, where they will remain until driven in normal operation (by a read access).
- Provide stable clock signals.
- Wait at least 200μs.
- Bring CKE HIGH, and provide at least one NOP or DESELECT command. At this point, the CKE input changes from a LVCMOS input to a SSTL_2 input only and will remain a SSTL_2 input unless a power cycle occurs.
- For more information about the initialization see the DDR SDRAM data sheet.
Setting the initialization time
The OPB DDR block will insert a 200us delay before it asserts DDR_init_done (see waveform plot) to allow time for DDR SDRAM initialization to happen.
For simulation purpose only we can change that time by editing the wrapper file ddr_sdram_64mx32_wrapper.vhd.
Look for the line: C_SIM_INIT_TIME_PS => 200000000 and change it to C_SIM_INIT_TIME_PS => 20000 (20ns).
C program
This program will write and read three addresses in the DDR SDRAM.
int main()
#define poke(addr,val) (*(unsigned char*) (addr) = (val))
#define pokew(addr,val) (*(unsigned*) (addr) = (val))
#define peek(addr) (*(unsigned char*) (addr))
#define peekw(addr) (*(unsigned*) (addr))
{
unsigned char byte_of_data;
unsigned word_of_data;
pokew(0x44000000,0xffffffff);
pokew(0x46000004,0xaaaaaaaa);
pokew(0x47fffffc,0x55555555);
word_of_data = peekw(0x44000000);
word_of_data = peekw(0x46000004);
word_of_data = peekw(0x47fffffc);
return 0;
}
Assembly code
0: 3021fff0 addik r1, r1, -16
4: fa61000c swi r19, r1, 12
8: 12610000 addk r19, r1, r0
c: 3060ffff addik r3, r0, -1
10: b0004400 imm 17408
14: f8600000 swi r3, r0, 0
18: b000aaaa imm -21846
1c: 3060aaaa addik r3, r0, -21846
20: b0004600 imm 17920
24: f8600004 swi r3, r0, 4
28: b0005555 imm 21845
2c: 30605555 addik r3, r0, 21845
30: b00047ff imm 18431
34: f860fffc swi r3, r0, -4
38: b0004400 imm 17408
3c: e8600000 lwi r3, r0, 0
40: f8730008 swi r3, r19, 8
44: b0004600 imm 17920
48: e8600004 lwi r3, r0, 4
4c: f8730008 swi r3, r19, 8
50: b00047ff imm 18431
54: e860fffc lwi r3, r0, -4
58: f8730008 swi r3, r19, 8
5c: 10600000 addk r3, r0, r0
60: 10330000 addk r1, r19, r0
64: ea61000c lwi r19, r1, 12
68: 30210010 addik r1, r1, 16
6c: b60f0008 rtsd r15, 8
70: 80000000 or r0, r0, r0
Simulation result
LED displays and push buttons
The LED displays (LED_Positions and LEDs_4Bit) and the push buttons are connected to the general purpose input/outputs and through the OPB General Purpose Input/Output (GPIO) controller to the OPB bus.
Features
- OPB v2.0 bus interface with byte-enable support
- Configurable as single or dual GPIO channel(s)
- Number of GPIO bits configurable from 1 to 32 bits
- Each GPIO bit dynamically programmable as input or output
- Can be configured as inputs-only on a per channel basis to reduce resource utilization
- Ports for both 3-state and non 3-state connections
- Independent reset values for each bit of all registers
- Optional interrupt request generation
Address ranges
0x40020000-0x4002ffff LEDs_Positions
0x40040000-0x4004ffff LEDs_4Bit
0x40000000-0x4000ffff Push_Buttons_Position
OPB GPIO Registers
There are four internal registers in the OPB GPIO design as shown in the table. These registers are implemented in the GPIO_CORE interface module. The memory map of the OPB GPIO design is determined by setting the C_BASEADDR parameter. The internal registers of the OPB GPIO are at a fixed offset from the base address.
Register Name
| Description | OPB Address
| Access | | GPIO_DATA | Channel 1 OPB GPIO Data Register | C_BASEADDR + 0x00 | Read/Write | | GPIO_TRI | Channel 1 OPB GPIO 3-state Register | C_BASEADDR + 0x04 | Read/Write | GPIO2_DATA
| Channel 2 OPB GPIO Data register
| C_BASEADDR + 0x08 | Read/Write | | GPIO2_TRI | Channel 2 OPB GPIO 3-state Register
| C_BASEADDR + 0x0C
| Read/Write | C program
int main()
#define poke(addr,val) (*(unsigned char*) (addr) = (val))
#define pokew(addr,val) (*(unsigned*) (addr) = (val))
#define peek(addr) (*(unsigned char*) (addr))
#define peekw(addr) (*(unsigned*) (addr))
{
unsigned char byte_of_data;
unsigned word_of_data;
// Write to LEDs
pokew(0x40020000,0xffffffff);
pokew(0x40020004,0x00000000);
pokew(0x40020008,0x33333333);
pokew(0x4002000c,0x00000000);
pokew(0x40040000,0x55555555);
pokew(0x40040004,0x00000000);
pokew(0x40040008,0x11111111);
pokew(0x4004000c,0x00000000);
// Read push buttons
pokew(0x40000004,0xffffffff);
word_of_data = peek(0x40000000);
pokew(0x4000000c,0xffffffff);
word_of_data = peek(0x40000008);
return 0;
Assembly code
0: 3021fff0 addik r1, r1, -16
4: fa61000c swi r19, r1, 12
8: 12610000 addk r19, r1, r0
c: 3060ffff addik r3, r0, -1
10: b0004002 imm 16386
14: f8600000 swi r3, r0, 0
18: b0004002 imm 16386
1c: f8000004 swi r0, r0, 4
20: b0003333 imm 13107
24: 30603333 addik r3, r0, 13107
28: b0004002 imm 16386
2c: f8600008 swi r3, r0, 8
30: b0004002 imm 16386
34: f800000c swi r0, r0, 12
38: b0005555 imm 21845
3c: 30605555 addik r3, r0, 21845
40: b0004004 imm 16388
44: f8600000 swi r3, r0, 0
48: b0004004 imm 16388
4c: f8000004 swi r0, r0, 4
50: b0001111 imm 4369
54: 30601111 addik r3, r0, 4369
58: b0004004 imm 16388
5c: f8600008 swi r3, r0, 8
60: b0004004 imm 16388
64: f800000c swi r0, r0, 12
68: 3060ffff addik r3, r0, -1
6c: b0004000 imm 16384
70: f8600004 swi r3, r0, 4
74: b0004000 imm 16384
78: e8600000 lwi r3, r0, 0
7c: f8730008 swi r3, r19, 8
80: 3060ffff addik r3, r0, -1
84: b0004000 imm 16384
88: f860000c swi r3, r0, 12
8c: b0004000 imm 16384
90: e8600008 lwi r3, r0, 8
94: f8730008 swi r3, r19, 8
98: 10600000 addk r3, r0, r0
9c: 10330000 addk r1, r19, r0
a0: ea61000c lwi r19, r1, 12
a4: 30210010 addik r1, r1, 16
a8: b60f0008 rtsd r15, 8
ac: 80000000 or r0, r0, r0
Simulation result
Embedded Test Controller
The Embedded Test Controller (ETC) is a custom IP that implements a 1149.1 complient JTAG tester. It can run JTAG test sequences on the board and/or the complete system during startup and normal operation.
ETC address map
Register/ Memory Name
| Size | Access | Address | | Control | 32 | Write | 0x42a10000 | Status
| 32 | Read | 0x42a10004 | | Execute | 32 | Write | 0x42a10008 | | Debug | 32 | Read | 0x42a1000c
| Test program RAM
| 1Kx32 | Write | 0x42a08000 | Test result RAM
| 1Kx32 | Read | 0x42a09000 | C programint main()
#define poke(addr,val) (*(unsigned char*) (addr) = (val))
#define pokew(addr,val) (*(unsigned*) (addr) = (val))
#define peek(addr) (*(unsigned char*) (addr))
#define peekw(addr) (*(unsigned*) (addr))
{
unsigned char byte_of_data;
unsigned word_of_data;
// Write testprogram
pokew(0x42a08000,0x800000f1);
pokew(0x42a08004,0x80000000);
pokew(0x42a08008,0x800000f2);
pokew(0x42a0800c,0x8000000c);
// Write control register in ETC
// Enable TCK clock
pokew(0x42a10000,0x000000a0);
// Read status register in ETC
word_of_data = peekw(0x42a10004);
// Read debug register in ETC
word_of_data = peekw(0x42a1000c);
// Start test program
pokew(0x42a10008,0x00000001);
Simulation result
Debugging the On-chip Peripheral Bus
When I started to debug the ETC IP I quickly found out that my implementation and the Xilinx implementations of the OPB interface differed.
Specifications
Here is the IBM On-Chip Peripheral Bus Architecture Specification and here is the Xilinx implementation
MicroBlaze write cycle.
Let's take a closer look at the OPB. Here are two plots showing all signals in the Xilinx implemantation of the OPB interface.
Here are all the input signals to the mb_opb block.
Here are all the output signals from the mb_opb block.
OPB signal description
| Signal | Description | Width
| Used in ETC
| | OPB_ABus | Address bus
| 32
| Yes
| | OPB_BE | Data byte enable
| 4
| Yes
| | OPB_beAck | OPB byte enable acknowledge
| 1
| No | | OPB_beXfer | OPB byte enable transfer
| 1
| No | OPB_busLock
| OPB bus arbitration lock | 1
| No | | OPB_Dbus | OPB Ddata bus
| 32
| Yes
| | OPB_dwAck | OPB doubleword acknowledge | 1
| No | | OPB_dwXfer | OPB doubleword transfer
| 1
| No | | OPB_errAck | OPB error acknowledge | 1
| Yes, always = 0
| OPB_fwAck
| OPB fullword acknowledge
| 1
| Yes, always = 0
| OPB_fwXfer
| OPB fullword transfer
| 1
| No
| OPB_hwAck
| OPB halfword acknowledge
| 1
| No
| OPB_hwXfer
| OPB halfword transfer
| 1
| No
| OPB_MGrant
| OPB master bus grant
| 2
| No
| OPB_MRequest
| OPB Master bus request
| 2
| No
| OPB_pendReq
| OPB pending master request
| 2
| No
| OPB_rdDbus
| OPB read data bus
| 32
| No
| OPB_retry
| OPB bus cycle retry
| 1
| Yes, always = 0
| OPB_RNW
| OPB read not write (write=L)
| 1
| Yes
| OPB_Rst
| OPB reset
| 1
| Yes
| OPB_select
| OPB select
| 1
| Yes
| OP_seqAddr
| OPB sequential address
| 1
| No
| OPB_timeout
| OPB timeout error
| 1
| No
| OPB_toutSup
| OPB timeout suppress
| 1
| Yes, always = 0
| OPB_wrDbus
| OPB write data bus
| 32
| No
| OPB_xferAck
| OPB transfer acknowledge
| 1
| Yes
|
Final result
It took me a couple of days to sort out all issues around the ETC OPB interface. Here is what I found out. Right or wrong?
- The read and write cycles can be two or more clock cycles long. The OPB interface can decide how long the read and write cycles will be by asserting the OPB_xferAck in the last clock cycle. I am using 3 clock cycles in the ETC OPB interface.
- The fullword and halfword control signals are not implemented in the Xilinx version of OPB. Use the signal OPB_BE instead. OPB_BE = 4'b1111 enable all four bytes when reading and writing 32 bit words.
- Always keep the read data bus low when no valid read cycle is taking place. Read data busses from all peripherals are or'ed together in the mb_opb block and only one peripheral at a time can drive the bus high. Important !!!
- You don't have to implement the signals OPB_errAck, OPB_toutSup and OPB_retry. I have set them all low.
Here is my OPB interface to the ETC block. Comments and improvements are welcomed.
Top Next Previous
Posted at 08:55 pm by svenand
Permalink
Fixing a HyperTerminal in Mac OS X
HyperTerminal is a communications program bundled with multiple versions of the Microsoft Windows operating system. It is a tool used when connecting to other computers, bulletin board systems (BBSs), and a host of other Internet-related services. HyperTerminal is designed to emulate various types of text terminal. It can be configured to make a connection through a modem or directly over a serial port. Various serial parameters are configurable such as: HyperTerminal supports various terminal protocols such as VT100 (ANSI X3.64), as well as various forms of file transfer protocols such as ASCII, XMODEM and YMODEM. The screen program A good replacement for HyperTerminal in Mac OS X is the unix program /usr/bin/screen.
NAME
screen - screen manager with VT100/ANSI terminal emulation
SYNOPSIS
screen [ -options ] [ cmd [ args ] ]
screen -r [[pid.]tty[.host]]
screen -r sessionowner/[[pid.]tty[.host]]
DESCRIPTION
Screen is a full-screen window manager that multiplexes a physical ter-
minal between several processes (typically interactive shells). Each
virtual terminal provides the functions of a DEC VT100 terminal and, in
addition, several control functions from the ISO 6429 (ECMA 48, ANSI
X3.64) and ISO 2022 standards (e.g. insert/delete line and support for
multiple character sets). There is a scrollback history buffer for
each virtual terminal and a copy-and-paste mechanism that allows moving
text regions between windows. We will use the screen program to communicate with the Xilinx evaluation board ML403. Here is the setup. Connecting the MacBook to the ML403 evaluation board
We will us the Keyspan usb to serial converter USA-19HS. - Download the driver software from Keyspan.
- Install the driver and restart the computer.
- Open a terminal
- Start the screen program in the terminal using the command: screen /dev/tty.USA19H1b1P1.1
- If you type screen /dev/tty.U and use the file completion (tab) you will find the right name.
- Connect the usb contact to the usb port on your Mac and connect the serial connector to the evaluation board where is says Uart Host.
- Turn on the power to the ML403 board and press the System ACE reset button.
- This is what the screen window looks like.
 We are ready to run the demo programs that come with the ML403 board.
More information Use screen as serial terminal emulator (MacOSXHints)
Posted at 01:52 pm by svenand
Permalink
FPGA design from scratch. Part 23
Simulating program execution in the MicroBlaze processor
The best way to verify an embedded system incorporating a microprocessor is to simulate the program execution. The testbench will be very simple, we only have to provide the system clock, load a program into the instruction memory, generate a reset and off we go. We will use this verification strategy when we build our simulation testbench.
Verification strategy
When we build a system of proven IP blocks we are not going to verify the operation of these IP blocks. Instead we will verify the connectivity, are all our peripherals connected and can we read and write to registers in the IPs. For this task a program running in the MicroBlaze processor is a perfect solution. We can observe all busses and we can use the Simvision waveform viewer to watch signals and timing relations. In theory this is very simple but in front of your computer it is a lot of work to set everything up. Let's go through to whole process.
Verification flow
- Write a small c-program or use machine code from start.
- Compile the program using gcc and generate machine code in ASCII format.
- Load the machine code to the MicroBlaze instruction memory.
- Start the simulation and generate system clock and a reset.
- The MicroBlaze processor will execute the program and write the result to the data memory.
- Read the result and compare it to expected data.
Generating a new MicroBlaze instruction and data memory modelThe VHDL model generated by platgen (see Part 17) is not suitable for our simulation setup. We must be able to load and dump data to/from the memory array in the simulation model. For that reason we need a behavioral model. We will use Coregen to generate one (see Part 4 for more information on using Coregen). The generated memory model is a dual-port memory 1024x32 with enable and reset inputs and byte write enabled. We also have to modify the wrapper file to support our new memory model.
Writing a simple program
Our first program we will code in 32 bit instruction words like this:
$ADDRESSFMT H
$DATAFMT B
# 1111111111222222222233
# 01234567890123456789012345678901
#
# MSRSET
0/10010100100000000000000000000000;
# SW store word
1/11011000100000100001101010101010;
2/10010100100000000000000000000000;
3/11011000100000100001101010101010;
4/10010100100000000000000000000000;
5/11011000100000100001101010101010;
The program is saved in a file called microblaze_instruction_mem.def.
Loading the program
The following NCSIM tcl command will be used to load the program: memory -load memory_instance_name -file memory_content
The instance name in our example has the following format:
ETC_SYSTEM_TEST.ETC_system_test:lmb_bram:lmb_bram_rtl:U0:$PROCESS_008:memory
The '.' is the verilog scope delimiter and the ':' is the VHDL delimiter. The $ sign is escaped using '' .
Running an NCSIM simulation
Here is the NCSIM control file generated from Mongoose:
/* NCSIM simulation control file generated from Mongoose 15.5 */
/* Generation date : 2007-04-30 */
/* Generation time : 14:15:58 */
-cdslib /home/svenand/root/projects/ETC/verification/simSetup/ncsim/cds_system.lib
-hdlvar /home/svenand/root/projects/ETC/verification/simSetup/ncsim/hdl.var
-logfile /home/svenand/root/projects/ETC/verification/log/verilog.log
-messages
-input /home/svenand/root/projects/ETC/verification/mongoose/input/ncsim_tcl.def
ETC_SYSTEM_TEST
Simulation result
The program is executing. The MicroBlaze processor is reading instructions from the instruction memory. In the Simvision plot you can also see the content of the instruction memory displayed.
Write a simple c-program
Let's write a simple c-program adding two integers and storing the result.
int main()
{
int number1;
int number2;
int number3;
number1 = 824;
number2 = 200;
number3 = number1 + number2;
return 0;
}
Compile and build the program inside SDK
Here is the log file from the build process:
**** Full rebuild of configuration Debug for project ETC_system_program ****
make clean all
rm -rf main.o main.d ETC_system_program.elf
mb-gcc -mno-xl-soft-mul -mxl-pattern-compare -mcpu=v6.00.b -I../../microblaze_0_sw_platform/microblaze_0/include -c -xl-mode-executable -g -O0 -omain.o ../main.c
Building target: ETC_system_program.elf
mb-gcc -o ETC_system_program.elf main.o -mno-xl-soft-mul -mxl-pattern-compare -mcpu=v6.00.b -L../../microblaze_0_sw_platform/microblaze_0/lib -xl-mode-executable
Finished building: ETC_system_program.elf
************** Validating ELF File **************
Validating ELF Section Addresses with Hardware Address Map...
elfcheck -mhs /home/svenand/root/projects/ETC/xps/ETC_system.mhs -p xc4vfx12ff668-10 -xmpdir /home/svenand/root/projects/ETC/xps -pe microblaze_0 ETC_system_program.elf
elfcheck
Xilinx EDK 9.1.01 Build EDK_J_SP1.3
Copyright (c) 1995-2007 Xilinx, Inc. All rights reserved.
Command Line: elfcheck -mhs /home/svenand/root/projects/ETC/xps/ETC_system.mhs
-p xc4vfx12ff668-10 -xmpdir /home/svenand/root/projects/ETC/xps -pe microblaze_0
ETC_system_program.elf
ELF file : ETC_system_program.elf
Populating list of memories for processor microblaze_0...
Analyzing file ETC_system_program.elf...
Elfcheck on ETC_system_program.elf completed successfully!
************** Determining Size of ELF File **************
mb-size ETC_system_program.elf
text data bss dec hex filename
748 48 1040 1836 72c ETC_system_program.elf
Build complete for project ETC_system_program
Generate assembly code and hex machine code
We use the following command to generate hexadecimal machine code: mb-objdump -d main.o
Here is the result:
==> mb-objdump -d main.o
main.o: file format elf32-microblaze
Disassembly of section .text:
00000000 <main>:
0: 3021ffec addik r1, r1, -20
4: fa610010 swi r19, r1, 16
8: 12610000 addk r19, r1, r0
c: 30600338 addik r3, r0, 824
10: f8730004 swi r3, r19, 4
14: 306000c8 addik r3, r0, 200
18: f8730008 swi r3, r19, 8
1c: e8930004 lwi r4, r19, 4
20: e8730008 lwi r3, r19, 8
24: 10641800 addk r3, r4, r3
28: f873000c swi r3, r19, 12
2c: 10600000 addk r3, r0, r0
30: 10330000 addk r1, r19, r0
34: ea610010 lwi r19, r1, 16
38: 30210014 addik r1, r1, 20
3c: b60f0008 rtsd r15, 8
40: 80000000 or r0, r0, r0
Make a NCSIM memory load file
We take the hex code and make a NCSIM memory load file. This script will fix everything in one run:
mb-objdump -d main.o | cut -f2 | sed -n '7,$ p' | cleanup > microblaze_instruction_mem.def
The script cleanup removes trailing spaces using the following command : sed 's/[ \t]*$//'
3021ffec
fa610010
12610000
30600338
f8730004
306000c8
f8730008
e8930004
e8730008
10641800
f873000c
10600000
10330000
ea610010
30210014
b60f0008
80000000
If we don't specify the addresses in the memory image file we have to add an start address and end address to the memory load command. The following NCSIM tcl command will be used to load the program: memory -load memory_instance_name -file memory_content -0 -1000
Running a simulation
Here is the result from the simulation. The result (=1024) is stored in memory[3] location.
Reading and writing registers in peripherals
We will start by using simple peek and poke commands to access the registers in the peripherals. First let's take a look at the address map which can be found in the ETC_system.log file.
MicroBlaze address map
(0000000000-0x00001fff) dlmb_cntlr dlmb
(0000000000-0x00001fff) ilmb_cntlr ilmb
(0x40000000-0x4000ffff) Push_Buttons_Position mb_opb
(0x40020000-0x4002ffff) LEDs_Positions mb_opb
(0x40040000-0x4004ffff) LEDs_4Bit mb_opb
(0x40600000-0x4060ffff) RS232_Uart mb_opb
(0x41400000-0x4140ffff) debug_module mb_opb
(0x42a08000-0x42a08fff) ETC_0 mb_opb
(0x42a09000-0x42a09fff) ETC_0 mb_opb
(0x44000000-0x47ffffff) DDR_SDRAM_64Mx32 mb_opb
(0x71a00000-0x71a0000f) ETC_0 mb_opb
C-program to access registers in ETC
Here is a simple program that will do the job.
int main()
#define poke(addr,val) (*(unsigned char*) (addr) = (val))
#define pokew(addr,val) (*(unsigned*) (addr) = (val))
#define peek(addr) (*(unsigned char*) (addr))
#define peekw(addr) (*(unsigned*) (addr))
{
unsigned char byte_of_data;
unsigned word_of_data;
pokew(0x71a00000,0xffffffff);
pokew(0x71a00000,0xaaaaaaaa);
pokew(0x71a00000,0x55555555);
return 0;
}
Here is the assembly code.
0: 3021fff0 addik r1, r1, -16
4: fa61000c swi r19, r1, 12
8: 12610000 addk r19, r1, r0
c: 3060ffff addik r3, r0, -1
10: b00071a0 imm 29088
14: f8600000 swi r3, r0, 0
18: b000aaaa imm -21846
1c: 3060aaaa addik r3, r0, -21846
20: b00071a0 imm 29088
24: f8600000 swi r3, r0, 0
28: b0005555 imm 21845
2c: 30605555 addik r3, r0, 21845
30: b00071a0 imm 29088
34: f8600000 swi r3, r0, 0
38: 10600000 addk r3, r0, r0
3c: 10330000 addk r1, r19, r0
40: ea61000c lwi r19, r1, 12
44: 30210010 addik r1, r1, 16
48: b60f0008 rtsd r15, 8
4c: 80000000 or r0, r0, r0
From this Simvision plot we can see the address and data appear on the OPB bus.
Top Next Previous
Posted at 08:50 pm by svenand
Permalink
FPGA design from scratch. Part 22
Using the XPS Software Development Kit
It is time to start writing some small programs to be used in our simulations. We will use the Platform Studio Software Devlopment Kit (SDK) to help us out with this task.
The Platform Studio Software Development Kit (SDK) was designed to facilitate the development of embedded software application projects. SDK has its own GUI and is based on the Eclipse open-source tool suite. The Platform Studio SDK is a complementary program to XPS; that is, from SDK, you can develop the software that the peripherals and processor(s) elements connected in XPS use.
You must create an SDK project for each software application. The project directory contains your C/C++ source files, executable output file, and associated utility files, such as the make files used to build the project. Each SDK project directory is typically located under the XPS project directory tree for the embedded system that the application targets. Each SDK project produces just one executable file, <project_name>.elf. Therefore, you may have more than one SDK project targeting a single XPS embedded system.
Software development flow
(Courtesy of Xilinx)
GNU Compiler Collection
The GNU Compiler Collection (usually shortened to GCC) is a set of programming language compilers produced by the GNU Project.
Executable and Linkage Format file
In computing, the Executable and Linking Format (ELF, formerly called Extensible Linking Format) is a common standard file format for executables, object code, shared libraries, and core dumps
Missing gmake
Warning, on a Debian/Ubuntu machine, you will not have a binary called gmake, but "make" is already "gmake". You need to add a proper symlink: sudo ln -s /usr/bin/make /usr/bin/gmake Running SDK We will start SDK from inside the Xilinx Platform Studio. Read the EDK Concepts, Tools, and Techniques Chapter 6, The Software Platform and SDK for more information on how to write embedded software applications. To start SDK directly from the terminal use the command: xps_sdk &
==> xps & 
Before we start SDK let's take a look at the software platform settings. From the Software menu select Software Platform Settings.
Starting SDK
From the Software menu select Launch Platform Studio SDK to open SDK.
Let's read the Getting started with the Xilinx Platform Studio SDK before we continue. To display the guide in your web browser click the Getting Started in the Welcome window. We will launch the Application Wizard to help us setup our first software project.
Xilinx Tools->Launch Application Wizard and select Import XPS Application Projects.
Click Next.
Mark the application TestApp_Memory and click Finish.
Creating a new C application project
We give the project a name and then click Finish.  The wizard starts working and after a few seconds the result is displayed. We are ready to write out first c-program.
A new directory called SDK_projects has been created with two projects in it. 
Top Next Previous
Posted at 02:21 pm by svenand
Permalink
FPGA design from scratch. Part 21
Debugging IP blocks
All Xilinx IP blocks are protected, meaning we don't have access to the RTL code and we can't probe internal nodes during a simulation. This makes debugging complicated. We can only observe input and output signals to the IP block and we have no idea what is going on inside the block.
The reset logic
The OPB_V20 design includes several sources for bus reset. A power-on reset circuit asserts the OPB_Rst for 16 clock cycles anytime the FPGA has completed configuration. External resets that occur during the 16 clock reset time are ignored. After the 16-clock reset has completed, external resets can be applied to the OPB_V20 reset signals. The external resets are: SYS_Rst (can be configured as high-true or low-true), WDT_Rst, and Debug_SYS_Rst. SYS_Rst is the main user reset for the OPB and can be connected to internal logic or an external signal or switch.
WDT_Rst can be connected to the reset output of a Watchdog Timer to allow for OPB resets in the event of a watchdog time-out. Debug_SYS_Rst can be connected to the reset output of a debug peripheral, such as the JTAG UART, so that the debugger can remotely reset the OPB. SYS_Rst, WDT_Rst, and Debug_SYS_Rst are synchronized to the OPB_Clk in the OPB_V20, but the width of these signals is otherwise unaltered.
Reset signal polarity
What is the polarity of the reset signal. Here is the specification for the opb_v20 setup, taken from the ETC_system.mhs file.
BEGIN opb_v20
PARAMETER INSTANCE = mb_opb
PARAMETER HW_VER = 1.10.c
PARAMETER C_EXT_RESET_HIGH = 0
PORT SYS_Rst = sys_rst_s
PORT OPB_Clk = sys_clk_s
END
The PARAMETER C_EXT_RESET_HIGH = 0 specification means that the reset signal is active low.
The system reset SYS_rst goes to the opb_mb block and should propagate through this block and generate the inverted OPB_rst signal.
MicroBlaze reset
When a Reset (OPB_rst) or Debug_Rst occurs, MicroBlaze will flush the pipeline and start fetching instructions from the reset vector (address 0x0). Both external reset signals are active high, and should be asserted for a minimum of 16 cycles.
All output signals are defined from the opb_mb block and we have the reset signal to the MicroBlaze processor coming through. We are ready for more advanced simulations. First we have to study how the MicroBlaze processor operates. Here is the MicroBlaze Processor Reference Guide.
Top Next Previous
Posted at 12:47 pm by svenand
Permalink
FPGA design from scratch. Part 20
Running our first simulation
Our first testcase will be a simple one. We will start the system clock running at 100MHz. After a few clock cycles we will assert the system reset and watch what happens. Here is the testcase.
We are ready to start.
- Testcase FirstTest.tc selected
- Waveform generation enabled. Dump sst/wlf
- NCSIM used
- Compile/elaborate/simulate in one run selected
Here is the result.
The simulation stops after 110ns displaying the following error message: Input Error : RST on instance * must be asserted for 3 CLKIN clock cycles. It looks to me like the DCM is missing a reset signal. Here starts the debugging phase. Up to now it has been "klipp och klistra" (Swedish for cut and glue) work. Now starts the real engineering work.
Let's open the Simvision waveform viewer by clicking the Simvision button in the terminal window, find the dcm_0 and dcm_1 in the design browser, select all signals and open the waveform viewer.
The dcm_1 block has no input clock. Let's dig into the problem. We will use the Simvision Schematic Tracer to help us find our way around in the design. Here is a view of the complete system.
Here is the dcm_1 block in full view.
Here is the explanation, the ddr_feedback clock is missing. We have to add one more clock generator in our testbench.
always
begin
#DDR_CLK_ClockStart DDR_CLK_FB = 1;
#DDR_CLK_ClockWidth DDR_CLK_FB = 0;
#(DDR_CLK_ClockPeriod-DDR_CLK_ClockStart-DDR_CLK_ClockWidth);
end
We will also add the DDR SDRAM to our simulation model.
Adding the DDR SDRAM
If we take a look at the Xilinx evaluation board we find two Micron DDR SDRAM 46V16M16 organized as 16Mx32. To download a Verilog model of this SDRAM we will go the Micron web page.
Before we connect the DDR SDRAM to the ETC system we will study the SDRAM interface already implemented and try to understand how it works. Here is the Xilinx document describing the interface. This table shows all the external signals in the DDR SDRAM interface.
| Signal | Width | Dir
| Description | | DDR_SDRAM_Clk_pin | 1 | Out
| Clock | | DDR_SDRAM_Clkn_pin | 1 | Out
| Clock inverted
| | DDR_SDRAM_Addr_pin | 0 : 12 | Out
| Address bus
| | DDR_SDRAM_BankAddr_pin | 0 : 1 | Out
| Bank address
| | DDR_SDRAM_CASn_pin | 1 | Out
| Active low column address strobe | | DDR_SDRAM_CKE_pin | 1 | Out
| Clock enable
| | DDR_SDRAM_CSn | 1 | Out
| Active low chip select | | DDR_SDRAM_RASn | 1 | Out
| Active low row address strobe | | DDR_SDRAM_WEn_pin | 1 | Out
| Active low write enable | | DDR_SDRAM_DM_pin | 0 : 3 | Out
| Data mask | | DDR_SDRAM_DQS_pin | 0 : 3 | Inout
| Data strobe both read and write
| | DDR_SDRAM_DQ_pin | 0 : 31
| Inout
| Data bus in/out | Here is an example showing the connection of two 16 bit DDR SDRAMS to the OPB DDR SDRAM controller.
(Courtesy of Xilinx)
Memory organization
OPB DDR SDRAM memory can be accessed as byte (8 bits), halfword (2 bytes), word (4 bytes) or Double word (8 bytes) depending on the size of the bus to which the processor is attached. From the point of view of the OPB, data is organized as big-endian. The bit and byte labeling for the big-endian data types is shown below. To address 32 bit words the address must be incremented by 4 to read the next word. One more observation, the MSB is bit 0 and the LSB is bit 31, opposite to what you may be used to.
The DDR SDRAM Verilog model
Let's see if the Verilog model (ddr.v) matches the OPB interface. Here is the module declaration:
module ddr (Dq, Dqs, Addr, Ba, Clk, Clk_n, Cke, Cs_n, Ras_n, Cas_n, We_n, Dm); It seems we a perfect match.
Compilation of the Verilog DDR SDRAM module
We will compile the ddr.v file together with the include file ddr_parameters.vh to the database directory $ETC_VERIFICATION/database/ncsim/userlib/sdram_v1_00_a. The default memory compiled will have 16 bits data width and speed grade sg75Z. Fine for us.
Instantiation of two memory modules
Here is the instantiation that has been added to the EXT_system_testbench.tb.
//$$INSTANTIATION OF EXTERNAL COMPONENTS
/*************************************************************************/
/* */
/* E X T E R N A L C O M P O N E N T S */
/* */
/*************************************************************************/
ddr ddr_sdram_16_31 (
.Clk (DDR_SDRAM_Clk_pin),
.Clk_n (DDR_SDRAM_Clkn_pin),
.Cs_n (DDR_SDRAM_CSn_pin),
.Cke (DDR_SDRAM_CKE_pin),
.Ba (DDR_SDRAM_BankAddr_pin),
.Addr (DDR_SDRAM_Addr_pin),
.Ras_n (DDR_SDRAM_RASn_pin),
.Cas_n (DDR_SDRAM_CASn_pin),
.We_n (DDR_SDRAM_WEn_pin),
.Dm (DDR_SDRAM_DM_pin[2:3]),
.Dqs (DDR_SDRAM_DQS_pin[2:3]),
.Dq (DDR_SDRAM_DQ_pin[16:31]) );
ddr ddr_sdram_0_15 (
.Clk (DDR_SDRAM_Clk_pin),
.Clk_n (DDR_SDRAM_Clkn_pin),
.Cs_n (DDR_SDRAM_CSn_pin),
.Cke (DDR_SDRAM_CKE_pin),
.Ba (DDR_SDRAM_BankAddr_pin),
.Addr (DDR_SDRAM_Addr_pin),
.Ras_n (DDR_SDRAM_RASn_pin),
.Cas_n (DDR_SDRAM_CASn_pin),
.We_n (DDR_SDRAM_WEn_pin),
.Dm (DDR_SDRAM_DM_pin[0:1]),
.Dqs (DDR_SDRAM_DQS_pin[0:1]),
.Dq (DDR_SDRAM_DQ_pin[0:15]) );
When we rerun our simulation the signals to the memory looks like this. Looks good to me.
If we run the simulation a little bit longer we get the following message.
ETC_SYSTEM_TEST.ddr_sdram_0_15: at time 202273 ns MEMORY: Power Up and Initialization Sequence is complete
At time 202373 ns LMR : Load Mode Register
At time 202373 ns LMR : Burst Length = 2
At time 202373 ns LMR : CAS Latency = 2
After the power up sequence is complete the auto refresh starts.
Suppressing assert messages in IEEE packages
When we have an 'x" in our simulation the VHDL packages will print millions of assert messages telling you there is an 'x' in your simulation. To suppress these message we can use the following tcl commands to ncsim:
ncsim> set pack_assert_off ieee.NUMERIC_STD
ncsim> set pack_assert_off ieee.STD_LOGIC_ARITH
We will add these commands to the TCL input file : $ETC_VERIFICATION/tcl/ncsim_tcl_input.def and they will be executed every time we run ncsim.
Top Next Previous
Posted at 03:38 pm by svenand
Permalink
FPGA design from scratch. Part 19
|
