Xilinx Platform Cable USB protocol specifications and/or open-source firmware replacement

The iMPACT software works with other devices in the chain by allowing you to specify a BSDL file for the device when it doesn't recognize it. The iMPACT software also allows you to generate arbitrary JTAG sequences in order to do anything that you want to do. If you want to generate a program to improve your ability to do this then run iMPACT in batch/command line mode and have your program control iMPACT.

I would also suggest using a product like Universal Scan

formatting link
I've not used it personally, but I did have a conversation with the principal developer a few years ago and it seems like a nice light weight tool to do exactly what you want to do. I think that it might be Windows only though.

Or, if the pins that you want to toggle are from a Xilinx device, then I would suggest using ChipScope Pro with a VIO (Virtual I/O) core attached to the pins for an even simpler product and it includes FPGA configuration capabilities. ChipScope Pro does work on Linux.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan
Loading thread data ...

Why? Xilinx doesn't have a copyright, trademark, patent, or trade secret on their USB vendor ID. I don't recall that I've ever signed a contract with Xilinx (or anyone else) stating that I would not use the Xilinx USB vendor ID for something else (e.g., a Xilinx-compatible cable).

Anyhow, you could always ship a product with some other USB vendor ID, and supply a tool that allowed the user to change the vendor ID to any numeric value of his or her choice.

Reply to
Eric Smith

Doesn't work on 64-bit Linux. Jungo supports 64-bit, but Xilinx only supplies 32-bit versions of the proprietary binaries that get linked to the Jungo code.

Please, please, please support 64-bit Linux in 8.2i, or at least in

8.2i SP1.

Thanks! Eric

Reply to
Eric Smith

Hi Ed,

thank you for your reply and setup suggestions. Unfortunately this only partly addresses my wishes. Just two (and a half) examples:

1) Think about a development board, that connects to a host PC via USB or Ethernet. It would be nice, if a vendor could supply a driver, and integrate the board with Impact. To do so, Impact would need to be able to talk to third party JTAG drivers. As board vendors cannot do this, every vendor is forced to provide his own configuration tool- which is really not the way things should look like.

2) When talking about pin toggling: I am not talking about a few toggle events, which I could do with a GUI. I am looking for an environment, where I can program complex toggle sequences. While I am happy to do the development of the required JTAG library myself, I would need to be able to access the JTAG cable easily. It would be nice to use the existing Xilinx cable- unfortunately the API is not disclosed.

3) Now think about a reason to combine both of the above setups without switching cable hardware, setting jumpers and changing flying leads...

Ed, I do understand that this kind of applications is not your primary interest. Still, it does not always help here to try and teach the engineer to do it a different way, as there are probably good reasons, why the engineer wanted to do so. While a technology leader will definitely need to do some evangelism, it is sometimes a nice marketing approach to listen to the customer (even if it is a smaller one).

Best regards, Felix

--
Dipl.-Ing. Felix Bertram
http://www.bertram-family.com/felix
 Click to see the full signature
Reply to
Felix Bertram

Ed ... you missed the point. JTAG is "supposed" to be an open standard interface, usable for a large number of in system interfaces, and Xilinx is turnning it into another proprietay closed interface with VERY limited static sequences exported to the user.

Consider that JTAG is the ideal port to introduce a source level debbugger interface into HLL reconfigurable computing netlists, which would require an open interface to plug a gdb/ddd backend onto. Having to create one JTAG chain for Xilinx tools, and one each for other vendors tools, and a separate one for your own debbuging tools is a total crock, and violation of what is "supposed" to be an open interface standard test port.

Open source is not about "free", is about the ability to preserve the right and ability to take and modify the tools to do what you need/want, and not be stuck with the bugs and lack of features (because the vendor lacks the resources to do it right) that you need. Or because the vendor obsoleted the product, discontinued support, and orphaned your VERY EXPENSIVE hardware that is only a year or two old (read XC4085XL and XC40150XV reconfigurable computing boards).

Xilinx may move rapidly in the market, but products built with Xilinx parts must be supportable for a reasonable life of 7-10 years or more. Current Xilinx polices which violate this sensibility are ....

Open source is Xilinx's friend in this respect, and provides a user community supported path to pick up the pieces when Xilinx commits these gross errors in product life support from and OEM and End User perspective.

for

ChipScope Pro

Yet another proprietary expensive tool. Probably only supported on a proprietary platform (Redhat Enterprise). Linux support is not about proprietary RE, it's about supporting Fedora, SuSE, Debian, ubuntu, etc in an "open source" not "free proprietary" way. That can include proprietary binary applications, but properly maintaining open source interfaces and NOT locking other open interfaces like JTAG to also be proprietary in the process.

I'm all for proprietary software and products which create pay checks for programmers, but when that is integrated with open source and open interface standards, it should be done in a sensible way that doesn't violate the openness of those standards. Proprietay JTAG interfaces, violates the openness of that standard.

