longest webcase record

I suggest you open a webcase to find the answer to your question. HTH, Syms.

I've got a couple with Altera that have been open for well over a year now....the clock is still running.

KJ

trust me, "Open" is better than "closed" with the notation of something like "will be addressed in next major release". Once they get a CR assigned, they go into a black hole.

Colin,

Are you trying to interface to the JTAG port using SSTL drivers and receivers? If so, then this is an interfacing question (and one that can be answered in 60 seconds with a simulator), and really has nothing to do with boundary scan at all.

If you post the part family (eg Spartan 3E), and the SSTL interface class and supply voltages, I can run the simulation, and see if it works.

Austin

I agree. But I have an even bigger complaint about the whole webcase system.

We use a lot of Xilinx parts, and occasionally we run into problems. We generally only use webcase as a last resort, as I hate to clog up their system with simple cases. So sometimes we find a problem and a work-around ourselves. This information should be valuable to Xilinx, so I open a case to tell them this. My frustration is that the basic response is "So you have a work-around? Case closed!" This info goes into the same black hole.

My most recent example:

We are using a lot of spartan 3E parts, with the BPI mode configuration

- which is awesome for our application. The early parts (stepping 0) had an issue where JTAG configuration would fail if the FPGA is set to BPI mode and the attached memory had a valid bitstream. The datasheet says that this has been fixed in stepping 1. We have never had any stepping 0 devices so we ignored this issue, but it turns out that it is still present in stepping 1. This wasted a lot of our time until we figured out what was going on. Xilinx has two suggested work arounds, which both work, but weren't good for our application. Now we are in production and the JTAG interface is not needed (as it was used for development only), so this is no longer an issue for us. I figured that Xilinx would like to know that this issue was not fixed in stepping 1, and that they still have an issue with their silicon, so I opened a webcase. But I basically got the response I mentioned previously: "So this isn't a problem for you? Case Closed!"

I opened the case in August, and the engineer ran an example design himself and then ended the case with:

"I let the Spartan group know that this problem still exists in Stepping 1 parts. They are looking into why this is not fixed. Since you are ok with the workaround and expressed that this is not a problem. I am going to go ahead and close this case. Please feel free to open up additional cases if need be. Thank you."

No, it isn't a problem for us, anymore, but there should be some sort of errata posted ASAP so that other customers do not run into the same problems we did. I gave it some time, but I still don't see anything, so I am posting here.

Xilinx's system is broken, as they have no good means for customer feedback. So I am hoping that comp.arch.fpga might work better than webcase?

Jason Daughenbaugh

Austin

I have a coolrunner II with some pins which are functionaly (after programming) SSTL. I want to perform boundary scan (interconnect) testing and I want to know whether the CPLD will do it using SSTL or CMOS logic levels on these pins.

I am aware that CMOS levels will work but for marketing reasons it would be much better if they were SSTL.

