ISE 8.1i on Fedora Core 4 (64-bit)

In general, ISE 8.1i seems to install and work just fine on my Athlon 64 system running Fedora Core 4 (64-bit).

ISE Simulator does not seem to get installed, though. I'll try installing on a 32-bit system later and see if that gets it.

And unfortunately there still aren't 64-bit cable drivers for use with the Parallel Cable IV or the Platform Cable USB. I started trying to build them myself from the Xilinx "sources" and the Jungo demo kit, but Xilinx supplies the core of the XPC4 driver as a binary archive, and they don't supply a 64-bit version of that.

Sigh.

Could we have some 64-bit cable drivers, pretty please?

It's nice being able to run Project Navigator and do everything up through the programming file generation on my main development machine, instead of needing a second machine with very old software (RHEL3) for that. But it looks like I'll still need a second machine to run Impact.

I'm considering buying Chipscope, but I think I'll hold off until there are 64-bit cable drivers.

Reply to
Eric Smith
Loading thread data ...

Hi Eric, Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full speed?

Mehdi

Reply to
GaLaKtIkUs™

I didn't try. I set up a system running CentOS 3.5 32-bit (though it's

64-bit hardware), and 7.1i worked fine on that, including cable drivers (after I compiled them).

So now I have a Belkin 4 port USB-and-DVI KVM switch, and go back and forth between that and my main development machine (FC4 64-bit). That KVM switch is a total piece of crap, buy the way, so don't buy one. (Details below for the curious.)

Now that I'm using 8.1i, I might try installing FC4 32-bit on that machine instead. Aside from the cable drivers and ISE simulator, 8.1i installed beautifully on FC4 64-bit, with none of the hassles for different versions of shared libraries and special environment variable settings that were needed for 7.1i.

But I *really* would much rather be able to program from my main development machine. I briefly considered trying to reverse-engineer the ioctl_3.a file, but I suspect that would violate the ISE license agreement, and anyhow, life's too short.

It's hard to believe that there are any significant trade secrets in ioctl_3.a; maybe Xilinx can be convinced to give out the source for it.

Eric

Belkin 4-port USB-and-DVI KVM problems:

1) mechanical - can't plug the DVI cable onto port 1 of the KVM due to lip of plastic housing, effectively making it a 3-port KVM

2) electrial - rather than having four DVI receivers, a mux, and a DVI driver, the KVM uses *relays* to switch the DVI signals. This results in enough signal degradation that I occassionally get twinkling pixel streaks. Ugh.

3) firmware (?) - the KVM sporadically loses key events. Sometimes pressing a key does nothing, and sometimes a key up event is lost, so the key starts repeating even though it's been released.

I wouldn't have gotten the KVM switch at all, since I can use X over the network easily enough, but while I was trying to get drivers working I was rebooting the machine frequently and needed to see the screen during the boot process.

Reply to
Eric Smith

Xilinx is trying to keep the Cable IV internals as secret so thats why they dont release in source code anything that could include information how to talk to the cable IV in high speed mode.

And that is also the reason why there Cable IV support is as shit as it is. On my main computer where all ECP port cable from other vendors work properly, well Cable IV works in Cable III emulation mode only. Its an WinXP machine so the problems are not only on linus

BTW the Cable IV PLD is non protected and resoldering a few 0 ohms on the PCB makes Impact able to read back the JEDED file from the XC3384, and I have a tool that converts the JEDEC to synthesizeable VHDL :)

Antti

Reply to
Antti Lukats

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.