Argh! Need help debugging Xilinx .xsvf Player (XAPP058)

I'm trying to get the .xsvf player in XAPP058 to work, but I haven't been able to do so. I have been able to do port.c, and I see signals that seem quite reasonable. But the FPGA DONE bit never gets asserted.

If I enable debugging output, and "play" a simple GetIdCode .xsvf file, I see the chip (Xilinx Spartan-3) responding with the correct value (0x01434093), so it seems things are more or less okay.

I can play my .xsvf files (which are generated by the svf2xsvf utility from the app note, downloaded yesterday) in iMPACT, and they work just fine.

When I Googled it, I found one thread titled "Configuration via JTAG using an Embedded Controller" from December, but there was not resolution. The one responder suggested that if DONE doesn't go high, then there's a problem; they also guessed that a "post-amble" is missing, and to re-read the documentation, but I'm not sure what documentation is being referred to! I haven't been able to find any mention of it in XAPP058 nor XAPP503!

Okay, but I'm not sure where to look for this! I've played the file using iMPACT, and it works - so it would seem iMPACT adds such a "post- amble" automagically? How do I get this into my svf (and hence, xsvf) files?

Thanks!

-Bob

Reply to
Bob
Loading thread data ...

Bob,

Try creating xsvf directly from iMPACT. Simply choose XSVF file in the output menu. When finished writing go to the same menu and choose Finish Writing. This works for me...

/Mikhail

Reply to
MM

Mikhail,

Thanks for the idea, and I just tried it, but sadly, no joy - it still doesn't work!

Any other ideas, anyone?

Thanks, Bob

Reply to
Bob

When you use iMpact instead of your xsvf player, do you see a warning about changing the startup clock? Make sure that the startup clock is set to JTAG in the configuration settings when you build the bit file. Also check the startup options to check how many clocks you need at the end of configuration to set the DONE output. This may be the "postamble" mentioned in the other thread. Theoretically just adding a few more cycles of TCK at the end of the configuration process should fix this unless your startup clock is incorrectly configured to use the CCLK pin instead.

HTH, Gabor

Reply to
Gabor

Hi Gabor,

Yes, I do see that warning, at least sometimes. I've always been a little confused about that message, but given that it has always "worked" before, meaning that iMPACT seemed happy to make things work. Seems this could well be it.

Looking at the Properties dialog for the "Generate Programming File" process, I see "FPGA Start-Up Clock" under "Startup Options" , which is indeed set to CCLK - seems this is the default setting, is that true? So you are suggesting I change this to "JTAG Clock", right? I'm asking this detail because I won't be able to try this until Sunday, and I don't want to miss something stupid on my part!

And just in case, where do I "check the startup options to check how many clocks you need"? Is this in the data sheet?

Thanks, Gabor, I'll let everyone know how it goes!

-Bob

Reply to
Bob

Bob,

The startup clock problem didn't occur to me because I am actually programming a Platform Flash rather than FPGA, thus CCLK is the correct clock in my case....

That's what you have to do.

Under the same "Start Options" you can see Done (output Events) set to probably 4 and Release Write Enable set to probably 6. The last number I believe is the number of extra clocks required after the bitstream has been shifted in the chip. However, I don't think this is your problem as I am sure iMPACT adds all the required cycles to your xsvf file. I am pretty sure your problem is with the startup clock as Gabor noticed.

/Mikhail

Reply to
MM

impact DOES NOT and CAN NOT change startup clock if playing back already generated xsvf files. just think about it. it can not do it.

so if the xscv played with impact work, then it is valid (also correct startup clock)

Antti

Reply to
Antti

Double argh! This still doesn't work. I set the JTAG clock and it still doesn't work!

Any _other_ ideas?

Thanks!

-Bob

Reply to
Bob

I guess Antti is right... Anyway, which version of the tools are you using? What is you microcontroller? Do you have any external pullups? Do you disconnect the cable when running your player? There is a number of Answer Records on Xilinx site, which might be relevant to your problem. e.g.

formatting link

/Mikhail

Reply to
MM

9.2i

Freescale MCF5234 Coldfire

