FPGA Editor (9.2.03i) under Linux x86_64

I am not able to run the fpga_editor (64-bit ISE install) under my Fedora 7, x86_64 system. After I set the DISPLAY variable to :0 (instead of my :0.0 or :0.1) and trying to start it, I get following output:

/opt/xilinx_92/bin/lin64/_fpga_editor: Symbol `_XtperDisplayList' causes overflow in R_X86_64_PC32 relocation /opt/xilinx_92/bin/lin64/_fpga_editor: Symbol `_XtGetPerDisplayInput' causes overflow in R_X86_64_PC32 relocation

Cannot register service: RPC: Authentication error; why = Client credential too weak unable to register (registryProg, registryVers, tcp)

Wind/U Error (248): Failed to connect to the registry on server workstation.cholunna.local

Warning!!: XKEYSYMDB environment variable is set to a wrong location Cannot register service: RPC: Authentication error; why = Client credential too weak Overriding Xilinx file with local file

Is there any chance to make it running? Does it run at least in 32-bit ISE install? Before I used 32-bit ISE 8.2 on the same system and fpga_editor worked fine.

By the way, why FPGA editor is still Windows application running under Wind/U environment while the rest of Xilinx tools run native in Linux? I do not understand.

Thanks, Jan

Reply to
Jan Pech
Loading thread data ...

A substantial amount of work is required for each appication when we move away from Wind/U. We have decided not to do that for FPGA Editor. Instead, we are creating a new application that is a combination of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be available in 11.1 (March 2009).

Steve

Reply to
<steve.lass

older version of libXt.so is needed to run WindU based programs like FPGAEditor

see Answer Record for details

formatting link

Reply to
krishnans

Steve,

did Xilinx consider Wine as a portablility layer for programs written in the windows API?

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

I read that correctly as a year and a half from now, right? That seems like a loooooong way off. I remember once being told that supporting partial reconfiguration on the Spartan devices was a few months off and that Xilinx was committed to it. I don't think that has ever materialized. How serious is Xilinx about this new tool, PACE? Anything more committal than just "committed"?

Reply to
rickman

I have to agree, this seems a VERY long way off. The day ISE ran without windu was a real landmark (and a good one too). Unfortunately, starting floorplaner of fpga editor is still a real pain.

Andy

Reply to
Andrew Greensted

Yes. We plan to keep FPGA Editor around for a while so if there are issues, let us know. Hopefully the issue that started this thread is solved by the answer record provided.

I don't remember a commitement on Spartan support. We have it working internally, but it's a very difficult flow and not something we are prepared to support. The big difference between Spartan and Virtex is that Spartan glitches when reconfigured. That means you need to isolate partial regions including IO, and static routes cannot cross parial regions. We are commited to Partial Reconfig for Virtex.

PACE is the old tool. The new tool will replace PACE, Floorplanner, FPI, FPE and FPGA Editor. We are committed. However, in 11.1, the new tool will not replace all FPGA Editor functions (like detailed manual routing) so FPGA Editor will be around for things that a small percentage of customers use until 12.1.

Steve

Reply to
<steve.lass

I remember once being told that

Now I am really confused. I read in another thread here about the partial reconfiguration toolm PlanAhead. When I looked on the web site it lists several Spartan 3 devices as being supported. Are you saying that this page is incorrect?

I can't say I am intimate with the limitations of the PlanAhead tool as I have never worked with it or even seen documentation. My application requires the low cost of the Spartan 3 devices and uses partial modular reconfiguration as a way to minimize the number of bit streams. With various hardware modules connected, the combinations of interfaces become huge. In essence, I want to create compatible interface modules within the FPGA that can be combined at run time by a small ARM processor. Initially the processor would query what hardware modules are connected to the FPGA and then load the appropriate interface modules into the FPGA.

I'm not clear on your description of "static routes", but if I can't run signals from I/Os through one module to another, the pinouts become very, very constraining.

The next time I am building a board that could use PlanAhead, I will take a look, but if Spartan 3 parts are not supported, or are not very usable with PlanAhead, then this does not really solve any of my design problems.

Reply to
rickman

I dug around and found that the Xilinx web site seems to contradict itself in regards to support for partial reconfiguration for Spartan 3 parts. Although the "PlanAhead" web page lists several lines of Spartan 3 parts as being supported by the PlanAhead software, I found these comments in the "PlanAhead Software as a Platform for Partial Reconfiguration" web page.

"Partial reconfiguration is supported in both the Virtex and Spartan(tm) families. In this article, we will focus on implementing the partial reconfiguration methodology as it applies to Virtex-II and Virtex-II Pro FPGAs."

So they really do shy away from describing in any way, partial reconfiguration for Spartan devices. I guess I will stick with my original belief that, for all practical purposes, in contradiction to what the Xilinx web site says, partial reconfiguration is not supported on Spartan devices.... still.

BTW, if you would like to see where I was told, more than once, that Xilinx was committed to supporting partial reconfiguration on the Spartan 3 parts, I can forward the emails to you.

Reply to
rickman

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.