| ??? 10/03/05 18:54 Read: times |
#101863 - XSVF Executor Responding to: ???'s previous message |
Terry A. Perdue said:
Hi Sasha -
Xilinx has promised to help us with this. If they do, I'll share any useful information here. But XSVF Executor may be just what we've been looking for. I'll turn it over to someone who speaks C. Thanks for making me aware of this. Sorry I missed your original message on this topic. I was out of town at the time, and thus missed a couple of my daily checks of the latest threads on 8052.com. Good luck on the Xilinx front. I will note though that I spent not more than a day getting XSVF Executor up and running. The other aspects of this (such as parsing, data transfer, etc.) took some work, but XSVF Executor was a breeze. You won't have to learn much about JTAG to get it going. It's good. Really good. FYI - The latest version of Impact outputs XSVF files without needing to convert SVF to XSVF with a separate utility. My particular XSVF file is approximately 7.5K. Since my processor, an Analog Devices ADuC841, has 62K of ROM, and I'm only using 15K so far, there should be enough room to store both the XSVF data and XSVF Executor as well, even though both only need to be used once. That way there will only be one file needed to program the uP. The main application can look at power-up for a flag that tells it whether the CPLD has been programmed yet, or there can be a special command to program it. I was using third party design tools that invoked the Xilinx backend tools to make JEDEC files. That actually worked out quite nicely for my application, since the JTAG chain had multiple devices anyway, and the configuration of the chain must be defined at the time the XSVF file is generated. If you're running iMPACT interactively yourself, chain configuration is something you have to specify. I wrote a simple program that converts XSVF files to a series of DB statements for inclusion in the assembly source. Your method of streaming the XSVF data through the serial port is more elegant, but I've got so much ROM left that this makes more sense to me. If your device is small enough that this approach is feasible, ROM-embedded XSVF is probably the way to go. Although robust and easy to debug, I'm not convinced that my approach is elegant. The HEX-386 encoding adds significant overhead to the XSVF data stream, and the rigid embedded parser for it is nontrivial. I didn't use a latch to isolate the CPLD once it's programmed. The four I/O pins that are connected to the JTAG pins on the CPLD will be used for other functions once the CPLD is programmed. There isn't much activity on those pins in normal use, so I assumed that it would be very unlikely that the CPLD programming could be affected, considering how involved the programming protocol is. I haven't seen any evidence that the program has been corrupted yet anyway. I don't think my gating of the JTAG lines is essential. However, in my application, there would be a mild safety issue if the CPLD configuration got destroyed during operation, which is not out of the question in the event of firmware corruption, bugs in my firmware, or other situations that might cause the microcontroller to unpredictably toggle the JTAG pins. The gate was a cheap and easy solution to eliminate the possibility of that sort of failure. Granted, there are other ways to cause errant operation in a CPLD, but that's a long story that would best be saved for its own thread. If you'd like the code for this, let me know, and I'll try to untangle it from the projects it's in. My HEX-386 parser is written for Keil C51, as is my port of Ethernut's XSVF Executor. The PC loader application is written as a Microsoft Visual C++ console application. --Sasha Jevtic |
| Topic | Author | Date |
| Using 8051 to program CPLD via JTAG | 01/01/70 00:00 | |
| Eh??? | 01/01/70 00:00 | |
| Reply | 01/01/70 00:00 | |
| Don't hurt yourself | 01/01/70 00:00 | |
| Ouch! | 01/01/70 00:00 | |
| Regarding XAPP058 | 01/01/70 00:00 | |
| ????????????????? | 01/01/70 00:00 | |
| It's a interpreter of XSVF | 01/01/70 00:00 | |
| why JTAG? | 01/01/70 00:00 | |
| Yes, but... | 01/01/70 00:00 | |
| not seeing the forest for the trees or w | 01/01/70 00:00 | |
| Several reasons... | 01/01/70 00:00 | |
| CPLD programming | 01/01/70 00:00 | |
| programming Xilinx CPLDs | 01/01/70 00:00 | |
| XSVF Executor! | 01/01/70 00:00 | |
| XSVF Executor | 01/01/70 00:00 | |
| XSVF Executor | 01/01/70 00:00 | |
| Using 8051 to program CPLD via JTAG | 01/01/70 00:00 | |
Yeah well | 01/01/70 00:00 |