1. Home
  2. Field-Programmable Gate Arrays
  3. more and more and more issues with Xilinx tools

more and more and more issues with Xilinx tools

Hi all,

FPGA are fun to work with ... when the tools work. New versions of the tools come out, then serice packs, but there is no light that the tools would actually work better. This is towards Xilinx tools. I used lately also Quartus 4.2 for several desings and dont recall having any tool related issues at all.

formatting link

there are some my current identified problems with ISE 7.1, unfortunatly backing up to 6.3 doesnt also work for me as the most needed feature has a problem on 6.3 - chipscope core inserter makes the working design a non working design.

I can not belive that everything do try todo with Xilinx tools is so weird that nobody else (e.g. xilinx internal testing team) has ever tried that. But with almost anything I touch I see the tools either crash or not properly working.

Some issues are minor, and I can figure out some workarounds, that takes time, but if the problem can be circumvented its ok. Some issues are more fatal. At the moment the current state (of xilinx tools) really doesnt look like the next service pack would resolve the major issues (those I am aware of, there are mort likely many more of them).

At the very present moment I am really in not good mood as I need to verify some designs VERY URGENTLY and the tools just fail there where I need them.

Antti

Reply to
Antti Lukats
Loading thread data ...

Have you reported the issues to Xilinx ? I was at a seminar last week & a Xilinx guy said they are always keen to get hold of designs (under NDA if necessary) that break their tools so they can improve them.

Reply to
Mike Harrison

"Mike Harrison" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

light

I

any

get hold of designs (under

have reported some, but have not opened any webcases lately, just hasnt enought time for that.

the current major problem I have, seems only to be an issue of core inserter in 6.3 so using core generator and hand wiring what is more time consuming, well if it works and doesnt brake the desing I am happy with that for the moment. As of most other issues those are not so urgent burning so I can wait and see if the issues get fixed in next service packs.

some issues are on my side too, namly I am refusing to have 3rd PC for xilinx design having only 2 seems to be insufficient

Antti

Reply to
Antti Lukats

..but you do have time to post on CAF about it? ;-)

Cheers, Syms.

Reply to
Symon

"Symon" schrieb im Newsbeitrag news:42922978$0$79459$ snipped-for-privacy@news.sunsite.dk...

sometimes, yes :) honeslty I was about to submit a web case a few week ago, but wasnt succesful at first attempt and later have not tried. as of the transition time from 6 to 7 its not so clear if it makes sense to submit bugs to version 6, after upgrading one PC to 7.1 I have not been able to recheck if the bugs with 6.3 I did see are fixed or not. So that one reason why I havent submittted the webcases.

Antti

Reply to
Antti Lukats

Thanks!

"Matthieu MICH> (...)

inserter

Thanks!

Antti, is hopefully not attacted for saying thanks in both top and bottom posting style :)

Reply to
Antti Lukats

no light ...

verify

them.

I have some suggestions to Xilinx about the ise7.1 regarging the intaller etc. Since they are mostly not bugs, I thought may be I will just keep them under the page

formatting link

Mostly started with the frustrating experiance I had downloading the tool. I had tried 48Kbps, 28Kpbs speeds and gave up because of the restrictions the cafes have ( since I don't access from a company - I am not working for any currently), then I went downloading at around

7Kbps and it tooks around 18 hours to get the file. I heard that there are times when people had to lock up their phones for days to get the files!. I suppose there are others with same issues too!. I hope even the device support files can be made into seperate downloads. Final comment is about the performance issues I had. It starts with opening gui stuff.

Anyways please have a look at the text and please comment.

Thanks, George

Reply to
Geogle

Matthieu MICHON wrote:>

Yep, I have ended up doing the same thing. It appears to me that the "Use RPMs" in 6.3 is broken.

Reply to
Duane Clark

Hi Antti,

I agree with everything you said. I also encountered the ChipScope issue on a Virtex4 design with the ISE7.1 tools. Either disabling the "Use SRL16" or disabling the "Use RPM" provided a good workaround. One more problem I had to find out the hard way : if you are planning to use the new IDELAY feature in Virtex4 (e.g.for source-synchronous interfaces, or DDR/DDR2 interfaces as generated by the Xilinx MIG tool) you MUST have at least ISE7.1 SP2. And also if you are using IDELAY, you should (according to the user guide) also use the IDELAYCTRL block : but don't wait for the IDELAYCTRLRDY pin to go high (like the user guide says you should), because there's a bug in the bitgen tools that prohibit this. Maybe all this does not apply to your design, but if it does, this saves you a LOT of debugging time :-)

best regards, Bart De Zwaef

Reply to
zeeman_be

Antti Lukats wrote: (...)

(...)

Hi Antti

I experienced the same issue. It seems that the RPM implementation in ISE 6.3 is kind of broken, and since the "Use RPMs" attribute is active by default in the CSP Core Inserter, the design implementation is very likely to fail with default settings.

A simple turn-around is to un-check the "Use RPMs" attribute (located in the Device panel of the CSP Core Interter).

Hope this help ;)

Matthieu (who also would be pleased to see native Mac OS X support for EDA tools)

Reply to
Matthieu MICHON

"zeeman_be" schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

Hi many thanks! well I am still having problems, I was trying core gen not inserter hoping it does better job, it randomly worked, then I unchecked use RPM, regenarated but then my design did not work, then I unchecked use SRL and guess ?

-- the design did not fit into V2-2000 !! my own design is 12% of the FPGA and one simple ILA core doesnt fit into the rest 88% !! uupsa!

I am struggling to see if some combination is working for me

Antti

Reply to
Antti Lukats

I know exactly what the issue is, and it is in 6.3 as well as 7.1. The problem is there is a bug in the RPM grid resolver that doesn't take into account BRAM or DSP48 columns. If your RPM has placed elements that require an M-slice (SRL16 or lut RAM), and that slice is placed within the RPM so that there is a non-lut column between it and the RPM origin (lower left corner), it barfs because it lost track of the which column is the M-slice column when it crossed over the non-LUT column. This becomes crucial in devices like the V4sx55 where you only have four lut columns between non-lut columns, as it becomes impossible to place such an RPM where it doesn't straddle a non-lut column. In my case, I was able to work around it by assigning the resources in the RPM to different HUSETs, depending on which column they fell in, and then putting separate RLOC_ORIGINs on each HUSET. they told me it would be fixed in the next service pack. FWIW, it is case 578431-1. Xilinx says it only affects locked macros, but that is not entirely true: it will allow an unlocked macro provided the placer can find a place to put the macro where it won't straddle a non-lut column. This may not be the possible with some of the V4 devices and larger macros.

Disabling USE RPM will sidestep the problem, but it also throws away all the placement information, so it may not allow you to meet timing if you are pushing the performance envelope. Turning off use SRL16 avoids the problem by making so there are no slice_Ms in the design. You pay a price in increased area and power consumption, however.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759
Reply to
Ray Andraka

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.