I talked about BSDLANNO because xilinx support said that once a pin is used as an input or output that is all it will do during boundary scan but the BSDLANNO documentation and a quick experiment on my part says otherwise. (I created a design with pinA Colin,

snipped-for-privacy@gmail.com schrieb:

JTAG BPI S3E issue - there is a solution that fixes the problem the external flash memory can be put into status read mode using CFI commands and boundary scan, then the JTAG can be used to work with the FPGA as if there S3e bug wasnt there. Its a bit tricky but working solution.

Antti

I like your solution. Clever!

Does this mean that you ran into this problem too? Do you see it with Stepping 1 as well?

Jason

So, you wish to drive a LVCMOS input from a SSTL output?

If this is what you are doing, at 2.5 volts, then if the CPLD is programed for SSTL class I, and there are no resistors used (no terminations), then the SSTL output is compatible with the LVCMOS input.

This can be simulated with any signal integrity simulation tool (like Mentor's Hyperlynx) in about 60 seconds (which I did).

To really know, and to be absolutely sure, I would need the part number and manufacturer of the CPLD, and the IBIS file for the SSTL output (I used the SSTL_I output for a V4 FPGA).

I think I understand the hotline's confusion now. Your boundary scan has nothing to do with JTAG. How confusing, as the only context that we have heard of boundary scan in, is JTAG.

Austin

Austin

I'm fairly sure that you understand most/all of this but you have suggested to the world that I don't...... :-)

I am using a third party boundary scan tool from assett intertech which uses the JTAG port to twiddle pins on certain devices and read back the values on other pins on the same net so yes I'm fairly certain that I'm using JTAG.

If the coolrunner II is not programmed then there is no confusion, one uses the bsdl file provided by xilinx which defines the jtag behaviour of the device and the coolrunner will drive outputs and receive inputs as CMOS to the value of whatever I have set VCCIO to for that bank.

If the coolrunner has been programmed then there is a tool from xilins called BSDLANNO which looks at the fitter output and the original bsdl file and creates a new bsdl because inputs are input only for jtag, but outputs can be IO still for JTAG. your tech support took a week to tell me that outputs are output only for jtag so 13 days ago I showed them the bsdlanno documentation and they said they would get back to me.

There is no issue with SSTL receiving CMOS because CMOS drives rail to rail (2.5v) which is what the SSTL driver does. However a CMOS receiver threshold is somewhat different to a SSTL rx threshold which means there is not as much (I said it was a marketing thing) noise immunity by the time the sstl signal has gone through the sstl termination scheme. My question is therefore what do I do to ensure that my boundary scan gets done using sstl levels. Now waiting 3 weeks for this bit.

Colin

Aust> So, you wish to drive a LVCMOS input from a SSTL output?

snipped-for-privacy@gmail.com schrieb:

Thanks!

I developed this solution in order to provide flash programming solution for the "s3e sample pack" it works nicely.

I cant comment on stepping 1 as I have no s3e boards with nr flash so I can not test it.

Antti

Colin,

Do not use any termination.

If you use any termination at all, it will not work.

That simple.

If you don't use any termination, you may get reflections, and that might be a problem, too.

Get Hyperlynx, and run the simulations yourself.

Aust> Austin

Austin

All I need is someone at Xilinx to tell me where the scan cells are in the IOB. I'm fairly certain that they are in a simillar place to where ALTERA clearly document them otherwise it would slow down the pin. I'm almost certain that the pin will be SSTL for JTAG if I make it SSTL functionally.

Your asking me to cripple a design functionally for the sake of the right person at XILINX answering the question. If I make the whole design CMOS then I can use a MAX II which I can power from 2.5v without needing a vreg to 1.8.

Regards, in total exasperation

Col> Colin,

Colin,

Where are the scan cells? What does that have to do with anything whatsoever?

The scan cells are where they are convenient. The scan chain is wired to the JTAG controller, and the JTAG controller is wired to the JTAG pins.

Since I seem to be completely unable to help you, I apologize, as I think I am answering your questions, only to have you be frustrated, and ask me a seemingly completely unrelated new question.

Perhaps I should quit, right now, and trouble you no further,

Austin

I think the OP is questioning how the device programming affects JTAG ? He mentions before programming, and after programming.

If you are going to JTAG-scan a post-pgmd full system, I'd say it helps to know which are IPs (to prevent accidental drive)

- I'm guessing that's what BSDLANNO does ?

My understanding of bondary scan is that once you are in that mode, the config fuses actually don't care, and the system does not know if the device is new/blank/pgmd, so scan is the same in all cases.

I think Colin is trying to confirm that, but with modern devices with many IO options, it is not a silly question - and one could argue that ideally, post pgm scan _should_ use the Pin-option information. (but I don't think it does, on anyones CPLDs - correct me if I am wrong ? )

-jg

Jim Granville schrieb:

Jim,

the boundary scan with Xilinx silicon is *NOT* the same before programming/configuration and after.

the effects how the IO programming affects the boundary scan behaviour is(or can be) different per cpld-fpga family, so I assume some missing description of this behavior is what causes issues to the OP.

Antti

Austin

I have just pulled up my copy of IEEE1149.1 to check my terminology

The proper name for a scan cell is "boundary scan register cell" and this is almost allways shortened to scan cell. Your CPLDs have them at every IO pin (and also some which drive programming). They are what is shifted out on TDO if your TAP controller (which is what can be placed wherever is convenient) has been placed into the correct state. If the input to the scan cell is before the VREF comparator then clearly I can only do CMOS levels, if it is after the VREF comparator then hopefully I can boundary scan with sstl.

I think you will find that I have been asking the same questions, just each time assuming you know a little less.

Col> Colin,

A better question might be to ask if the cell IO config fuses apply to/during the boundary scan - and also specify the CPLD device exactly, as Antii's reply suggests the answer depends on family..

-jg

Jim

I'm using a coolrunner II (which I said in my first email). I think they are the only CPLDs that support SSTL but if anyone knows of another familly then I'd love to take a look.

I'm fairly certain that the IO config isn't removed during boundary scan because I can read the functional state of pins using JTAG and so can chipscope for FPGAs.

Col> col> > Austin