longest webcase record

Jim

Unfortunately we haven't purchased the jtag debugger option where you can manually tri-state and read the state of pins so injecting my own levels is not easy. However your quite right, it is fast coming to this and I am going to end up with adding a couple of 0R resistors so that I can remove them and drive the net myself.

Col> col>

Funny, I think I understood what you were asking by your second post here. I don't know why Xilinx does not understand. They seem to want to answer the wrong question and then when you tell them they answered the wrong question they seem to think *you* are the one that misunderstands.

I have seen this more than once and with more than one person at Xilinx. I don't know if it is a corporate culture thing to not be willing to reexamine their thinking or if it is just the individual people, but I have seen this on numerous occasions.

Perhaps if you asked in an extremely detailed way that left no room for misunderstanding? Specify the pin number of the signal you are using to keep them from thinking you are using SSTL on the JTAG pins. Ask specifically what the threshold level will be on that pin during boundary scan after you have loaded the configuration. *Do not mention any other information that you may think will be helpful if it is not required!!!* Any stray info can result in misinterpretation. I have seen many times that the mention of a piece of information that should help to clarify your thinking actually results in alarm bells going off on the other side and the discussion goes way off course.

Good luck!

col> Jim

rickman - I give you kudos for understanding what colin is trying to achieve. I've watched this thread and I'm still confused. My engineering career started in manufacturing where I had extreme interest in boundary scan. Yet, I'm stymied.

The issue of IO standard is external to any registers in an internal scan chain. I couldn't figure out if there was a need to interface to the jtag chain in SSTL logic or if there was a perceived internal need for the jtag chain to be driven by SSTL to scan SSTL I/O cells.

If the scan was 1) desired before configuration, 2) designed to drive, receive, or tristate signals based on the scan chain, or 3) use the existing configured design, this casual observer still has no clue.

It seems there are assumptions that aren't discussed in setting up the problem that needs to be solved. Often, assumptions can be determined from the context. If these underlying assumptions are guessed incorrectly, the wrong question is answered.

So - any idea what's really needed?

I will explain what I think is going on and Colin can correct me if I am wrong.

They are using a Coolrunner II to interface to an SSTL device. The CPLD is first configured, then they want to run boundary scan to test the board. In order to assure their customers that boundary scan will properly verify the connection to the SSTL device, they want to verify that during boundary scan the CPLD will be using SSTL voltage levels on the pin that connects to the SSTL device. This is not one of the JTAG pins, it is just a general IO pin.

So the question is, will this pin use SSTL signaling during boundary scan if it is first setup as an SSTL IO during configuration?

Is that clear?

I fully expect the answer is that the pin will be using SSTL voltage levels during boundary scan. But I can see where the OP would want to ask to make sure. You can never be too sure how chips work internally regardless of what seems obvious.

Thanks for responding Rickman, I was begining to wonder about my sanity.

To answer John_H, Austin has replied in a new thread :) that I should only boundary scan post config :-

-When configuration cannot be prevented

-When differential signaling standards are used"

I had seen this before but SSTL is not differential. In fact Coolrunner II use standard IO pins to become the vref inputs, needing to use one IO for vref for every 6 SSTL inputs. Also the vast majority of Xilinx cocumentation is FPGA centric without expressely saying so.

Rickman, the vast majority of webcases are hand holding of new users. It doesn't matter how loudly Xilinx shout RTFM that is what the user has not done. I allways expect to spend a few days getting Xilinx support to understand that my question is not trivial and your not going to change human nature which is not Xilinx induced. Allthough perhaps changing a usenet thread title to something that is ultimately embarrassing is a lesson that might not be forgotten.

Col> John_H wrote:

I don't think there is much you can say in this newsgroup that will have an impact on what Xilinx does. What you have seen so far is the typical response when they don't understand what you are saying. Rather than admit they don't get it, you get the sort of undignified responses you have seen.

The hotline is not terribly good in many respects. The first person you get is typically a newbie, that's why their on the hotline, they can't do a lot else. You have to convince that person that the question is over thier head before you can move to the next level, and repeat the process. My experience has been that the first two levels of support can only provide info that Xilinx has published somewhere. To get an answer to a unique question like you are asking, you need to reach the third level of support. Think of it as a video game!

If you really want a surprise, the person who has been replying without understanding what you are asking, is the person who is over the support group. Does that make you feel any better?

Colin,

With regards to being the longest webcase, if you don't see the "record overflow" message in the Webcase viewer, you've still got a ways to go :)

I've hit 3-4 months, without ever getting definitive answers, and CR's and documentation errors still unresolved 3.5 years later.

