Missing virtual jtag documentation

[Altera_Forum]

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

[Altera_Forum]

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]

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]

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]

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]

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]

Hello, 

 I too am trying to get somewhere with this. It looks like Altera has a patent on the JTAG HUB: EP1420351A3  http://www.freepatentsonline.com/ep1420351.html  Cheers, Ian Barnes.

[Altera_Forum]

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]

Thanks Frank, in fact the US patent I was able to find online - and it had a lot more information that the other one I mentioned. That is pretty much what I needed to know. 

 http://www.pat2pdf.org/patents/pat20040098638.pdf

[Altera_Forum]

I see, that I didn't read your post exactly. EP1420351A3 is a supplement, the full application is EP1420351A2. The text is also available athttp://ep.espacenet.com

[Altera_Forum]

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.

[Altera_Forum]

Up to now, I believed the documentation statement, that virtual JTAG functionality is not supported for simulation. If it's true, you have to replace (or supplement) the JTAG interface by user logic in the SOPC IP to get simulation access.

[Altera_Forum]

Thanks for your super quick response :). 

 It seems to me that you have been looking at this also (but at a MUCH deeper level than myself :)).   Given my scenario, what direction would you suggest I pursue (I would prefer not to modify the actual hardware if I can avoid it).   Thanks again,   Winston.

[Altera_Forum]

Actually I don't use virtual JTAG with SOPC, I only tried to understand the architecture. Unfortunately I have no detail suggestion.

[Altera_Forum]

Are you trying to simulate the VJI because it has bugs, or just replicate what you're doing via VJI to get the system to work(i.e. read and write some registers)? Since VJI ends up having you create the final layer of logic i.e. your instruction and data chains within the fabric, why not just have those be your interface for your commands, i.e. during simulation have those registers just appear(and don't include the actual VJI guts in your RTL sim). My guess is that will run much faster than taking hundreds of clock cycles to serially load in a single command.  

A problem with having an RTL model for VJI is that it would be a model up to the JTAG ports on the FPGA. There is a large gap between the Tcl commands you type in the console and how those get translated to TDI ticks. Whatever was done would be slow and would certainly not be cycle accurate with how your computer software operates. I think just removing the VJI directly would be the best bet.

[Altera_Forum]

I'm after a method of doing some simple reads and writes to the SOPC core from within modelsim (preferrably using the JTAG interface). I think that I will need to use the (V)irtual (J)TAG (I)nterface to do this.  

 It is my understanding that I instantiate the VJI as a BFM external to my Device Under Test and I then drive this by a series of TCL commands to perform the functions I need to do (ie : simple reads and writes to setup registers and read back values). or Does the VJI need to be part of the design?    The current design (which I am not in control of) uses the SOPC JTAG UART. I would want any internal logic to mimic the actual hardware (is there a model for the SOPC JTAG UART with the VJI available somewhere to accomplish this).    I just (!) need to talk with this within an RTL simulation somehow and it doesn't appear very clear how to do this.   If I can I want to do this without modifying the actual design logic, but is this possible??   Speed isn't especially an issue with this.   also   Once I have decided on a method to achieve my desired control, where do I access the appropriate documentation (and examples if possible) that tells me how to do this?   I am new to this SOPC thing (and NIOSII), and would appreciate being pointed in the right direction.   Many thanks,   Winston.

[Altera_Forum]

Note that I was explicitly talking about VJI, which I did in one design many years ago. This is a way to get signals into the FPGA through JTAG from a Tcl console. It is not the same thing as the SOPC JTAG UART(I'm sure the underlying parts are the same, but the UART it built up quite a bit more than VJI). The VJI, I believe, is for people who want to access the internals of the FPGA independently of SOPC Builder. It doesn't get used a whole lot because it requires you to build the end logic in the FPGA(which, when it does get used, is exactly what hte user wants). You might want to try nioswiki.com.

[Altera_Forum]

I think that insisting in using VJI for simulation purposes only, when VJI won't be used at all in real hardware, doesn't make much sense. 

 One of the main problems of simulating JTAG, is that the Altera model doesn't bring the JTAG signals to the top level. Actually, the JTAG interface is modelled as a black box silicon without any connection to the outside world. That would be tricky to simulate.  I would instantiate a custom SOPC component, which could be even your own version (for simulation purposed only) of VJI. Or even your own version of JTAG UART, if you prefer. Forget about any actual JTAG protocol, there is no need for it.  Then use simulator specific tools to access registers in that custom SOPC component. For instance, ModelSim would let you access buried signals from your testbench.

[Altera_Forum]

Is it just me or does anybody else think that this is a serious oversight from Altera. Why they don't just they let you see the actual JTAG pins is beyond me?? 

 At this stage I am thinking that maybe it is worth replacing the SOPC JTAG UART with the Avalon BFM for simulation purposes.   However this would mean that the actual design post place and route would not have the ability to have back annotated SDF timing simulations applied to it.   For a worst case timing/temperature/etc I have always been told that this is a necessary part of sign-off.   Ideally, I am after a solution for this which talks with the ACTUAL design so that you can then run both RTL and back annotated timing simulations in Modelsim.   Does anybody have any further ideas??   How do other people do this? or Is it just NOT possible with a NIOSII design??   Its a bit bad if this is the case in my eyes...

[Altera_Forum]

Hey Guys, 

 I have read through the forum and some of the thread regarding virtual jtag but I still can't find anything that I need.  I have implemented a design using VJI to basically program flash devices that are connected directly to the fpga. I have compiled the design and downloaded the design into the fpga hardware using Quartus II programmer.  Now, I try to establish run time communication with the VJI by using the quartus_stp package in tcl command. More specifically, I try to use the device_virtual_ir_shift and device_virtual_dr_shift command to shift in the values that I want into my boundary scan cells.  I first tested the design and the device_virtual_ir_shift and device_virtual_dr_shift command on my DE0 evaluation board and everything worked fine.  Then I try to implement the design into my own custom PCB which has the Stratix II FPGA. I connected the PCB to my PC using the Terasic download cable adapter, which has USB connected to the computer on one side and a JTAG connector to my PCB on the other side.  Now, I try to use the Jtag Chain Debugger in Quartus Programmer and it detects the FPGA successfully. I am also able to download my design onto the FPGA hardware through the quartus programmer successfully as well.  However, the problem happens when I try to access the VJI using tcl command, the device_virtual_ir_shift, device_virtual_dr_shift. I get an error message saying :"ERROR: The specified virtual JTAG instance cannot be found".  I read FvM's test_vji.tcl.txt about the HUB_INFO instructions and getting all the NODE Information by doing the following once I have opened and lock the device:  device_ir_shift -ir_value 14 -no_captured_ir_value  device_dr_shift -length 64 -dr_value 0000000000000000 -value_in_hex  device_ir_shift -ir_value 12 -no_captured_ir_value  device_dr_shift -length 4 -dr_value 0 -value_in_hex (doing this n*8-1 times, depending on the number of node)  Now, all I get returned back to me when I shift those nibbles is F, but when I tried it on my DE0 board, it returns the appropriate values like 08086E04 and 00406E00 (I only have on node in my design).  Can you guys please help? I know I typed quite a bit but hope everything is clear. Let me know if further clarifications is needed  Thanks You So Much, Jack

[Altera_Forum]

From my experience the JTAG PLI in association with the VJI only seems to work for certain scenarios of internals and although the device will be recognised you will not be able to talk to it. 

 I gave up in the end and am now talking to the internals of my design in simulation via an existing uart...   Good luck :).   Winston.