Zedboard/Bittware Anemone Board Setup

[russ_smith]

I have a setup which includes a Zedboard, and a Bittware FMC board with 4 of the EG16G301 Epiphany Chips.
The Bittware board was originally intended for connecting to a Bittware PCI-e board, but Bittware is having problems making that configuration work.

I sent the Anemone Board back to Bittware to be reprogrammed for the Zedboard application. This consisted of a CPLD update to change the Chip XID and YID values to put the Base Address at 0x80800000.

There is an AD9520 Clock Generator chip on the Bittware FMC board. It is necessary for the clock generator chip to be programmed in order for the Epiphany CCLK signals to be generated.

The AD9520 chip was not programmed by Bittware, thus providing no CCLK to the Epiphany chips. I programmed the AD9520 over the I2C bus to generate a 600MHz CCLK.

When I try to run the matmul-16 example, the linux system locks up when the program is trying to load the Epiphany program.

Does anyone know what the correct settings are for the AD9520 registers? My settings now are just a guess (though CCLK is 600MHz, measured on a testpoint on the Bittware board).

Does anyone have any other suggestions how I can get this system running?

Thanks
Russ Smith

[mhonman]

Are you able to confirm that one of the Epiphany chips is indeed mapped at the base address where you are expecting it to be?
e.g. can you access any on-chip registers prior to attempting the program load?

I'm no expert on this, but as far as I can understand the daughterboard setup should match the HDF and LDF files in the board support package directory (/opt/adapteva/esdk/bsps/zed_E16G3_512mb). And the base address of 0x80800000 is what it *should* be expecting...

To my shame I *have* had the experience of causing zedboard lockups, always due to the Epiphany not being home when I called - by that I mean (a) some silly blunders converting from on-chip addresses to host-side addresses so that the host was reading nonexistent locations (b) when the Epiphany is reset it temporarily disappears from host address space - the e_reset function thus includes a 0.2s delay between issuing the reset and attempting to access the chip.

Hope this gives you a couple of clues... it'll be interesting to know what the problem turns out to be.