codiert.org

When the XUPV5 board arrived (in 2008) it already was configured to boot OpenSolaris on the OpenSPARC T1 processor. I just did a short boot and looked at the serial prompt. This was the whole experience I made with the default set-up. Since the board was needed for other projects, I deleted the files from the SystemACE CF card. Last week I had some evening cycles and reactivated the set-up and  booted OpenSolaris on the T1 again. Here some notes about it.

Needed download: OpenSPARC T1 Core
Useful Documentation: quick start

After copying the OpenSPARCT1_1_7_os_boot.ace file into a free revN directory on the CF card and configure SW3 dips to the corresponding revN directory the board could be power-on. On the serial line the firmware boot shows up and after entering into the OpenBoot prompt OpenSolaris can be boot with the command “boot -mverbose”. Now it’s time to take a coffee, since the boot procedure takes roundabout 60 minutes. After finishing the boot procedure, a login prompt is displayed and it can be logged in the system to adjust the IP address for the local network. Now telnet can be used to log-in and to explore the system…

Again the issue with the Xilinx JTAG cable under Linux. This post is just a reminder… After putting the cable into the USB port, nothing happens. ‘lsusb’ shows the device but the led on the JTAG box doesn’t light up, which means the firmware isn’t loaded. The firmware is provided by Xilinx and it can be loaded with:

/sbin/fxload -v -t fx2 -I /usr/share/xusb_xlp.hex -D /proc/bus/usb/<bus>/<dev>

New week, new API. I’m not the person who complains about APIs, but the RDMA API is somehow scary. For a simple “HelloWorld” data transfer program I had to write over 600 lines of code. Just think about that, if everybody has to code 600 lines to get a connection and a remote buffer to work on that buffer, that is not very maintainable. Anyway, I have the impression that this API isn’t used by very much people and the majority just use the upper layers, like distributed filesystems or MPI. Of course, there are lots of attributes which can be configured and you have the complete control, but that only make sense if you want the last percent of performance, that is the only thing which could be rated as plus point. It would be nice if someone could explain me why this API is done this way…

I started looking into the graphic card programming especially Nvdia CUDA stuff. After getting the SDK compiling under Fedora 12 (so far only possible with compat-gcc) first examples could be tested. It is quite impressive how fast and nice some tests look like.

To get somehow familiar with the framework, I wrote a simple memcpy program which copies from host memory to device memory and vice versa. The results are quite nice.

Host to Device: 2149.465255 Mbyte/s
Device to Host: 1609.497326 Mbyte/s

In detail, the program allocates pinned memory on host side and global memory space on device side and the measurement only measures the time of the copy routine.

The next simple experiment was to lunch a so called kernel (program on the GPU). For the experiment I just copied an initialized memory region to the global device memory, did a floating point multiplication and copied the result back into host memory. To compare the measured time I did the same multiplication with the host CPU on an equal region of memory.

GPU w/out memcpy: 1.796128 ms
Host CPU        : 3.556544 ms

Hardware used: Lenovo T61p, Nvidia Quadro FX 570M.

The following recursive VHDL function provides the needed bit count for a given integer number.

function len(x: integer) return integer is
begin
  if (x<=1) then return 1;
  else return 1+len(x/2);
  end if;
end len;

This solution solves the issue on, how to detect either one or more bits are active in a bit array. The technique is quite easy, just isolate one of the bits. This can be done by the same technique as known from the arbiter implementation. Calculate the two’s complement of the bit array signal and bitwise AND the result with the same array line (1).

(1) b <= a and (not a)+1;

This equation isolate the least significant bit. Since we just want to know if there are more than one bit is active, the next step is to mask out (2) the detected bit from (1) and compare the result with zero (3). If the result is zero, no other bit was active.

(2) c <= not b and a;
(3) morebits <= '0' when c = 0 else '1';

Here a very cute method to implement an FPGA round robin arbiter, inspired by [1].

Assumption
Incoming signals “req”/”ack”, outgoing signal “grant”.

Needed Behaviour
req = “0001000″ => grant = “0001000″ -ACK- grant = “0001000″
req = “0011000″ => grant = “0010000″ -ACK- grant = “0001000″ -ACK- grant = “0010000″ …

Technique
To create a priority arbiter, we just calculate the two’s complement of the request signal and bitwise AND the result with the request line (1). As result the least significant bit has the highest priority. This equation always returns the request with the highest priority.

(1) gnt <= req and not(req)+1;

To create an round robin arbiter we have to save the previous grant signal. We use this signal to masked out the previous grant signal (2) and use the method from (1) to get the least significant active bit.

(2) reqs <= req and not ((pre_gntM - 1) or pre_gntM);
(1) gnts <= reqs and not(reqs)+1;

The last step to realize the RR-Arbiter is to select between “gnt” and “gnts” (3). If all previous grant signals are masked we just start with the highest priority of equation (1).

(3) gntM <= gnts when reqs /= 0 else gnt;

Conclusion
This technique can be used to create an round robin arbiter for any number of input bits. Only one parameter must be changed so increase/decrease inputs and outputs.

[update 2010] Since I got some requests, Round Robin Arbiter.

[1] http://stackoverflow.com/questions/480405/finding-the-next-in-round-robin-scheduling-by-bit-twiddling

Today I had a great day. I spend the whole day in Villingen and drove my motorbike on an indoor track (http://www.mo-ce.de/). It was the first time this year and the first time indoor. Also the handling of the motorbike was complete different, this could be related to the new suspension I invested during the winter time. So hopefully, I will have time to join the track again.

During the vacation time a lot of code changes were made. Now it is time to write a little bit about the changes. The first thing was to write a Cypress USB to wishbone interface which gave the possibility to connect wishbone compliant modules to USB. As testcase the wishbone lcd driver should help to get the interface stable. Some changes regarding the LCD clock as to be made because the first implementation used the slow clock, which is needed for the lcd, for the whole design. Now a fast clock is used and the lcd module generates a slower clock for the lcd interface. Further changes were made in the Cypress bios to support the new usb2wb (USB to Wishbone) interface. What should I tell, so far everything works great. With a program which uses calls from libusb, it is now possible to initialize the lcd and drop characters to it.

Today I want to use the attached DDR2 Ram on the ml50x (XUPV5) board. Xilinx provides a Memory Interface Generation (MIG) IP core which could be used to generate a design which drives all ddr2 lines and provides an interface for user logic. It is extremely sadly that xilinx doesn’t provide directly the needed ucf-files for all boards they sale. Everybody who wants to use the MIG has to create the ucf by himself or looking for reference designs where this file is included. Fortunately the ucf exists for the xupv5 board. So I only have to care about the user logic which writes or reads from the memory. The user interface is well documented in the user guide (ug086) and could be driven with some lines of code. Keep reading, now it is time to combine some already written logic with the mig.