Xilinx SystemACE on multi-FPGA board

Not enough information on your problem.

1) In the single Virtex-II case, what does the complete JTAG chain look like? 2) In the dual Virtex-II case, what does the complete JTAG chain look like? 3) Have your connected the DONE pins of the Virtex-II devices together? 4) In the dual Virtex-II case, do both device go DONE? 5) Which device is connected to the MPU port of the SystemACE device? 6) What holds the PPC405GPr in reset until both Virtex-II devices have been configured? 7) What exactly is a PPC405GPr, I think that this is discrete PPC405, but which one? 8) What exactly does this mean? "The SystemACE driver is getting an error that the JTAG configurator was unable to read the configuration stream from the CF." 9) It sounds like you filed a case with our hotline, what number were you assigned?

Ed McGettigan

-- Xilinx Inc.

I had a quick discussion with our Linux/UBoot expert and the SystemACE designer as well as reading your original case that you filed with our hotline and we believe that the SystemACE driver code that you are using is resetting the SystemACE and causing another configuration of the devices in the chain.

In the case of the single FPGA in the chain the SystemACE reconfiguration may complete and return control to the MPU port before another MPU access is made. While in the case of the two FPGAs in the chain the reconfiguration is still occurring when you attempt another MPU access. In any case you should not be reconfiguring the devices a second time (unless you really want to) and our Hotline had given you instructions on how to prevent the reconfiguration.

If you would like to confirm this theory you can put a scope probe on the CFG_TCK pin from SystemACE and you should see it actively toggle, stop for a period of time after the 1st configuration and then restart again at some point before stopping permanently.

The hotline engineer assign to your case did not ask any of these questions that I posed as your original query was very different from the one that you posed here on comp.arch.fpga, but I do believe that they did give you an answer that will resolve the problem when you implement it.

Ed McGettigan

-- Xilinx Inc.