Programming XCF from MicroBlaze over JTAG???

Hi,

Has anyone had any success in programming a Xilinx XCF using C code in a MicroBlaze over the JTAG ports?

Any information appreciated.

Thanks!

Reply to
Bob Golenda
Loading thread data ...

Not exactly, but some closely related things, such as programming FPGA and config flashes whose JTAG signals have been connected to GPIO pins of ordinary (hardware) microcontrollers.

I don't think you'll be able to program the config flash by driving the FPGA's jtag pins, so you would need some seperate connections from ordinary I/O pins.

Once your microblaze can twiddle the config flash's jtag signals, you have a software problem. My preferences has been to make the embedded device behave like a jtag cable with some macro commands and act as a proxy for a program running on a PC. You could of course embed the whole thing, but that means putting the algorithm and the data into the embedded processor. Your microblaze system may have the resources for that, my embedded targets don't, so I use a much smaller block of code that acts as a proxy.

Reply to
cs_posting

You can do the following:

- Use IMPACT and record the JTAG programming sequence to an XSVF file.

- Read XAPP058 and XAPP503 to learn about the XSVF file specification.

- Implement an XSVF player using C code in a Microblaze.

- Play the recorded JTAG programming sequence in your board.

Using the batch mode of IMPACT, you can script this from your makefile.

Regards, Marc

Reply to
jetmarc

I've done it with a Xilinx Spartan 3 programming from the .bit file (using a modification of the open source XC3Sprog package)

and for Altera EPC4 config flash and also directly the Stratix-II FPGA, from .jam files using a modification of Altera's open source jam player.

I haven't done a Xilinx config flash, but I don't imagine that would be too hard - one would just modify their reference XSVF player to control your microblaze as a proxy, or to run on your microblaze.

Reply to
cs_posting

Hi,

Of course, using GPIO pins.

But, the question is, has anyone actually gotten this to work?

Thanks!

Reply to
Bob Golenda

Hi Marc,

Have you actually done this and gotten it to work?

Thanks!

Reply to
Bob Golenda

We have it working. I say "we" as it was mostly my software colleague's effort:) Apparently it took him a day or less to port the code from the appnote to PPC in V4, which we have been using. We are programming Xilinx Platform Flash on a slave board using this method.

/Mikhail

Reply to
MM

yes, I have ported XSVF player too. was to coldfire embedded linux. the porting itself is simple, and it pretty easy solution when storage is readily available. if the FPGA system doesnt run linux and only has small amount of available ram and no nonvolatile storage and no network and no high speed connections to any hosts, then its more efficient to program the XCF from bit file directly as then there is no overhead of the XSVF involved. this is unfortunatly a bit more than 1 day of work. well at least when doing it first time. Actually my first time was almost a month. but that was long time ago when xilinx had not even published the XCFxxP BSDL files yet. now its more info available so its a bit simpler to get going. and yet still Xilinx has not and will never publish the XCF programming specifications so its a bit RE and testing involved to get all timeouts correctly etc, as there is no reference datasheet for then existing :(

Antti

Reply to
Antti

This is using XSVFPlayer? How many M Bytes is the file? Don't you have to actually do an output of the file and record that, and then use XSVFPlayer?

Reply to
Bob Golenda

We don't really care much about how big is the file as it gets downloaded from an external server when needed and the whole purpose of this is a rare in-field hardware upgrade.

/Mikhail

Reply to
MM

rare

Ah, OK. Unfortunately, we care about:

1) how big the code it self is...so it fits in the XCF 2) how big the data is, as it has to fit in available memory 3) programming speed

So, it doesn't seem like the XSVF player solution will work for us. That's why I asked about straight JTAG programming, which it seems like no one has actually done and gotten working.

Thanks!

Reply to
Bob Golenda

Read again Antti's reply. He has done it.

/Mikhail

Reply to
MM

That may be possible in some situations, but not this. The software that talks to the board is dedicated (and embedded), and the programming needs to be self contained.

That would be fine, but the speed depends on a lot of things. Now, you are programming an Altera...I specifically asked about Xilinx XCF...

Reply to
Bob Golenda

I read that he ported XCF player.

When he said his first time was about a month, it's unclear exactly what it is he did, and how it operated. I will ask him off-line.

But, let's say he has done it...has anyone else? So far, it appears not, and that doing it is no trivial task.

Reply to
Bob Golenda

And how is the new bit or XSVF file going to get into this "self contained" device to start with? Download? Flash Card? How? Answer that question and you are on the path to solving your problem.

Speed depends mostly on the size of the part and the efficiency of the implementation - for comparison, this is about 4x slower than the USB blaster doing the same job.

You haven't specified how big your bitstream is, anyway.

(I haven't told you how big mine is because I'm not exactly sure - the pof file is about 500k, but the jam file is only about 300k... I'm not really sure how big the actual prom image is)

Reply to
cs_posting

Hi Bob,

Yes, I've actually done this and it works.

I didn't use or port the XSVF Player, because when I didn't know about it until I had half of my code finished already. I based my code on the XSVF file description in XAPP503. I found it is sufficient to program an XCF08P chip, but not for a V4FX FPGA. The FPGA XSVF file uses some states not covered in XAPP503. They are covered in the source code of XAPP058 and actually they are not difficult to guess either.

For what it's worth: The XSVF is about the same size as the (ASCII) MCS file. It's binary but contains lots of redundant patterns. Unfortunately the XCF08P erase time is very slow, because it's implemented as simple delay. The XCF08P datasheet documents how to poll the erase state, so it's possible to "replace" the delay with a poll function on-the-fly in your XSVF interpreter code.

In theory you can't stream an XSVF file because the byte order of some commands require you to access the last byte first. The command size can be any 32-bit integer, so effectively this puts an unknown memory size requirement on your embedded stream buffer. It can be as large as the whole file size. In practice however, I never observed commands larger than 768 bytes produced by Impact as XSVF generator. To be on the safe side, my code interprets the XSVF on the Windows PC, and produces a stream of proprietary command tokens. This stream is sent to an 8-bit MCU on my target board to produce the actual JTAG patterns.

To produce the XSVF file with Impact (batch mode), I found the most simple solution is to load a working project file with all chips already configured. This reduces the size of the batch command file to less than 10 lines.

I hope this helps, Marc

Reply to
jetmarc

Hi Marc,

Thanks for the info. But, it sounds to me like you "play" the XSVF file, using your own code/interpreter instead of porting the Xilinx XSVFPlayer, and you don't actually do the JTAG protocol your self? Not a problem, that's one way to skin this cat...but I'm just trying to understand the relationship between what you did and having a true JTAG programmer that just uses .mcs files.

Thanks!

Reply to
Bob Golenda

Take a look at this old discussion:

formatting link

/Mikhail

Reply to
MM

I don't find it odd that few people have reversed engineered and implemented a proprietary interface.

An XSVF player does do the jtag.

What it is not is something which knows by itself the syntax of the proprietary commands to send via jtag to the xilinx config device; it gets around that by following explicit instructions in the XSVF file. The proprietary commands become part of the "data"

Reply to
cs_posting

Thank you very much for that pointer. It still appears that aside from what Antti did, no one (at least on this list) has successfully done a real JTAG programmer for the XCF...just XSVF Player type programmers. I just find that odd.

Reply to
Bob Golenda

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.