[USRP-users] FW: Config N210 with Microblaze

Huldi Michael huldm1 at bfh.ch
Mon Jun 11 10:38:35 EDT 2012


Hi,
I give you right that the problems with the tools of Xilinx not your issue is. But fact is if I add a elf-file from microblaze to a ise-project and generate the .bit file for an other hardware than USRP N210 so I can download the generated download.bit file via Jtag and it works.
But if I generate the download.bit file on the same way and convert the generated download.bit file with the command "promgen -u 0x0 download.bit -p bin -w " to a .bin file, the net-burner doesn't accept the file.
Do you have an idea how I can solve this problem on a simple way. Because to write some extra zpu-firmware is too complex.
Thanks Michael


From: Ian Buckley [mailto:ianb at ionconcepts.com]
Sent: Donnerstag, 7. Juni 2012 18:54
To: Huldi Michael
Cc: 'usrp-users at lists.ettus.com'
Subject: Re: [USRP-users] Config N210 with Microblaze

Michael, I'm a little confused by what your actual question is? It seems your having fundamental tactical problems loading a new FPGA image onto the N210, but the question you pose is architectural: "Is it possible to program the fpga with impact via JTAG? How could I insert the zpu firmware file in this case?"

I'm not going to address your problems with using the Xilinx Microblaze SDK, that's a Xilinx proprietary flow and not something I, nor anyone at Ettus uses. But I'll try to give you some architectural guidelines how to add a new microprocessor to the N210:

First, yes it's entirely possible to use impact to program the FPGA, this is how all new H/W is initially brought up. However note that unless you design the H/W to have an attached FLASH RAM in a way supported by impact for JTAG programming then you are only to directly configure the FPGA and that configuration will be lost every power cycle/reset. The USRP SPI flash is not programable via impact, so all non-volatile FPGA images and firmware images have to be burned under firmware & FPGA control.

Now to boot an embedded microprocessor there are generally 2 different approaches:
1) The boot vector (PC after reset) directly addresses a discrete FLASH RAM that you can program externally (normally via JTAG)...this option doesn't exist for unmodified N210 H/W.
2) The boot vector addresses an internal stable boot ROM (a pre-initialized BRAM in a Xilinx) and the microcode in there performs a second stage boot, getting more firmware from elsewhere (FLASH RAM, network etc). This is how the stock N210 works with the ZPU and the attached SPI flash, which contains multiple FPGA and firmware images. In this case the ZPU boot's with the bootrom code in one BRAM, and uses this code to load the production firmware ware image from SPI FLASH to the other at which point it does a quick FPGA logic trick, swaps the MSB of the 2 BRAM's so that the boot vector now points to the other BRAM and toggles the ZPU reset line to cause a new (ZPU not FPGA) boot.

Since you already have a working bootable and upgradable system in the stock N210, I strongly suggest the following approach:
1) Add your second microprocessor (I suggest reusing the ZPU, firmware libraries and tools..but you may have a compelling reason to learn and use Xilinx microblaze SDK) to the existing FPGA build methodology and continue to use the Ettus Makefile driven scripts to build and upload a new FPGA image via the network.

2) Make the BRAM(s) that contain the firmware for your new microprocessor exist also in the existing ZPU memory map. You can do this either by multiplexing them or making use of the dual port nature of BRAM.

3) Write some extra firmware for the existing ZPU so that it handles the download of your new microprocessors firmware from network to SPI flash and from SPI flash to BRAM exploiting all the TCP/IP based updater code that already exists. Boot your second microprocessor after and under the control of the original ZPU.

This will be less work than you imagine since you will essentially be able to re-use all Josh's existing firmware code and the H/W design idea's behind the N210. You'll have a system quickly where you will not have to rebuild the FPGA every time you change firmware.

Hope this helps,
-Ian






On Jun 7, 2012, at 5:53 AM, Huldi Michael wrote:


Hello,

I need help to get a simple microblaze configuration with bram-memory working with the USRP N210 release_003_004_001.

I removed the tx chain and insert the microblaze in the top and connect 2 of the leds from the front to the microblaze gpio. Run  a software with a blinking led function.

I tried different ways to program the fpga without success:

1. add the elf-file from the microblaze to the ise-project and generate a .bin File with double click to "generate programming file" in ise, then download with net burner.

2. combine the bitstream with the elf file, which resides in the bram in SDK with "Programm FPGA" to a .bit file, then convert the generated file download.bit to a .bin file with "promgen -u 0x0 download.bit -p bin -w " and try to download with net burner. But the net burner says "Invalid FPGA image file".

3. Download with Platform Cable and with SDK, JTAG connected to the FPGA. But here it doesn't load the new configuration, since the leds I disconnect still light up in startup.

I also changed the StartUpClk in the bitgen.ut from JTAGCLK to CCLK.

Someone have an idea, how to make my configuration working? Is it possible to program the fpga with impact via JTAG? How could I insert the zpu firmware file in this case?

Thanks for your help!
Huldi

_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com<mailto:USRP-users at lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120611/78ad9cf9/attachment-0002.html>


More information about the USRP-users mailing list