04-10-2013 07:27 AM
Hello all! I'v posted that before in Design Tools section, but I'm afraid no one is reading that forum...
Every time i try to use Lab tools under Linux with DLC9G USB cable I stumble to TCK frequency derating.
I set the desierd frequency of 12Mhz in Cable setup, but on any JTAG command iMPACT limits the maximum speed to 750Khz:
Warning: Chain frequency (1000000) is less than the current cable speed (12000000). Adjust to cable speed (1000000). Maximum TCK operating frequency for this device chain: 1000000.
There are no derating under Windows. I believe its a flaw of iMPACT's speed detection algorithm under Linux.
Looks like only iMPACT is derating the frequency to 1M under Linux. xmd (fpga -f) works properly w/o any derating.
Same with the Chipscope, it works properly on 12MHz!
How to fix the iMPACT? I need to turn off or repair the speed setting algo.
On Linux, Platform Cable USB works via iMPACT's native libusb inferface. I'v tried several versions of Lab tools, from 13.x to 14.5 now and with the same result and several PCs from powerful desktop to a tiny laptop with any type of JTAG target device I have the same result.
In any setup I'v tried: Windows - 12MHz, Linux - 1Mhz (750Khz).
Funny thing, even inside a virtual machine on Linux host Windows works properly with 12MHz TCK. If I try to use Windows virtual machine on VMWare running on the Linux host and the same target board with Platform Cable's USB port routed to VM, I enjoy the 12MHz speed. The same host running native Linux version of iMPACT gives me depressing 750Khz. That's very annoying.
So far, I never saw anything better than 750Khz under pure Linux in iMPACT. How can I fix it? Is it possible to disable the speed checking algo in iMPACT?
07-29-2013 04:54 AM
I'm experiencing the same issue here. Both with Impcat 12.4 and 14.4. On Windows everthing is fine, in Linux TCK is lowere to 750 kHz. Target Device is Virtex5FX.
Interresting thing: When downloading the bitfile with the Chipscope Analyzer or XPS/EDK, everthing is fine.
BTW: XPS uses its Makefile, which launches impact in batch mode:
impact -batch etc/download.cmd
The cmd file has the following content:
setMode -bscan setCable -p auto identify assignfile -p 2 -file implementation/download.bit program -p 2 quit
And this batchfile sets the chain TCK to 6MHz !
11-28-2013 07:25 AM
I am experiencing the same problems here with 2 PC's running Ubuntu 13.10 (kernel 3.11) and ISE WebPack 14.7. Cable connects at 6MHz but switches back to 750kHz when programming. It would be nice if someone had a solution or a nice workaround
12-03-2013 01:37 AM
Hi All who are facing this problem,
The iMPACT 7.1i (and later) automatically restricts the available TCK_CCLK_SCK selections to frequencies that are less than or equal to the slowest device in the chain. Check the other devices in your chain and check if the slowest one runs at 750Mhz or whatever the IMPACT is pulling it down to. For further information please check the Pg 5 and 6 of this guide - link, which talks about these cable speeds.
Hope a glance through this guide should help you understand the requirements.
03-03-2014 04:52 PM
I got the exact same problem when I updated from an older version. Worked just fine before so after reading what athandr wrote I did some testing and it turns out that iMPACT for linux can't interpret the BSDL-file correct. Max frequency is given as 25.0e6, but iMPACT wants it as either 25e6 or 25000000.
First find which BSDL-file iMPACT is using:
INFO:iMPACT:1777 - Reading /opt/Xilinx/14.7/ISE_DS/ISE/spartan6/dataxc6slx45.bsd...
If you edit the BSDL-file you will find a line that reads:
attribute TAP_SCAN_CLOCK of TCK : signal is (25.0e6, BOTH);
Remove the ".0" so it looks like this, with the max for your chip:
attribute TAP_SCAN_CLOCK of TCK : signal is (25e6, BOTH);
And now iMPACT will run at desired speed:
>Maximum TCK operating frequency for this device chain: 25000000.
Hope this will work for you as well.
08-04-2014 06:31 AM
Shameless crosspost from another topic; but I found the cause of this problem and a solution!
Took a while :+) , but I found a solution to this problem!
Yesterday I found a solution to another problem which I think is related. I was unable to generate some IP cores directly from my projects in ISE. I had to open the core generator from the Tools menu, then generate a core and add it manually to my project.
This was caused by a different numeric locale setting. Default at my pc (running Ubuntu 14.04, ISE 14.7 lin64) is nl_NL.UTF-8. The case seems that ISE expects en_US.UTF-8, so it interprets '.' as ',' and vice versa. During the generation of the cores it would stop and give a quite undiscriptive error. After an extensive search I found the problem cause to be the locale setting wich I fixed adding the third and fourth line to my ISE startup script:
Skipping back to a few minutes ago; I was programming my FPGA and noticed it was way faster than before. At first I thought something went wrong (couldn't believe it was done in 20secs instead of +2min) and tried again with the same result, though the FPGA seemed to work as expected.
After examining the Impact console log I found the chain speed warning had disappeared. Removing the lines from the startup script let everything get slow again.
I guess Xilinx is using some decimals somewhere in the communication or configuration files :-)