ISE has lots of installation issues when installing on Vista x64. In order to try and work around some of them I decided to force an x32 only installation. The required steps are to run the xsetup.exe directly from the bin/nt folder instead of the default xsetup.exe in the root of the installation. Of course to update the installation you will have to use the 11.3 32-bit update. You will have to run the bin/nt/xilinxupdate.exe to install the service pack.
From preliminary tests I see this fixes ISIM and Chipscope issues. For ISIM it now installs the required files under the hdp folder.
Friday, September 18, 2009
Thursday, September 17, 2009
ISE 11.3 released
I downloaded and installed ISE 11.3 update which brings an unknown bundle of updates to ISE. Unknown because they still haven't updated the ARs (Answer Records) to detail the changes / fixes / issues. I can say for sure that they haven't fixed the external editor issue (http://ionipti.blogspot.com/2009/05/xilinx-ise-using-external-editor-not.html). I see that they do have updates for many of their IP cores.
Seems to me that the major updates are related to Virtex 6 and Spartan 6 support. It would be nice to see the release notes whenever Xilinx makes them available.
Struggling now with ISIM issues on Vista x64.... (http://forums.xilinx.com/xlnx/board/message?message.uid=46879)
Seems to me that the major updates are related to Virtex 6 and Spartan 6 support. It would be nice to see the release notes whenever Xilinx makes them available.
Struggling now with ISIM issues on Vista x64.... (http://forums.xilinx.com/xlnx/board/message?message.uid=46879)
Friday, September 11, 2009
ISE 11.3 coming out this month
I'm excited to see ISE 11.3 simply because it allows full installation to use WebPack functionality when not connected to license server or when license is unavailable. It would be nice if Xilinx would past target release dates for updates, but of course they don't. I found on one of their AR (Answer Record) pages that the release date is September 2009. Not an exact date, but nice to know.
AR record: http://www.xilinx.com/support/answers/32744.htm
AR record: http://www.xilinx.com/support/answers/32744.htm
Monday, September 7, 2009
Xilinx MIG - doesn't meet timing
In attempting to compile a design at rates of 200 MHz or above I run into many timing issues with the MIG. Xilinx explains this because my board's pinout of the DDR2 pins are far away. I definitely agree with their analysis regarding why the MIG is failing to meet timing. What I don't understand is why Xilinx didn't add a parameter for increasing latency in order to increase the frequency. This is a trivial matter when dealing with a DDR2 controller.
Here's hoping MIG 3.2 will have such a parameter as this will be helpful for those occasions where you didn't place all the DDR2 pins where Xilinx believes they should be.
I guess I should delve into the MIG and add this parameter myself.... argh!
Here's hoping MIG 3.2 will have such a parameter as this will be helpful for those occasions where you didn't place all the DDR2 pins where Xilinx believes they should be.
I guess I should delve into the MIG and add this parameter myself.... argh!
Tuesday, September 1, 2009
Xilinx Divider IP / Translate -- SOLUTION!!!
So I've spent a while studying this particular issue with the hope that I could puzzle out a solution. After a few hours I finally did. The issue is that the NGC that coregen creates is not flattened. The easiest way to fix this is to open the coregen-created NGC in PlanAhead, and let PlanAhead "Export Netlist". Take the exported .edf file and do a find replace to switch all "/" to "." (without quotes of course). This will flatten the netlist and the Translate step will now act nicely.
PS. This isn't a recommended solution for flattening other netlists, but it happens to be OK for the coregen dividers from what I can see. I didn't write a parser to verify legality or any such thing, so please don't complain if this doesn't work for you. And don't use this method for flattening other netlists!
I know there is at least one other person suffering with 12 hour translates and I hope he gets this information... I will pass this onto XilinxSupport and my FAEs and ask that they pass it on to you.
Perhaps this can save the next guy hours of wasted time
PS. This isn't a recommended solution for flattening other netlists, but it happens to be OK for the coregen dividers from what I can see. I didn't write a parser to verify legality or any such thing, so please don't complain if this doesn't work for you. And don't use this method for flattening other netlists!
I know there is at least one other person suffering with 12 hour translates and I hope he gets this information... I will pass this onto XilinxSupport and my FAEs and ask that they pass it on to you.
Perhaps this can save the next guy hours of wasted time
Xilinx Divider IP and the Translate step
I have been building a highly optimized processing FPGA which requires amongst many other things a divider module. I used Core Generator to create the necessary divider. I have now noticed that the Translate step suddenly takes upwards of 2 hours to complete (with numerous dividers of course).... After lots of research and testcases it appears that Xilinx's divider module is very troublesome for their Translate tool (ngdbuild). This of course is extremely aggravating as the Translate is now the longest step by far in the whole compilation process.
I recently held a meeting with representatives of Synopsis regarding Synplify. I was happily surprised to see that they not only manage to decrypt the divider module, but to also write the divider directly into their output EDIF. The whole Synplify synthesis step took 30 minutes. This EDIF can then be Translated within a matter of minutes and of course mapped and routed. Amazing! Xilinx themselves spend over 2 hours during the Translate step which doesn't take into account XST time, whereas Synplify does the complete synthesis and bypasses the heavy Translate step in 30 minutes!!!
I am not impressed by Xilinx.
Perhaps someone knows of a Xilinx solution and would like to enlighten me.
To try this out on your own you need to create the largest divider you can and implement it a few times in a simple testcase. Easiest way is to connect the divider's ports directly to the I/O ports of the top module. The Translate step will be the longest step by far in the compilation process.
I recently held a meeting with representatives of Synopsis regarding Synplify. I was happily surprised to see that they not only manage to decrypt the divider module, but to also write the divider directly into their output EDIF. The whole Synplify synthesis step took 30 minutes. This EDIF can then be Translated within a matter of minutes and of course mapped and routed. Amazing! Xilinx themselves spend over 2 hours during the Translate step which doesn't take into account XST time, whereas Synplify does the complete synthesis and bypasses the heavy Translate step in 30 minutes!!!
I am not impressed by Xilinx.
Perhaps someone knows of a Xilinx solution and would like to enlighten me.
To try this out on your own you need to create the largest divider you can and implement it a few times in a simple testcase. Easiest way is to connect the divider's ports directly to the I/O ports of the top module. The Translate step will be the longest step by far in the compilation process.
Subscribe to:
Posts (Atom)