Reply to
fpga_toys

Sure. Give me access to a PCI bus master (say the IDE) device, and I can splat whatever data it contains (say a binary I compiled) into whatever portion of memory (say kernel address space) I want it to go.

Oh, you need a "cite"... Well, if you're in the "know" and understand the implications, the following should make you cringe:

formatting link

If I get userland access to poke into I/O or device memory, I will take over your machine.

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Reply to
Tobias Weingartner

That's exactly the point. WinDriver gives access to PCI devices from userspace. Any PCI bus master can then be used to modify system memory. There are many more ways to gain root privileges once you can access device and/or system memory. Loïc Duflot published a very interesting paper describing how to gain root access (and doing much more) using the AGP aperture and SMM:

formatting link

How do you expect people to trust a closed-source driver which main purpose is to enable userspace applications to access devices directly ? Especially when there are safe open source multiplatform alternatives (libusb).

Laurent Pinchart

Reply to
Laurent Pinchart

Xilinx has done nothing to deviate from the IEEE JTAG standards as defined in the IEEE 1149.1 and IEEE 1532 specifications. All Xilinx devices have corresponding JTAG BSDL files for both 1149.1 and 1532 publicly released both on our web site and in every software release. These files fully conform to the appropriate IEEE specification.

These files and the IEEE standards are all that is needed for anyone to create software and hardware to communicate with Xilinx devices through the JTAG interface along with any other devices in the same chain.

If you do not like the software and hardware that we provide for this function and if no one else does either then you should go ahead and create what you want instead.

On the hardware comms front, Macraigor

formatting link
sells various JTAG communication hardware and has (had??) GDB support so you might want to start there first. I'm sure that there are other providers out there as well that you can find if not then go ahead and create your own JTAG communication hardware.

One thing is certain, if it meets the IEEE JTAG electrical specs and wiggles the bits as defined in the IEEE standards it will work with our devices.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

and again you completely missed the point.

Does Xilinx provide an open specification so that 3rd party software can use your expensive JTAG interfaces?

Does Xilinx provide and open specification so that 3rd party JTAG hardware interfaces are usable with expensive Xilinx software?

The complaint as I listen to this thread is that Xilinx does neither, instead offering a closed development environment which allows neither

3rd party hardware or software interfaces, that also creates a trojan root kit interface ... is that not the issue?
Reply to
fpga_toys

Is that permission to replace the Xilinx bit stream tools by reverse engineering and providing open source replacements?

The bitch ... is that Xilinx requires users to use the Xilinx usb adapter to program, then unplug the Xilinx usb JTAG interface, from a possibly live board, then plug another 3rd party (or home grown) JTAG into the board to do testing or configuration of non-xilinx device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG interface when it's necessary to reprogram a Xilinx part on the JTAG chain.

First, this is POOR practice on a live board, and labor intensive in any case. Second it's completely unnecessary, except for Xilinx's refusal to provide open development tools interfaces for the JTAG environment so that either a 3rd party usb adapter can be used, or 3rd party software with your adapter.

Reply to
fpga_toys

A IEEE 1149.1 and/or IEEE 1532 JTAG interface is available in all of our modern FPGAs (not available in the XC2000, XC3000 and part of XC4000 families) for configuration, boundary scan and internal user extensions. It is simple and easy to use with 4 pins TDI, TDO, TMS and TCK and conforms to the public IEEE interface standards. We have chosen to not implement the optional TRST pin. We have also chosen to implement allowed optional extensions to permit internal USER scan chains. The JTAG interface is not expensive to use.

All needed documentation on how to perform traditional JTAG boundary scan can be found in the IEEE specification and the appropriate BSDL file.

All needed documentation on how to configure a device from a binary bitstream can be found in the IEEE specification and the appropriate BSDL file and datasheet.

All needed documentation on how to create and use the internal USER scan chains can be found in the IEEE specification and the appropriate BSDL file and datasheet.

More information is also provided in Xilinx Application Note XAPP058

formatting link
which documents various consideration and even includes a C routing for JTAG programming from a microprocessor.

It is not as hard as rocket science, but it is harder than falling off a log.

Xilinx software is designed to work with Xilinx communication cables and some selected 3rd party equipment. Our software is tightly coupled to the communication hardware and we do not provide general access to the driver/software APIs.

Ed McGettigan

--
Xilinx Inc.
Reply to
Ed McGettigan

Since the function that I was discussing was configuration through iMPACT and a Xilinx USB JTAG cable and you have twisted this into something completely different then of course your answer is no.

There is no truth to this assertion. Our devices can be configured by many, many, many different means. Hundreds, if not thousands, of pages are available on

formatting link
describing how to take a generated bitstream and use it configure a device.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

Ok, interface is too general a term, as is cable, of which an active usb device is more than a cable, and hence refered to as an interface.

so,

Does Xilinx provide an open specification so that 3rd party software can use your expensive "usb" JTAG interface devices/cables/converters?

