Forum Discussion
Altera_Forum
Honored Contributor
11 years agoThese modules are entirely custom and designed to sit in the second cpu socket of an Intel Xeon DP server. We already have built and deployed a few hundred now. Redesign is not an option. Future platforms will have a better program flow through the processor directly and will be programmed by the bios at power on (adds ~20-30 seconds to the boot time). When we get to production stage of that design, we will no longer need jtag for everything, although we will likely need it for internal development/debug.
My theory for 1 server, multiple targets was that it reduces the overhead per rack cabinet. Our current production system is based on a 4U server, and the next generation will allow for 1U or 2U server (same motherboard for 1U/2U). Each server already uses 2 IP addresses (1 OS, 1 Remote Management). Having a third for each system (jtag server) is not easy without moving internally to a new subnet. Networking aside, having 1 additional host per target is also a waste of space and resources. It takes far too much time to allocate systems for development/debug/validation. Also, it is not very efficient for a developer to have to query the lab staff to see what is available, and not efficient for lab staff to query developers to see if they are still using a system when there is a shortage. Except for the multi-threaded connection issue, my design is fairly optimal and easy to automate for allocation, and allows for scaling. I even have a full web front end for managing and allocating systems in the pool, complete with time expiration alerts and auto-logoff (for the developers that forget they are on a system and go on vacation).