Forum Discussion
Altera_Forum
Honored Contributor
11 years ago --- Quote Start --- First, let me state that I am a systems administrator and lab manager, not a hardware engineer. --- Quote End --- Great! Its good to know your perspective on the problem. --- Quote Start --- Our module has a 10 pin header for the USB Blaster to plug into for programming and probing the FPGA. We currently have 24 systems with modules, and due to the configuration the module needs to be programmed while the system bios is in a loop waiting for discovery. The systems currently are not self-programming, thus the need for Quartus on a 'Host' system. We have a team of engineers doing various debug and optimizations of our base RTL, thus the reason for Signal Tap and reprogramming (which takes ~30-40 seconds vs 3-5 minutes converting to POF and programming that way). When the engineers are not programming or debugging, the systems are in a pool for automated regression testing. When they need a system, they can request one from the pool. We are also ramping up to allow other internal (and possibly external) groups access these systems. Due to the space needed (4U rack space per FPGA based system), we need to be as conservative as possible. Hence the 1U 'JTag Server' in my diagram. Having a dedicated system running JTAG for each FPGA based system is not scalable, space or administratively. --- Quote End --- Your comments regarding the BIOS imply that these boards are also PCIe boards. Is that correct? Are these custom boards, or commercially available development boards? If so, what are they? I could take a look at the board design and see what other options might work for you. Your type of system management issue is something that needs to be solved at the hardware design level, so ultimately you might be limited by the boards your engineers have selected. I have a system with a similar issue to yours; see p16 + p18 https://www.ovro.caltech.edu/~dwh/correlator/pdf/hawkins_jpl_2014.pdf The 'data processing' FPGAs on these boards are dynamically reconfigured by the on-board PowerPC processor. The PowerPC is the PCI end-point and is always powered, so that the BIOS on the x86 cPCI host CPU does not see the PCI end-point 'disappear', which is what would happen if the FPGAs were the PCI end-point. In your case you sound like you're working with PCIe, but the concept is the same. If you are working with PCIe end-points implemented as FPGAs, and those FPGAs support CvP (configuration via PCIe), then it should be possible to have the PCIe end-points configure at power-on with an appropriate set of PCIe end-point registers that will allow the FPGA core to be configured and re-configured at will. Those end-points would not require JTAG for configuration, and configuration would take a second or so. You could have a pool of machines without JTAG connections, and another pool with JTAG connections. The JTAG pool would be used by engineers that need to use SignalTap II, while the non-JTAG pool could be used by the FPGA interface application developers, i.e., the developers working with already-debugged FPGA designs. If these boards are custom boards, and are still being designed, then here is an option I have considered; Compact PCI-Serial (CPCI-S.0), uses a backplane that includes PCIe, Ethernet, and USB. A Compact PCI-Serial host contains a USB hub that can connect to every board in a chassis. By including a USB-Blaster circuit on every peripheral board, the CPCI-S.0 host can see every USB-Blaster in a chassis. If that host runs an Altera JTAG server, then all connections in a chassis will be visible to the outside world. This "solution" is better than having numerous USB-Blaster cables, since there are no cables to manage, they are inherently part of the chassis design. If your system is not Compact PCI-Serial, but uses a custom chassis design, then this same concept could be applied, but would depend on the chassis connectivity. If you can provide more details, I can provide more ideas :) Cheers, Dave