I've CC'd this to the list so my advocacy gets archived. ;)
On 09/03/11 12:34 AM, Michael Walle wrote:
Mh, xilinx has the bscan cell, which basically has a TDI and TDO and that gets connected to the real JTAG pins if you select the proper instruction (USER1, USER2, etc). The 'internal' JTAG TAP isn't really visible externally. Doesn't the Altera's vJTAG megafunction work in a similar way? For the Xilinx case, i have to know that i have to use a special instruction anyway. Hence i don't see why there should be an IDCODE for automatic discovery.
Sounds quite similar. Altera boards have a JTAG bitbang interface over USB. You can boundary scan, load FPGA configuration, etc over that JTAG interface. Sometimes this interface has more than one chip on it (our Arria2 boards have 2 components in the chain, for example).
The Cyclone3 chip has a 'sld hub' inside it which is accessed via two of the Cyclone3's JTAG registers. You can instruct the hub via USER1 to connect one of the JTAG instance ids' IR or DR to the USER0 register.
What is inside that chain you can now probe like any other JTAG chain; only the way you access the chain is different, two registers instead of USB. Since the FPGA is reconfigurable, until you probe the internal chain, you have no idea what is inside it. Having a tool which is able to detect the contents of the FPGA and say "Aha! You have an LM32 in there, let's provide gdb hooks and wishbone bus access!" is a lot better than a tool which has to work off the assumption that the FPGA was configured with an LM32.
I have designed my debug tool to be quite modular and extensible. I hope that it will be useful for many other cores than just the LM32. In that case, it might need to support other devices built into a Cyclone3/whatever. Other designs may already have a JTAG chain with multiple devices that were originally connected directly to output pins and you have now connected to the sld hub. In that case the tool should still scan the JTAG chain to determine what is inside and address the attached devices.
Conversely, you might design an LM32 to have its JTAG pins connected to actual output pins once deployed. In that scenario you would need IDCODE support for the LM32 to be detected on the external interface. I intend to make my LM32 debuggable over Etherbone in addition to USB. That means I will wire the JTAG pins also to a small Wishbone->JTAG slave. Since we will likely have many devices on that Linux/UDP->Etherbone->Wishbone->JTAG path, the LM32 should behave correctly so that we can use it and the other devices.
Finally, the cost to implement IDCODE and BYPASS is very small. I imagine it will be some 2-4 hours of work and under 20 LUTs. So I'd turn the question around and ask: "What is the advantage to not conforming to the JTAG standard?"
Will an Altera FPGA split the JTAG chain if you use you instantiate a vJTAG megafunction? I can hardly believe this, because (1) a broken FPGA bitstream could result in a broken JTAG chain (2) the JTAG chain would be different if the FPGA was configured
You cannot attach a device to the top-level JTAG, but as I've argued above, there are many situations where that doesn't excuse the LM32 from conforming to the standard. _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode Twitter: www.twitter.com/milkymistvj Ideas? http://milkymist.uservoice.com
