You are not logged in.
Hi there,
we recently discovered an issue regarding the use of different bitstreams on our 5 board testbed (mixed v1 & v2). To be more specific we started to use different bitstreams which not only differ in its software part but also its hardware part.
When we program the boards alternatingly with both bitstreams, we end up with the radio board somehow misconfigured and the board not being able to communicate with others.
Once this happens the only way to fix this issue is to powercycle the board. Reprogramming with any bitstream does not help. This is a big issue because the boards are controlled remotely and are not within reach.
The problem can be reproduced rather easily.
Our designs are based on the OFDM Reference Design. On my way to find the cause I found out that the issue can also be reproduced with the unchanged reference designs.
If I build both the 16.1 and the 16.2 reference designs, use the CSMAMAC sourcecode and program two v1 boards at once in the following orders I'll get these results:
powercycle -> program 16.1 -> boards working -> program 16.2
= board 1: all radio board LEDs are off (green, yellow, red).
board 2: red and yellow radio board LEDs are lit, green flashes upon transmission - no communication
powercycle -> program 16.2 -> boards working -> program 16.1
= same as above
powercycle -> program 16.2 -> boards working -> program 16.1 -> program 16.2
= board 1: red and yellow are lit
= board 2: board didn't boot up at all. no hex display. no ethernet. no tty.
powercycle -> program 16.1 -> boards working -> program 16.2 -> program 16.1
= board 1: red and yellow are lit
= board 2: board didn't boot up at all. no hex display. no ethernet. no tty.
powercycle -> program 16.1 -> program 16.1 -> ... -> program 16.1
= works fine
powercycle -> program 16.2 -> program 16.2 -> ... -> program 16.2
= works fine
I can reproduce this with each of two bitstreams which differ in its hardware parts. For example just changing the debug_io module from 2 to 8 pins and rewiring the debug pin header in the ucf file will cause such a behaviour.
I have seen this issue on at least three v1 boards. I haven't tried for v2 yet.
The only thing I configured in the reference designs is the linker script where I selected "ppc405_0_(d/i)ocm_cntlr" for all entries and the programming script which I attached at the end.
Before I dig deeper into the problem I wanted to ask if anybody has seen a similar issue or knows a solution.
I suspect that the radio boards are not properly reset on reprogramming but I don't have the knowledge to get deeper into this.
Help would be very much appreciated.
Thanks in advance.
---
Impact Batch Script:
setMode -bscan
setCable -port usb21
identify
assignfile -p 2 -file implementation/download.bit
program -p 2
setCable -port usb22
identify
assignfile -p 2 -file implementation/download.bit
program -p 2
quit
Offline
I just tried to reproduce this using a 2-radio WARP v1 kit and the download_csmamac.bit files from the two ref design archives. I can re-program in any order and node always boots up as expected. I'm using iMPACT 14.4 and one Digilent XUP USB-JTAG cable.
Can you try your setup with the original download_csmamac.bit files? This will help rule in/out something inherent in the reference design or in your hardware setup.
Do you see the same behavior if you select .bit files and program the FPGAs interactively in iMPACT (vs. using the batch script)?
= board 1: red and yellow are lit
When a node boots into this state does its UART print anything at boot? Does a software reset (pushing the "down" button) have any effect (UART output, LED state changes)?
The solid red LED indicates the radio PLL is not locked. This suggests either the Clock Board is not providing a valid 20MHz RF reference clock or the MAX2829 is misconfigured. The Clock Board is configured by the clock_board_config core immediately after the FPGA is configured, before the PPC attempts to boot. The MAX2829 is setup by the radio_controller driver during the PPC boot. If the problem is during the radio_controller reset, there might be some useful output on the UART.
Offline
Okay, I think I found it. I used ancient Impact 10.3 for programming. With 14.4 and this cable driver http://www.george-smart.co.uk/wiki/Xilinx_JTAG_Linux the problem didn't show until now.
Thanks for your help.
Offline
I discussed the issue once more with my colleague. I was not aware that 10.1.3 is the last ISE Version that fully supports the Virtex 2 pro device.
The problem as described in my first post is also reproducible with the original bitstreams (download_csmamac.bit) and impact 10.1.3. There is no difference between the GUI and a batch script.
Pushing the reset button has no effect and there is nothing suspicious on the UART output.
On two boards we only use a single radio board. Does this make a difference?
@murphpo Before we change all our toolchains to another version, I wanted to ask if you have a 10.1.3 installation at hand and are able to reproduce it that way?
Otherwise the only suspect left is the cable driver. Which one is the appropriate for using with Impact 10.1.3 and Linux?
Offline
On two boards we only use a single radio board. Does this make a difference?
This shouldn't matter - the FPGA configuration process should succeed with any daughtercard configuration.
Before we change all our toolchains to another version, I wanted to ask if you have a 10.1.3 installation at hand and are able to reproduce it that way?
I don't, unfortunately. I have an old VM with 10.1 somewhere but am not sure it still runs. We definitely don't have a Linux machine with 10.1.
Any version of iMPACT can configure a V2P device - it is ok to use iMPACT 14.4 to configure the V2P with a bitstream generated by ISE 10.1. The bitstream format and JTAG protocol have not changed (they're defined by the chip), but I'm not surprised at all that Xilinx may have quietly fixed USB driver bugs between releases.
It should be possible to have ISE 14 and ISE 10.1 installed on the same machine. The ISE 10.1 tools can generate the bitstream. The ISE 14.4 tools can provide the newer USB driver and matching iMPACT version.
Offline