Reply to
fpga_toys

AFAIK The only thing you can't do with a borrowed/made-up VID/PID is use the USB logo.

Reply to
Mike Harrison

At first I thought that I could take a shot at this, download the WinDriver SDK and see if I could quickly figure out how the WinDriver API works. However, I didn't have to do that since they have some nice sample programs included in the WinDriver distribution:

-----------------------------------------------------------------------------

(This is all run as my normal user, not as root user.)

files.txt isapnp_scan pci_diag pci_dump pci_scan usb_diag wddebug wddebug_gui wdreg

PCI diagnostic utility. Application accesses hardware using WinDriver and a Kernel PlugIn driver (KP_PCI).

PCI main menu

--------------

  1. Scan PCI bus
  2. Find and open a PCI device
  3. Exit Enter option: 2 Enter vendor ID (to cancel press 'x'): 0x1002 Enter device ID (to cancel press 'x'): 0x5960

Found 1 matching device [ Vendor ID 0x1002, Device ID 0x5960 ]:

  1. Vendor ID: 0x1002, Device ID: 0x5960 Location: Bus 0x1, Slot 0x0, Function 0x0 Memory range [BAR 0]: base 0xE8000000, size 0x8000000 I/O range [BAR 1]: base 0x2000, size 0x100 Memory range [BAR 2]: base 0xF8400000, size 0x10000 Interrupt: IRQ 10

PCI main menu

--------------

  1. Scan PCI bus
  2. Find and open a PCI device
  3. Read/write memory and IO addresses on the device
  4. Read/write the PCI configuration space
  5. Enable/disable the device's interrupts
  6. Register/unregister plug-and-play and power management events
  7. Exit Enter option: 3

Read/write the device's memory and IO ranges

---------------------------------------------

  1. Change active address space for read/write (currently: BAR 0)
  2. Change active read/write mode (currently: 32 bit)
  3. Toggle active transfer type (currently: non-block transfers)
  4. Read from active address space
  5. Write to active address space
  6. Exit menu

Enter option: 5 Enter offset to write to (to cancel press 'x'): 0x0 Enter data to write (max value: 0xFFFFFFFF) or 'x' to cancel: 0xffffffff Wrote 0xFFFFFFFF to offset 0x0 in BAR 0

-----------------------------------------------------------------------------

At this point my upper left pixel turned white. I also managed to crash the PCI bus (and the computer of course) by playing around with this program and reading from the wrong address...

It seems that there are some ways around this according to comments posted at

formatting link
but I'm not sure how you would go about implementing that.

I wonder if the same problem will appear on the Windows version of WinDriver? I don't really have time to test it myself at the moment though.

(And yes, I also think it would be much nicer if the Xilinx tools did not depend on 3rd party kernel modules if it could be avoided.)

/Andreas

Reply to
Andreas Ehliar

We have a tiny FTDI 2232 based JTAG dongle, just havent got around to buiding them yet. Supports IO voltages from 1.6V to 5V (or 1.2V to 3.3V using different level tranlators) Should be really cheap ~$25.00 or so, or bare PCBs for cost of shipping (Free!) I think there are Linux drivers available for 2232.

Peter Wallace

Reply to
Peter Wallace

Then where is the documentation which describes the API for the Xilinx USB JTAG interface/cable/adapter?

Reply to
fpga_toys

That's the part that we're questioning. If you had a publicly documented API for the interface between Impact and the driver, you could get two main benefits:

1) Third party hardware that came with drivers supporting your API, so they could work with Impact. 2) Third party software (e.g., JTAG debuggers for various soft core processors and the like) that could work with Xilinx cables (or with the third party hardware in part 1).

Cost: A few weeks of an engineer's time to document the API. I suspect that there's already an API document which would simply need to be sanitized for public release.

Drawbacks:

1) Availability of third-party cables that work with Impact might slightly reduce sales of PCIV and PCUSB. Presumably Xilinx doesn't view PCIV and PCUSB as a major profit center, and it would overall be of greater benefit to Xilinx's bottom line to have more third party support even if it might slightly reduce the sales of PCIV and PCUSB.

2) The API would be semi-frozen. Xilinx could change it with future software releases, but then the third-party drivers and software would have to be revised by those third parties. However, since JTAG seems to be a reasonably mature interface, and Xilinx presumably understands their own requirements for the JTAG API, it seems unlikely that the API would need to be revised very often.

Eric

Reply to
Eric Smith

e

t,

u

Hi Uwe Bonnes, I am working with a JTAG-USB programmer based in FT2232D. The interface is the OOCDLink-s[0] board. Can you give me any information about how you adapted a FPGA(Spartan 3) wit h FT2232 on USB? Thanks very much in advance.

Regards,

Luis

[0]
formatting link

ng

Reply to
Luis Alberto Guanuco

Look at the code for xc3sprog on the sourceforge SVN repository. Discuss specific problems on the xc3sprog mailing list.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

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.