Dude, where are my JTAG pins

Hi Roland,

> I see no JTAG pins on the symbol when I return to the .bdf.

Correct ... you won't see the JTAG ports on your system module.

Same goes for the epcs controller, for example.

> ... a non-visible connection is made between my Nios-II module

> and the JTAG pins on the Cyclone chip.

Correct ... basically ... the connection between the Cyclone JTAG

and the Nios-II JTAG debug module doesn't appear in your system

module symbol.

Regards,

--Scott

So this means that JTAG is hardwired from the Nios-II core and the FPGA JTAG chain ? That is kind of weird because the Nios-II can be mapped anywhere on the FPGA surface, right ? So that would mean that everywhere on the FPGA there are hard wired connections that lead towards the JTAG pins on the FPGA.

Also, (just want to make this sure) : JTAG logic in the Nios-II is not simulated when I run a simulation ?

Bye,

Roland.

Roland,

The JTAG connections to the outside world are hard-wired on the device. However, Altera has (proprietary) logic that allows us to connect to JTAG with things like processors. Nios II, or more appropriately, the debug core if selected, talks to this logic for JTAG connectivity. The same technology is used with the signal tap logic analyzer, which adds no pins to your design, but allows you to do logic analyzer-type activities through your JTAG download cable.

For purposes of simulating the Nios II CPU, with or without the debug core, yes, JTAG is transparent. However, we do include simulation support for our other JTAG peripheral in the kit (the JTAG UART). Note that the simulation support for this does not give you a wiggling TDI/TDO/TCK, but rather, a host-style interface where you can send & receive characters, and Nios gets those from the peripherals; the JTAG logic is hidden.

Ok, that clears things up for me.

Thanks Jesse ! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

I am trying to access the Jtag pins in my RTL simulation also. Not having much luck :(.

I want to test the system level design at the top level with no software interaction in a 'real' system (as part of an automated self-checking VHDL testbench). (And as a software independant check.)

[I've had a look at the PLI and this does not support the SOPC Jtag UART which is what the design I am looking at is using.]

I am thinking that over the Jtag pins is the best option.

Using the System Console to exercise the programmed chip is fine, but to exercise the RTL design what am I supposed to do without access to the Jtag pins?

I feel a little lost :(....

[Also; can somebody provide me with a URL to where the Altera communications over the Jtag port to the NiosII is decribed (serial message and format sent in through TDI for read/write/etc).]

I am new to this sopc thing, but I am thinking if there is not access to the Jtag pins there must be another way to test the complete device at a top level (of the complete device ie: sopc + logic + logic etc).

I would appreciate if somebody could point me in the right direction with regards to this.

All this being said I would kind-of like to see my Jtag pins (from the Jtag Uart sopc component if possible) and 'waggle' them in my testbench. Is this Possible?? Shouldn't this be possible??

Thanks,

Winston.

I suspect there may be a tcl interface to control the rtl of the buried sopc from the top level as there doesn't appear to be any vhdl models for the Jtag interface (and as previously stated you can't actually see the Jtag pins in a rtl simulation anyway).

From my perspective any combination of tcl script / vhdl testbench / both to exercise the individual registers within the sopc from the complete device top level for the purposes of simple writes / reads would be fine :).

Please help :).

Winston.

A bit of reading is in order:

Read the section on the JTAG UART and the "Hardware Simulation Considerations" section:

http://www.altera.com/literature/ug/ug_embedded_ip.pdf

And of course this:

http://www.altera.com/literature/an/an351.pdf

That should get you going

Jake

Thanks Jake

Unfortunately I have thoroughly looked at these documents and I do not feel that they are pointing me in the right direction.

From what I can see the only usefull simulation advice in these documents refers to either at an sopc level (the sopc functionality on its own not as part of a bigger design) or physically exercising the design in the actual hardware.

What I am after is some way to drive the (invisible) Jtag pins from the device top-level (with the sopc block buried within the device) for the purpose of simple software independant sopc register writes / reads during an RTL simulation.

This is required as part of our system testing (and follows a standard design flow).

I assume there is some method of doing this by using the RTL testbench, a tcl script, or a combination of the two. The trouble is I cannot find any information on this.

Using command windows like system console is fine for testing the physical hardware implementation. However I cannot find a way to do this under RTL simulation conditions (I have looked at the PLI, but it is not supported for the sopc Jtag UART).

I am sure the information I need exists somewhere but I cannot find this in any of the multiple searches that I have done.

Please advise.

Thanks,

Winston. :)

Is there out anybody out that tests the nios II at a system (complete device) level with an RTL simulation? (or 'real' SDF timing).

Surely this is part of a 'standard' SOPC design flow.

How else would verification with 'real' SDF timing be achievable without having a method of doing this?? It would be impossible any other way in my eyes and surely this is something that needs to be covered for anything that is timing critical.

Please enlighten me. Somebody....