I'm starting a new project at the moment, and I'm looking at upgrading to ISE 7.1, since I prefer not to change synth/par tool versions mid-project. I noted that a number of people complained about 7.1 when it first came out, but also noted that Service Pack 2 is out now. Can anybody comment on the state of ISE 7.1 at the moment? Thanks, Jeremy
ISE 7.1 Service Pack 2 - Ready yet?
Started by ●June 20, 2005
Reply by ●June 20, 20052005-06-20
Jeremy Stringer wrote:> I'm starting a new project at the moment, and I'm looking at upgrading > to ISE 7.1, since I prefer not to change synth/par tool versions > mid-project. I noted that a number of people complained about 7.1 when > it first came out, but also noted that Service Pack 2 is out now. Can > anybody comment on the state of ISE 7.1 at the moment?Howdy Jeremy, I don't use Linux, but Windoze based 7.1i has stablized enough that chances are slim you'd run into any problems with it - and even if you do, they are likely fixed in SP3 (due out in the next week or so). Have fun, Marc
Reply by ●June 20, 20052005-06-20
Marc Randolph wrote:> Jeremy Stringer wrote: > >>I'm starting a new project at the moment, and I'm looking at upgrading >>to ISE 7.1, since I prefer not to change synth/par tool versions >>mid-project. I noted that a number of people complained about 7.1 when >>it first came out, but also noted that Service Pack 2 is out now. Can >>anybody comment on the state of ISE 7.1 at the moment? > > > Howdy Jeremy, > > I don't use Linux, but Windoze based 7.1i has stablized enough that > chances are slim you'd run into any problems with it - and even if you > do, they are likely fixed in SP3 (due out in the next week or so).Thanks Marc, Looks like I'll upgrade after all :) Jeremy
Reply by ●June 22, 20052005-06-22
Marc Randolph wrote:>Jeremy Stringer wrote: > > >>I'm starting a new project at the moment, and I'm looking at upgrading >>to ISE 7.1, since I prefer not to change synth/par tool versions >>mid-project. I noted that a number of people complained about 7.1 when >>it first came out, but also noted that Service Pack 2 is out now. Can >>anybody comment on the state of ISE 7.1 at the moment? >> >> > >Howdy Jeremy, > >I don't use Linux, but Windoze based 7.1i has stablized enough that >chances are slim you'd run into any problems with it - and even if you >do, they are likely fixed in SP3 (due out in the next week or so). > >Have fun, > > Marc > > >Unless you are putting RLOCs on the DSP48's. That is still broken in SP2. Last version it worked correctly in is ISE6.3 SP3. ise7.1 SP3 fixes that, but has a problem with the C ports on the DSP48 (the C Port is physically shared by two DSP48 slices, but shows up individually for each slice in the library. If both DSP48s do not have the same value tied to the C Port, its CE input and its reset input, the mapper crashes. If you are careful, that isn't a problem. The problem comes if one DSP48 uses the Cport and one doesn't, you still have to specify the same inputs on both. That creates a packing problem unless you've pre-packed the DSP48s making sure both Cports are wired identically. -- --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 by ●June 22, 20052005-06-22
Ray Andraka wrote:> Unless you are putting RLOCs on the DSP48's. That is still broken in > SP2. Last version it worked correctly in is ISE6.3 SP3. ise7.1 SP3 > fixes that, but has a problem with the C ports on the DSP48 (the C > Port is physically shared by two DSP48 slices, but shows up > individually for each slice in the library. If both DSP48s do not > have the same value tied to the C Port, its CE input and its reset > input, the mapper crashes. If you are careful, that isn't a problem. > The problem comes if one DSP48 uses the Cport and one doesn't, you > still have to specify the same inputs on both. That creates a packing > problem unless you've pre-packed the DSP48s making sure both Cports > are wired identically. >I was just told that they managed to get the CR for the Cport error into SP3, so it sounds like that might work correctly. Time will tell:-) -- --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 by ●June 23, 20052005-06-23
For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade our tools to 7.x but instead wait for 8.1 release in August... Paul C "Ray Andraka" <ray@andraka.com> wrote in message news:kmnue.17953$FP2.12419@lakeread03...> Ray Andraka wrote: > >> Unless you are putting RLOCs on the DSP48's. That is still broken in >> SP2. Last version it worked correctly in is ISE6.3 SP3. ise7.1 SP3 >> fixes that, but has a problem with the C ports on the DSP48 (the C Port >> is physically shared by two DSP48 slices, but shows up individually for >> each slice in the library. If both DSP48s do not have the same value >> tied to the C Port, its CE input and its reset input, the mapper crashes. >> If you are careful, that isn't a problem. The problem comes if one DSP48 >> uses the Cport and one doesn't, you still have to specify the same inputs >> on both. That creates a packing problem unless you've pre-packed the >> DSP48s making sure both Cports are wired identically. >> > I was just told that they managed to get the CR for the Cport error into > SP3, so it sounds like that might work correctly. Time will tell:-) > > -- > --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 by ●June 23, 20052005-06-23
Bo wrote:>For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade >our tools to 7.x but instead wait for 8.1 release in August... > > >I'm still using 6.3 SP3 because there are a few show-stoppers in 7.1. Remains to be seen whether they are all fixed in SP3 or not. -- --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 by ●June 24, 20052005-06-24
Bo wrote:> For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade > our tools to 7.x but instead wait for 8.1 release in August...I was told the same thing. We ran into a problem with timing driven map in 7.1 which made our design impossible to implement. 6.3 works well. They have it fixed in 8.1 (it implemented nicely with 8.1) but it won't be fixed in 7.1 sp3. We were told to skip 7.1 unless we need it for S3E or possibly V4. Jason Daughenbaugh http://www.advanced.pro
Reply by ●June 25, 20052005-06-25
fpgaguy@aedinc.net wrote:> Bo wrote: > > For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade > > our tools to 7.x but instead wait for 8.1 release in August... > > I was told the same thing. We ran into a problem with timing driven > map in 7.1 which made our design impossible to implement. 6.3 works > well. They have it fixed in 8.1 (it implemented nicely with 8.1) but > it won't be fixed in 7.1 sp3. We were told to skip 7.1 unless we need > it for S3E or possibly V4.Looks like I spoke too soon. We also have a design that won't implement in 7.1i (it's very full), but does fine with 6.3i. So maybe my original response to the OP should have been something closer to "7.1i works fine for all but a few things. If you run into those, you'll need to drop back to 6.3i." Marc
Reply by ●June 25, 20052005-06-25
What do you mean by "not implement"? Does it not close timing, not fit in the chip, not route or not create correct logic? Are there any bugs specifically for very full Virtex-IIs? In article <1119714524.207809.146560@o13g2000cwo.googlegroups.com>, Marc Randolph <mrand@my-deja.com> wrote:> > >fpgaguy@aedinc.net wrote: >> Bo wrote: >> > For what it's worth..we were told by visiting Xilinx engineer to NOT upgrade >> > our tools to 7.x but instead wait for 8.1 release in August... >> >> I was told the same thing. We ran into a problem with timing driven >> map in 7.1 which made our design impossible to implement. 6.3 works >> well. They have it fixed in 8.1 (it implemented nicely with 8.1) but >> it won't be fixed in 7.1 sp3. We were told to skip 7.1 unless we need >> it for S3E or possibly V4. > >Looks like I spoke too soon. We also have a design that won't >implement in 7.1i (it's very full), but does fine with 6.3i. > >So maybe my original response to the OP should have been something >closer to "7.1i works fine for all but a few things. If you run into >those, you'll need to drop back to 6.3i." > > Marc >-- /* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
