Page 1 of 1

FPGA Firmware update

PostPosted: Sat Oct 18, 2014 8:57 pm
by bluefreq
I was hoping to be able to create my own 'firmware' and reflash the FPGA image with some custom code.
I've looked briefly at the hdl code, but haven't seen any way to do so without soldering on some headers (which I'm reluctant to do, as I'd have to drill the case as well).
Is there any way to do so?
Do you have any architectural diagrams of the HDL code that you can share?

Re: FPGA Firmware update

PostPosted: Tue Oct 21, 2014 11:29 pm
by Andy
Hi bluefreq,

If you want to reflash the FPGA image with some custom code, you just need to replace "res/DSLogic33.bin" or "res/DSLogic50.bin" file in install directory using your custom bin file for xc6slx9 FPGA.

You should convert bitstream to raw binary.
Please refer to following link: ... /td-p/7772


Re: FPGA Firmware update

PostPosted: Wed Oct 29, 2014 2:15 am
by n4mho
Where do I find the HDL code for this project?

Re: FPGA Firmware update

PostPosted: Mon Nov 03, 2014 12:35 am
by Andy
n4mho wrote:Where do I find the HDL code for this project?

Re: FPGA Firmware update

PostPosted: Wed Oct 21, 2015 11:19 am
by RGD2
Which pins on the fx2 connect to what inputs/outputs in the FPGA firmware?

I'm going to try to port my firmware to the DSLogic, but I'm also going to need to use a bit of custom firmware in the fx2 to get the PC side of my application to talk to the Spartan6 through the fx2, and the easiest way seems to be to just rearrange my design to conform to the DSLogic's connections.

This is the app that captures real time data 30MB/s for 11 TB without any glitches (with an intel Xeon PC running ubuntu 14.04 LTS).

Although the hardware I am using now does have 64 MiB of dram, I think the design will work with 32 MiB. I suspect it really only needs about 8, so long as the host side is on the ball and doesn't micro-time-out too long or too often.

I'm interested in getting it working with an Allwinner A10/A20 host, since I was getting close to 39999 KB/s from an FX2 with a PcDuino3. I think the ARM SoC's have better DMA controllers integrated into their USB roots than PC's usually have, and if I can manage similar performance on the PcDuino3nano I may be able to then stream data at such a rate over the GbE, which would be good.

Re: FPGA Firmware update

PostPosted: Wed Oct 21, 2015 12:38 pm
by RGD2
Answering my own question because I noticed

FX2 pin <> fpga pin : hdl name
SLOE/PA2 <> P35 : sys_en
RDY0/SLRD < P39 : usb_rdy
WU2/PA3 <> P34 : sys_clr
ADDR0/PA4 <> P33 : usb_overflow
ADDR1/PA5 <> P32 : -
FLAGD/PA7 <> P30 : -
PKTEND/PA6 <> P29 : -
INT1#/PA1 > goes to LED
INT0#/PA0 > goes to LED
CTL2/FLAGC > P37 : -
CTL1/FLAGB > P64 : usb_en
CTL0/FLAGA > P47 : usb_rdwr
CLKOUT > P124 : -
IFCLK <> P70 : cclk
FD0-15 <> P{65,62,61,46,45,44,43,48,27,26,24,23,22,16,17,21}.

Hmm.. this could be tricky. My design had the FX2 running in slavefifo mode, whereas the DSLogic is wired to use GPIF master mode, which for some 56PVXC FX2's doesn't detect changes on RDY0/RDY1 - but perhaps you have a good batch?

(The ones I first tried to use absolutely refused to sense changes - although they worked fine in slave fifo mode. I think the multiple functions require that pin to be multiply-bonded, and I think some of those specific packages weren't bonded right. The exact same firmware I was trying to get work instantly worked without any changes when I tried running on an FX2 in a different package... Cypress know, they put out an advisory about it... the other way you can still run gpif master mode even without working RDY pins is to use the transaction counter to terminate a transfer - which is what the USRP guys did, in the open source firmware for that.)

Hmm.. I have a feeling FPGA_DONE is dedicated and can't actually be used as a user-controlled pin, this will make things tricky...

Andy - Do you have any problems using decision points in the GPIF master with the RDY pins?
(ie, getting a waveform to stop or start based on what the RDY pin is doing?)

Re: FPGA Firmware update

PostPosted: Thu Oct 29, 2015 12:54 am
by Andy
Hi RGD2,

We used rdy pin, but don't use as a accurate flag.
It seems no any problem with our tests.