This is our new webpage. If you prefer the old one, it's here. If something's not working right, let us know at contact@antmicro.com or use the contact form. Thanks!
 
 
 
 
 
 

Posts Tagged ‘Xilinx’

May 13th, 2012
Xilinx X-Fest 2012 in Oslo – time for Zynq

Oslo is always a good and familiar place to visit, especially if it means bumping into some old friends from the FPGA world and making a few new ones on a Xilinx X-Fest. The one we attended was held in Sandvika in suburban Oslo on May 8, but you can still participate in several other places around Europe and the world if you wish – check the event website!

This year, X-Fest is dominated by the new Cortex-A9+FPGA hybrid – Zynq, with one track and most exhibitor’s booths dedicated exclusively to this technology. And rightly so!

The “Processing System + Programmable Logic” combination, a dual-core general-purpose CPU with the ability to delegate tasks which are computationally heavy and prone to parallelising onto a dedicated block synthesised within the FPGA is just brilliant. Sure, not all applications will benefit from this, but if you know what you are doing and are able to identify bottlenecks in your product, you can get your software to run some 10x faster.

It’ll be good to verify this claim in practice – after all, ground-breaking technologies are more often announced than functional – but this time it looks that Xilinx’s has really done a good job. There are limitations such as power-up time or the speed of the CPU (the dual-core Cortex-A9 is clocked only around 600 MHz for now, 800 MHz in future chips) but none of them seem to be deal-breakers.

We will see if the tools available allow the ecosystem to suck up ‘traditional’ software developers in addition to the FPGA guys, but it seems that Xilinx is aware of the fact that SW engineers require a different approach and are working with ARM provide tools necessary to facilitate the transfer from plain-ol’ CPU systems to a CPU+FPGA hybrid.

We have already been running the Zynq QEMU port out of curiosity, but this of course gives little feel of what the real stuff behaves like. However, with a bit of luck we will get our hands on physical modules as early as in June.

Follow our blog where we will describe our work with the Zynq technology and our thoughts on how useful it really is in practice. If you have ideas on how your applications can benefit from using Zynq or want to ask a question about it, be sure to leave a comment!

June 9th, 2011
FDT support for QEMU/Microblaze

As mentioned in the previous note on Customizing Microblaze emulation, the original microblaze/qemu provided support for a Petalogix Spartan3adsp1800 board only. Thanks to the modifications introduced in that note it was possible to create an external configuration file which listed the peripherals to be included in the emulation, thus enabling the support of any other Microblaze configuration.

As promised in the summary of the note, we have greatly improved this mechanism, so that all the information is extracted directly from the .dtb (Flattened Device Tree file) file and the mb.per file is no longer needed.

To modify the .dtb file simply decompile it with Device Tree Compiler using the following command:

1
dtc -I dtb -O dts mb.dtb > mb.dts

Once the modifications are performed, the altered data can be compiled back to .dtb file using the following command:

1
dtc -I dts -O dtb mb.dts > mb.dtb

For example, the uartlite UART is described using Flattened Device Tree file format in the following way:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
RS232_Uart_1: serial@84000000 {
    clock-frequency = <125000000>;
    compatible = "xlnx,xps-uartlite-1.00.a";
    current-speed = <115200>;
    device_type = "serial";
    interrupt-parent = <&xps_intc_0>;
    interrupts = < 3 0 >;
    port-number = <0>;
    reg = < 0x84000000 0x10000 >;
    xlnx,baudrate = <0x1c200>;
    xlnx,data-bits = <0x8>;
    xlnx,family = "virtex5";
    xlnx,odd-parity = <0x0>;
    xlnx,use-parity = <0x0>;
} ;

In our modification, only the “compatible”, “interrupts” and “reg” fields are taken into consideration.

The attached .diff file is compatible with the latest QEMU 0.14.1

To include the change, QEMU must be compiled with libfdt support.

It modifies the original petalogix_s3adsp1800_mmu.c so that instead of adding default peripherals it loads the dtb file and dynamically adds peripherals basing on the data from the Flattened Device Tree file.

This modification is released under the GPL.

Attached .diff file: qemu_microblaze_fdt.diff.gz

August 25th, 2010
Customizing Microblaze in QEMU

The Microblaze QEMU port contributed in 2009 by Edgar E. Iglesias from Axis Communications AB (Sweden) makes QEMU a very useful tool for Microblaze OS prototyping.

The problem is that the port is limited to emulating a fixed set of hardware (Petalogix s3adsp1800 Spartan3a board) with fixed addresses in memory, interrupt controller, timers, UARTs, ETH, etc.
Of course, you could adapt your application (e.g. Linux or eCos kernel) to take this limitation into consideration, but why make things harder than they should be? We’ve decided to simplify this process by removing the need to tamper with the kernel code. Instead, by making a few simple alterations to the QEMU, we allowed it to use an external “peripherial” file (“mb.per”) with hardware definitions.
An example “mb.per” file for the Petalogix board (think of it as the “default” file, as these are the settings QEMU originally starts with):

1
2
3
4
5
6
7
8
9
10
#
# petalogix s3adsp1800 board microblaze definition
#
fpgaid 0x0C000000
ddr 0x90000000 134217728
irq 0x81800000 0
sysbus xilinx,uartlite 0x84000000 3
timer 0x83C00000 0 2 62000000
eth 0x81000000 1
flash 0xA0000000 16777216

When QEMU is launched with the file above, it will run Microblaze @ spartan3adsp with 128MB of DDR memory mapped @ 0×90000000, irq controller @ 0×81800000, one UARTLITE serial @ 0×84000000, IRQ=3, two 62 MHz timers @ 0x83C00000, IRQ=2, one ethlite @ 0×81000000, IRQ=1 and 16MB flash driver @ 0xA0000000.
The idea is very simple, and the general shape of the .per file is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# fpgaid id
#    0x04000000 : Virtex2
#    0x05000000 : Virtex2pro
#    0x06000000 : Spartan3
#    0x07000000 : Virtex4
#    0x08000000 : Virtex5
#    0x09000000 : Spartan3e
#    0x0A000000 : Spartan3a
#    0x0B000000 : Spartan3an
#    0x0C000000 : Spartan3adsp
#    0x0D000000 : Spartan6
#    0x0E000000 : Virtex6
# ddr addr size
# irq addr sys_irq
# sysbus name addr irq
# timer addr irq count clock_speed
# eth addr irq
# flash addr size

Using this “fix” we’ve successfully started eCos and Linux kernels prepared by us for other targets (Spartan6).
All this data can be retrieved from the .dts/.dtb Device Tree file, so one idea for the future would be to make QEMU read the necessary information from the mb.dtb file.

Attached .diff file: qemu.diff.zip

 

Copyright © 2009 - 2012 ant micro. All rights reserved. | Design: Duind.com