Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

Missing virtual jtag documentation

Hello,

I started to use the sld_virtual_jtag Megafunction for low level debugging puposes, using Tcl interface with quartus_stp. Now I'm considering possible operation with non-Altera JTAG interfaces. The virtual jtag user guide says:

--- Quote Start ---

If you are building a debugging solution for a system where a microprocessor controls the JTAG chain, the SignalTap II embedded logic analyzer cannot be used because the JTAG control has to be with the microprocessor. By learning the low level controls for the JTAG port from the Tcl commands, you can program microprocessors to communicate with the sld_virtual_jtag megafunction inside the device core.

--- Quote End ---

Does this mean, instead of documenting the coding of virtual jtag ir and dr shift instructions, Altera suggests to "hack" the information from Tcl operation by applying the

-show_equivalent_device_ir_dr_shift option? Sounds somewhat silly to my opinion.

The point is, I can easily learn the commands to assemble the virtual ir and dr shift instructions for a fixed virtual jtag configuration from this method. But the configuration may change and other virtual jtag node types (stp, source&probe, in-system-memory) can be added and modify the virtual jtag node configuration. I would prefer to have a tool, that is able to identify virtual jtag instances from read-back node configuration as quartus_stp obviously does.

This would imply understanding the jtag hub programming to some extent, which Altera apparently didn't wanted to disclose up to now. I don't see, that this information, effectively present at users fingertips, should be classified confidential.

Best regards and Merry Christmas

Frank

30 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    I'd file an SR on this. I don't believe there is anything available for doing your own interface(I started down this path once before when it first came out and didn't uncover anything.) I assume the interface was made to be easy and powerful(which it is, and covers probably 95% of the user cases), but it seems like it was never created for your own customer controller. I don't know if this is because they didn't want the support burden(which I'm sure there is due to all the things you mentioned that use JTAG), or they didn't think of it, or what. But if you file a request at least they know users are asking for it.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hello,

    you guessed right so far, Altera support stated:

    --- Quote Start ---

    Unfortunately there is no document to describe the detailed infrastructure operation codes for virtual JTAG Megacores.

    --- Quote End ---

    They suggest to use -show_equivalent_device_ir_dr_shift option to evaluate the command coding.

    But I think, virtual jtag interface operation can be basically understood. Some information is shown in Quartus report files, e. g. the jtag hub's node_info data. This info is read during virtual jtag node enumeration by Quartus tools and shows the number of connected instances, each node type and virtual ir register length. The node index and select bit coding results implicitely from node_info data.

    Best regards and Happy New Year!

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hi,

    --- Quote Start ---

    But I think, virtual jtag interface operation can be basically understood. Some information is shown in Quartus report files, e. g. the jtag hub's node_info data. This info is read during virtual jtag node enumeration by Quartus tools and shows the number of connected instances, each node type and virtual ir register length. The node index and select bit coding results implicitely from node_info data.

    --- Quote End ---

    Seems you find out how this "enumeration" is performed. Would you mind share your finding?

    I have the same problem. The "-show_equivalent_device_ir_dr_shift" tells you how to implement the "virtual" shifting. But it doesn't tell you how to enumerate the virtual instances and get the info for assembling the virtual IR value and length.

    Guess not too difficult to "reserve engineer" sniffing the JTAG transactions. But you would save me a lot of time if you already did that.

    --- Quote Start ---

    which Altera apparently didn't wanted to disclose up to now. I don't see, that this information, effectively present at users fingertips, should be classified confidential.

    --- Quote End ---

    And not disclosing USB Blaster protocol seems even worse. Fortunately somebody reverse engineered the USB Blaster already.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hello,

    to my opinion, gathering information scattered in the available documentation and watching JTAG scan codes shouldn't be regarded as "reverse engineering", at least in a legal sense. As Altera recommended, I used Tcl programming to learn about virtual JTAG. The appended Tcl example shows how to read virtual JTAG node info this way.

    To access Altera programming hardware with own tools, it would be most convenient to use the high-level interface apparently existing with jtag_client.dll as Terasic does with some JTAG tools. But's it's also undocumented.

    Regards,

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Thanks again Frank, I think I have the "whole picture" now.

    Yes, documenting the Jtag client API would be very nice. Altera seems to have lots of undocumented/undisclosed issues that doesn't make much sense. Some time ago, just out of curiosity, I tried to find the Nios Debug/OCD specs. Couldn't find not even a brief description.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Yes,

    I had already been pointed to it by another forum member. It's identical also to the US application document US2004/0098638.

    To my opinion, the description part can be used as a programming handbook for the virtual JTAG interface, as far as I previously checked, everything is implemented exactly as described, e.g. the HUB commands and the HUB_INFO coding.

    Regards,

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I don't suppose any documentation exists with regards to this yet does it (official or unofficial - I don't care).

    I would like to talk to a device over the JTAG port in an RTL simulation if possible and from what I have seen this could be a potential solution.

    Nobody through the 'regular' Altera support network seems interested in helping.

    My FAE has talked to several Altera guys and they are saying that my options are either :

    1. - ripping out the complete SOPC build and putting in a Avalon BFM,

    2. - using system console on the programmed device.

    That is it!

    Surely this isn't the case. Is it??

    As a large part of our design is the SOPC itself, ripping it out will not be overly helpfull.

    I have also spotted the Beta (unsupported) PLI. But this does not support the SOPC JTAG UART (which our design uses).

    Can the virtual JTAG be used for this as an external BFM somehow to interface with the *invisible* JTAG pins on the device?

    Or is there an API type function that can be used with the virtual JTAG (or stand-alone) to do this?

    Ideally I would like to control this with a combination of my VHDL testbench and/OR some TCL scripts.

    Please can somebody point me in the right direction with regards to performing RTL sims on a buried SOPC (doing simple reads and writes of registers). any options would be good right now :).

    If ANYBODY out there can help with this I will be eternally gratefull.

    Thanks in advance,

    Winston.