No.

Yes

your problem.

I've looked, but I can't seem to find one that helps...

I need to get this working by Friday, so I hope someone has some ideas?

Thanks,

-Bob

Reply to
Bob

Bob, (04.05.2008 16:50):

Did you check "Drive Done Pin High" in the startup options?

Andreas

Reply to
Andreas Hölscher

Maybe, but I don't think so. I thought of trying this, but I'm not convinced it has anything to do with it. DONE not going high is just a convenient way to tell if the configuration was successful, as I have it controlling an LED. Furthermore, the configuration is not "taking effect", and the FPGA remains unconfigured.

On the other hand, if this "option" is automatically applied by iMPACT when it is doing an actual FPGA configuration, but it is not added to the recorded .svf or .xsvf files, then you may be right. So, I will try it tonight (~8:30 PM EDT), and let you all know.

In the meantime, in seems there are a number of potential "gotchas" with various options that may be applied to the bit file generation process. Or to put it another way, I've become quite concerned that I'm missing some critical options that may well be documented somewhere and I messed it, or perhaps something everyone assumes I know when in reality I don't. Can someone who has done this give me a concise list of options they used, or what options are critical, or can point me to documentation on this (other then XAPP058)? Whatever is easy - I'm not asking for anything fancy.

Thanks!

-Bob

Reply to
Bob

I am not sure if this could be your problem, but... normally JTAG signals require pullups. Bitgen can (and probably does) enable them internally, but personally I've never relied upon them and always designed in external resistors... The behaviour with iMPACT might be different because there might be some pullups inside of the programming cable and/or simply the drivers/receivers are different.

/Mikhail

Reply to
MM

I have used XAPP058 to get a working setup. The only thing I struggled with was getting the DONE pin to go high. I belive the code has two options for the "RUNTEST" SVF instruction (or something like that): one is a delay loop and the other puts out clocks. Make sure you pick the code that puts out the clocks. The delay loop won't work. This was for a Spartan3A FPGA.

MD

Reply to
Martin Darwin

Oh? I've never used them before, but then again, I've only used iMPACT and the programming cable before...

This one I can't do until Wednesday, but I will try tacking on some external pull-ups, if possible. Frankly, I don't have a lot of hope on this, but then again, nothing else seems to work either!

Yes, Bitgen does enable them by default, and I didn't touch these...

Yeah, who knows?!

Thanks, but unless the pullups work Wednesday, I'm not sure I'm any closer. I certainly appreciate all your comments! Any others?

-Bob

Reply to
Bob

Yes, this is exactly my problem!

Okay, but I don't know how to do this. Where do I "pick the code" that you refer to? I've poked around all the options for the "Generate Programming File" process, but nothing seems to work, nor does anything seem to be what you're talking about. It certainly sounds like you have a great lead, but I don't even know how to follow it! Can you describe or point me to how exactly do I do this? I haven't run across it..

Thanks, Martin,

-Bob

Reply to
Bob

Martin is talking about the source code for the microcontroller...

/Mikhail

Reply to
MM

Oh!!! Do you mean this user-supplied function?

void waitTime(long microsec);

Now we're talking! The version I got suggested three approaches, one that pulses TCK, one that doesn't, and one that does for short durations, and doesn't for long ones! Well, I chose the one that simply delays, as the comments suggested that's okay for Spartan-3; on the other hand, the default does pulse the TCK! Since this is in agreement with Martin, I'll try that tonight, and report back...

Thanks, guys! Bob

Reply to
Bob

Oh!!! Do you mean this user-supplied function?

void waitTime(long microsec);

Now we're talking! The version I got suggested three approaches, one that pulses TCK, one that doesn't, and one that does for short durations, and doesn't for long ones! Well, I chose the one that simply delays, as the comments suggested that's okay for Spartan-3; on the other hand, the default does pulse the TCK! Since this is in agreement with Martin, I'll try that tonight, and report back...

Thanks, guys! Bob

Reply to
Bob

Bob,

Congratulations! I am curious if the second method will work?... I think there is a good chance that it will...

/Mikhail

Reply to
MM

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.