I've just applied your patch to add Spartan III support on my custom hardware (PPChameleon AMCC405EP). To write the board-specific functions I used the file
board/gen860t/fpga.c
as starting point. I work with cross GCC 2.95.4 provided by ELDK
2.0.2.
The programming technique is slave serial. To make the code to work I had to apply some slight changes:
In function Spartan3_ss_load I had to replace this line
(*fn->wr) ((val < 0), TRUE, cookie);with if (val & 0x80) { (*fn->wr) (1, TRUE, cookie); } else { (*fn->wr) (0, TRUE, cookie); }
It seems the compiler does not like the expression (val < 0) because it is always evaluated to 0.
- It seems the board-specific function fpga_done_fn in
board/gen860t/fpga.c is wrong because it returns the error codes (either FPGA_SUCCESS or FPGA_FAIL). In my understanding it must return the state of the pin (0 when the DONE pin is low, 1 when it is high).
I can't commit my own fpga.c (spartan3) because this patch is not commited. The gen860t isn't my board but if they should make the changes to the gen860t code as you suggested, it wouldn't work. That's because the gen860t uses the parallel mode of configuring its Virtex2, if you check Virtex2_ssm_load(), Spartan3_sp_load() or Spartan2_sp_load() you can see that the while condition that checks the DONE pin state is:
while ((*fn->done) (cookie) == FPGA_FAIL) { in stead of: while (! (*fn->done) (cookie)) {
I tried to keep the code as compatibel with Spartan2 as I mentioned in the patch mail. Also by comparing with a fpga state here, it becomes more clear. Therefore it's maybe better to change the while condition in the Spartan3_ss_load() function. I can be wrong, don't hesitate to correct me if you disagree.
- I tried to use both the "fpga load" and "fpga loadb" commands
respectively with the .bin and .bit files. The first one runs
succesfully
while the latter fails. In this case the header is parsed correctly but the FPGA is not programmed and the DONE does not go high.
The loadb function is a wrapper around the load function that converts your bitstream file first. Could you check what the difference is between your manually converted bitsteam file and the data that loadb creates? Imagine that the fpga startup clock configuration is set to the JTAG clock. Your conversion tool could change this automatically into the config clock. But the loadb doesn't make any change to your bitstream before the conversion takes place. This results in a successful configuration in "fpga load" but not in "fpga loadb".
Kind regards Kurt