Answer Record 15346 states that the I/O behavior changes post configuration to match the I/O standard for 'most' families- perhaps you should point Xilinx at that Answer Record and ask them to explicity define if 'most' applies to CoolRunner-II : " " For most Xilinx device families, the boundary scan architecture " changes after the device is configured because the boundary scan " registers sit behind the I/O buffer and sense amplifier: " " BSCAN Register -> IO buffer/sense amp -> PAD " " The hardware is arranged in this way so that the boundary scan " logic operates at the I/O standard specified by the design. This " allows boundary scan testing across the entire range of available " I/O standards "

Also from 15346, re. the I/O behavior of p>

Austin's selective quoting of that page would read quite differently had he also included the surrounding text: " " Whenever possible, boundary scan tests should be performed on an " unconfigured Xilinx device.Unconfigured devices allow for better test " coverage, since all IOs are available for bidirectional scan vectors. " " Boundary Scan tests on Xilinx devices should only be performed after " configuration under the following circumstances: " -When configuration cannot be prevented " -When differential signaling standards are used " " Mandatory modifications " If a post-configuration BSCAN test is required then the BSDL file " must be changed. Currently the user will have to manually modify " the BSDL file as per answer record 6664 . "

Brian

Although there are other considerations in choosing an FPGA vendor, support is one of those things to consider. Perhaps you should consider suppliers other than brand X.

KJ (not representing any FPGA suppliers)

All,

I posted that quote because it actually did (but very poorly, I agree) state that after the device is configured, the pins assume their new configured standards, and states.

The tech answer is slightly better written, but is goofy as to say "most" or "almost all" which is pretty useless (just poor writing).

The issue is that since the BSDL file is only accurate before configuration, there is a "recommendation" NOT to use boundary scan after configuration, because you need to then create a design specific BSDL file to use any of the JTAG scan software tools out there. And, since we don't have software to do that, we just say "don't do that" rather than explain why.

Peter and I will see about rewriting this so it makes better sense.

In no way does my post suggest that you 'RTFM': rather, I spend a lot of time to search for information, and post where I found it. Just because I read very fast in no way suggests that I think you could have, or should have, found this information. Again, please do not put words in my mouth!

I still have no idea if this is the "answer" to the "question" Colin posed originally.

Austin

Err Austin, you do have a tool to do that, it is called BSDLANNO.exe and comes as standard with webpack. See previous posts, you give it the output of your design and the original BSDL file and it creates a bsdl that reflects your programmed CPLD.

My original support question was, will pins that are functionally SSTL output only, be SSTL input during JTAG, to be told that once functionally an output then its only an output for jtag. I then disproved that by creating a pinA

Colin,

So, the device should take on the new configuration for the IO standard once configured. Yes?

JTAG or normal IO use should not make any difference: the IO pin can not revert to the default programming just because JTAG is in use?

Is this what you have confirmed? Yes, or No, please. I already know my mind doesn't work the same as yours.

Austin

col> Aust>

I don't think it is a matter of minds working differently, they are mostly the same with a few differences in left/right organization. The important issue is to read what is being written in enough detail to get what is different about the thoughts.

"My original support question was, will pins that are functionally SSTL output only, be SSTL input during JTAG"

I believe what he is asking about here is whether a pin that is configured for output only as set up in the JTAG configuration be capable of bidirectional testing using boundary scan. I would expect the answer to be, "it will work in either direction during boundary scan". But I can see where he would have some concern about this since the pin will be working in the SSTL voltage levels that are configured by JTAG. So will the configuration also limit whether the pin can be boundary scan tested by both input and output?

Okay guys this is where I'm at and this is what I'm going to do.

I have several pins which are functionally SSTL output which are connected to a device which can do bidirectional JTAG and you get better test coverage if both ends of the net get a go at receiving.

I'm going to add two pins which I can easily spare, one as an input tied low and one as a floating output. The input will be used to drive the OE of the above output pins. The output pin will be a simple AND of the above pins. This guarantees that the outputs become bidirectional with no logic getting minimsed out.

The pins are now bidirectional and so I will need three new pins to be used as VREF pins for the SSTL levels. I can't easily afford these three pins, it forces me to have another bank at 2.5V instead of 3.3v which was the entire reason for ever asking the question (I expected a very quick yes or no).

I've just re-read the whole thread and I appologise for side-tracking the issue talking about ouputs becoming IO during jtag (which I did not do straight away). Clearly the cpld needs to be routing vrefs to an IOB to work as an SSTL input.

Colin