Max V Extending JTAG?

I think you need to reconsider your 'requirements'. Yes, the JTAG to Avalon Master Bridge IP is going to be a little large - it'll consume over half of the resources in largest MAX V device. However, without it you won't have an "actual interface between the on chip jtag tap circuits and the logic blocks..."

The JTAG interface allows you to program the non-volatile memory from which the device configures itself. At power up the device configures from this non-volatile memory. There is no default interface between the JTAG and the logic. This interface will only exist if your design implements it. I'd suggest the only practical way to do this is with Altera's JTAG IP. I'm not even sure if there is another way of doing it.

Hence, my suggestion that you reconsider your requirements. Either an alternative interface into your MAX V logic or a larger device, probably from another family (large MAX V's are relatively expensive), that will support the necessary Altera IP.

The JTAG to Avalon Master Bridge IP should exist in the web edition of Quartus. Type 'JTAG' in under the IP Catalog.

Cheers,

Alex

By definition, the Altera IP blocks cannot do anything unless the physical capability (in this case, a connection from the non-programmable JTAG logic to the programmable logic blocks) is present on the chip. So the Altera JTAG extension IP megafunction (with its copious collection of additional features) obviously works by somehow instructing the logic compiler and assembler to connect the logic blocks programmed with the IP megafunction to the on-chip fixed JTAG logic blocks.

So the question was how to access that connection ability myself, pairing it with much leaner logic suited to the application.

As for the missing listing in Quartus, I realize now that some obscure document mentioned this might be disabled when the telemetry/feedback component was turned off, which is standard practice when developing my own IP.

As for my requirements, the alternative would simply be to not integrate the two functions and either use additional pins on board-to-board connections to carry both JTAG and private data lines, OR to use a bed-of-nails to do one-time programming of the CPLD and hope there is never a need to field upgrade that part of the design, in which case I can also use a less powerful Max3032 in a 0.5mm TQFP-44 rather than the more expensive to accommodate 0.4mm EQFP-64 package and extra LDO used by Max V.

Supplemental: After temporarily enabling the Telemetry/feedback I have managed to look closer at the official JTAG megafunctions.

1. The megafunction named sld_virtual_jtag_basic seems non-functional, all it does is make Quatus optimize away anything connected to it.

2. The megafunction named sld_virtual_jtag is lean itself, but triggers the inclusion of the sld_hub megafunction, which uses about 80+ LEs, causing a minimum device of 5M160ZE64C5. A lot of that seems to be wasted on one-hot state machines and maybe a non-optimized shadow IR register implementation, there are even messages in Quatus itself about how it could be done better! (look in the compilation report under Analysis & Synthesis, Optimization Results, Multiplexer Statistics, Multiplexer Restructuring Statistics).

3. From some early experiments, I seem to be able to implement the needed sld_hub subset in less than 30 LEs, and I haven't optimized it yet, but this should at least allow me to go from 5M160ZE64C5 to 5M80ZE64C5 (I need room for the main functionality too).

4. The sld_hub ultimately connects to a dedicated hardware "atom" near the UFM (according to the chip planner and netlist viewer). This is named "altera_internal_jtag" and has 4 pins connected to the physical JTAG pins and 4 pins with similar names for the JTAG stuff in logic blocks.

# 4 ("altera_internal_jtag" atom in Max V devices) is what I was looking for, but I still don't know how to invoke it directly, e.g. as a VHDL component or by some other means.