Xilinx / Altera TCLK termination (Pull up or down)

To enter JTAG, the TCLK pin is sampled on the rising edge. With Altera devices, the TCLK pin is pulled low and the other JTAG pins are pulled high to prevent sampling of the clock. Looking at XAPP501 and others it appears Xilinx is using a pull-up. This would seem to be a possible source for problems. Is this really what Xilinx is wanting, or is there a problem with their documentation?

Thanks

Reply to
lecroy7200
Loading thread data ...

Hi, both pull-up or pull-down will be OK. The goal is to prevent an undefined (floating) level on TCK pin.

The difference between the use of pull-up or pull-down will be on the power-on of the target board.

Using a pull-up, you will generate a max 1 clk. Anyway, this 1 clk will not be able to do something wrong in the JTAG TAP controller of any device.

Anyway, when starting an JTAG communication (for debug or boundary scan), the first thing you will do is to do a soft-reset of the JTAG TAP by driving 5 clk with tms '1'.

Regards, Laurent Gauch

formatting link
___________________________ Unlocking the power of JTAG

------------ And now a word from our sponsor ------------------ Do your users want the best web-email gateway? Don't let your customers drift off to free webmail services install your own web gateway!

-- See

formatting link
----

Reply to
Amontec, Larry

Laurent,

I am looking at page 5-2 in IEEE 1149.1 93 section 5.1.2. There is a statement "No matter what the original state of the controller, it will enter Test Logic Reset when TMS is held high for at least five rising edges of TCLK. The controller remains in this state while TMS is high."

And I would agree with you had I never worked with JTAG before, but in my limited JTAG coding I have seen devices that will enter this state on one clock. The Motorola 306 for example. I don't know about the internals of the Xilinx parts. Maybe all of their devices require the minimum of 5 edges to enter test mode. Does anyone know that this is for sure the case? Why run the risk pulling it high?

Reply to
lecroy7200

snipped-for-privacy@chek.com wrote in news:1110249759.373411.51880 @z14g2000cwz.googlegroups.com:

The JTAG state machine is organized such that it will always return to the Test-Logic-Reset state in at most 5 TCLK cycles if TMS is held high. Depending upon what state it is in, it could arrive at Test-Logic-Reset sooner than that, but it will never take more than five.

Why run the risk pulling it high?

--
----------------------------------------------------------------
Dave Van den Bout
XESS Corp.
PO Box 33091
Raleigh NC 27636
Phn: (919) 363-4695
Fax: (801) 749-6501
devb@xess.com
http://www.xess.com
Reply to
Dave Vanden Bout

"The JTAG state machine is organized such that it will always return to the Test-Logic-Reset state in at most 5 TCLK cycles if TMS is held high."

Again, this is not what the specification states. "At most" would be a maximum, "at least" is a minimum.

"No matter what the original state of the controller, it will enter Test Logic Reset when TMS is held high for at least five rising edges of TCLK"

If it could reach test mode on one clock, I can see where this could be a potential problem.

Again, I just want to make sure that Xilinx has done their homework on this and that pulling the clock pin high will not introduce problems on any of their devices.

Reply to
lecroy7200

snipped-for-privacy@chek.com wrote in news:1110552324.463013.313590 @l41g2000cwc.googlegroups.com:

It depends upon your viewpoint. If you look at it from the standpoint of the TAP controller, you see that it will take at most 5 clocks to get yourself from any state back to test-logic-reset. If you look at it from the standpoint of the system designer, you see that you will need to provide at least 5 clocks to guarantee that the TAP controller is in test-logic-reset (provided you have no knowledge of the current state of the TAP controller).

If I were you, I would stop parsing the text of the document (which can be fuzzy) and go directly to the TAP controller state diagram (which is not):

formatting link
state-machine-large.png

--
----------------------------------------------------------------
Dave Van den Bout
XESS Corp.
PO Box 33091
Raleigh NC 27636
Phn: (919) 363-4695
Fax: (801) 749-6501
devb@xess.com
http://www.xess.com
Reply to
Dave Vanden Bout

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.