Xilinx ISE - how to improve erratic timing optimization?

[asmi]

I'm super interested to hear that, I'd been sticking with S6 and ISE in a VM just down to cost.
Current pricing on the S6 - 16k is <$6USD Qty 1.
https://lcsc.com/product-detail/CPLD-FPGA_XILINX_XC6SLX16-2FTG256C_XILINX-XC6SLX16-2FTG256C_C39313.html

Where can we get this sort of pricing on S7?

I was comparing prices at DK and Mouser. You might want to talk to Xilinx sales to see if you can get a better deal (I'm sure you will, the only question is just how good will it be). Though smaller S7 are only available in packages with 100 user IO pins (FTGB196 with 1 mm pitch, CSGA225 with 0.8 mm pitch, and CPGA196 with 0.5 mm pitch), if you want more than that in 1 mm pitch package, you will have to step up to S50 and FGGA484 package (it has 250 IO pins).

[Someone]

There are many things you can do. Of course, if you do not want to make any changes then nothing will change 

I think this is where the discussion fails. There are many possible ways to improve timing on a design, but they usually involve significant architectural changes to the HDL and not just a sprinkling of magic pixie dust in the constraints/build parameters.

1) learn what the critical path is (if it radically changes from build to build thats a hint you're resource constrained, see 3b)
2) redesign the structure or clocking of the critical path to improve timing along it
2b) add constraints to make the tools find a quick solution on the critical path (based on some obvious mistake that is visible in routing at step 1)
3) return to 1)
3b) diversify the build flow (ISE smart explorer) and hope for a lucky solution among many many attempts

Most of this is best left for once the design is "finished" and ready to package up as a release, trying to chase the last 10% of timing in the middle of the design is usually a waste of time.

[NorthGuy]

Uh yeah. I have a design on a Spartan 6 that is not even that complex (but it's a CPU). I get a 110MHz max frequency, and among the longest paths, routing delay alone takes up to 7ns. My design uses 23% of the FPGA resources, so it's far from congested. I use almost all block RAM available though.

I have explained this few posts back (even with geographical examples ). You have many logic layers. The logic layers are connected through switch boxes. These switch boxes produce the routing delay you see. If you divide the routing delay between logic layers, and you'll see that a single logic layer doesn't need big routing delay. But when you have many layers the routing delay grows. This has nothing to do with covering distances within FPGA, or congestion, or anything of that sort. Decrease the number of logic layers, and the routing between them will go away. That's how you make the design work faster.

[ebastler]

All -- I just wanted to say thank you again for many helpful hints in this thread! I have understood that trying to optimize for the last few percent of performance at the very edge of the design is not a good idea, and is not what the timing and placement constraints are meant to achieve.

Since I am so close to my symbolic 100 MHz target, I will go for the pragmatic "solution" suggested by NorthGuy and tggzz, and just overclock by a few percent. This is a hobby project anyway, nothing mission-critical.

As a next step, I will look into Spartan-7 FPGAs. (Although in this particular application they do end up being 50% more expensive than the Spartan-6, even at Mouer prices for both, since my BRAM needs require a larger S7 chip.) But I am certainly tempted to switch to Vivado, and see how the S6 and S7 compare performance-wise.

[tom66]

I really like the Zynq.  Once you get used to some of its idiosyncrasies, it is a *really* nice platform.  You can easily move GB/s of data around.  The platform is pretty easy to understand.  The A9 is a fast ARM, even though the clock rate is not particularly high.

Vivado is f**king terrible though.

[SiliconWizard]

Uh yeah. I have a design on a Spartan 6 that is not even that complex (but it's a CPU). I get a 110MHz max frequency, and among the longest paths, routing delay alone takes up to 7ns. My design uses 23% of the FPGA resources, so it's far from congested. I use almost all block RAM available though.

I have explained this few posts back (even with geographical examples ). You have many logic layers. The logic layers are connected through switch boxes. These switch boxes produce the routing delay you see. If you divide the routing delay between logic layers, and you'll see that a single logic layer doesn't need big routing delay. But when you have many layers the routing delay grows. This has nothing to do with covering distances within FPGA, or congestion, or anything of that sort. Decrease the number of logic layers, and the routing between them will go away. That's how you make the design work faster.

Well, true in general. (But I still consider that route delay. Xilinx tools do as well.)

In one of my examples, I get : Data Path Delay:      8.611ns (Levels of Logic = 5)
(2.031ns logic, 6.580ns route)

5 levels is significant, but not that large. But on this path, there is some Block RAM.
There are actually paths with a slightly larger number of logic levels and shorter route delay.

That may be "fixable" by helping placement I guess, but I didn't bother as 100 MHz was my goal here.

[NorthGuy]

5 levels is significant, but not that large. But on this path, there is some Block RAM.
There are actually paths with a slightly larger number of logic levels and shorter route delay.

When you start from the BRAM without output register, there will be big initial delay within BRAM, which Xilinx consider a routing delay too.

Regardless, if you have a chain of elements to connect there are delays associated with the elements - internal delays within the element (BEL delays as they call it), launching delays (to reach the switch box), pin delays (to get the signal from switch box to the element). Plus every element will connect to two fixed switch boxes - one for the input and one on the output. The switches within boxes will produce further delays. Whether you consider these to be routing delays (as Xilinx does) or not, you must endure all of these delays as soon as you add the element to your chain. These cannot be eliminated by better routing (althogh you can improve some of these, for example by selecting faster LUT pins). If you've got 10 ns of these, you cannot run at 100 MHz, no matter how good your routing is. It is therefore outright counterproductive to try to solve the problem by improving routing.

However, you can get in a situation where you know the solution exists, but the tools cannot find it. This can be caused by either congestion, or by high clock speed. You can try to fix the congestion problem by using better floorplanning, and you may succeed. Similarly, if you have high speed project, you can manually place your elements, sometimes duplicate some logic, sometimes route manually. These are routing problems - you have acceptable design, but it will only work if the routing improves.

And, of course, you need to be able to distingush one from the other.

[nctnico]

I have a nearly completed VHDL design for the Spartan 6, implemented via ISE 14.7. The automated synthesis and place/route process reliably produces a design which runs at above 90 MHz, but then things get erratic. (Yep, 90 MHz are not a whole lot -- the major bottleneck is that I am using all block RAM as a large 64 kByte RAM, so there are long routing delays to and from the outer blocks.)

I would like to push this to 100 MHz, mainly because that's a three-digit number.
I can come close, and did get timing closure at 100 MHz once, but the optimization results have been frustrating. It seems pretty clear that the place & route does not always find the optimal result. E.g.:

• I set the internal clock to 94 MHz, and the timing results tell me that my design can run at up to 98.x MHz. So I set the clock to 98 MHz -- and get a design that only runs at up to 92 MHz. I did check the clock jitter and it did not increase with the adjustment to 98 MHz, so that's not the cause.
• Trivial changes to some VHDL signals, which clearly have nothing to do with the critical paths, also can throw the result off track significantly.
  
• I switch the clock generation from PLL (which is power-hungry) to DCM_CLKGEN, which makes the clock jitter a mere 25ps worse. But the penalty on the resulting overall design clock speed is nearly 10 MHz?! Both clock generators are directly driving a BUFG, so I would assume clock distribution behaves the same for both of them.

Timing and placement constraints are probably the answer to my frustration, but I struggle with them. Based on earlier advice here, I have declared some false paths for signals derived from stationary inputs, and at least that seems to do no harm --- although I am not sure about reliable improvements. I have also tried placement constraints to put some critical functionality fed by the BRAM close to the chip's center, to ensure it's equidistant to the outermost BRAMs on both ends of the chip. This helps in one particular place/route run, but then when I change some other trivial detail, the placement restriction actually makes the results worse compared to a run where I remove it.

What's the right way of doing this? I have not found any good tutorials with specific advice on how to use constraints in a robust way. Thanks for any hints you might have!

It is a bit of a black art to get a design routed and close timing. First of all I'd start by setting the clock constraint to 100Mhz and don't mess with lower frequencies. Make sure to have timing constraints from the inputs to the flipflops (PADS(*) to all_ffs) and from the flipflops to the pads (all_ffs to PADS(*)).
Then route your design. If it fails use the timing analyser to see which paths are the slowest ones. It may help to change the setting to have more paths in the timing analyser log so more failing paths can be checked. If you only need a little bit of extra speed you can try to place an element manually and/or play a bit with the 'starting placer cost table'. Something else to look at is how full your FPGA is. If it isn't very full then disable the optimisation. This sounds crazy but I have a reasonably large project which uses an oversized FPGA. If I enable optimisation all the logic gets packed together and the timing towards the IO pins is impossible to achieve.

[dnotq]

3. Have you considering migrating to Spartan-7? They are significantly faster than S6, they are cheaper, and you can use Xilinx's Microblaze core for free if that's what you want.

Duh... no, I had not considered that yet. And I had not even realized that the S7 is lower cost than the S6; had always assumed it was the other way round by a fair margin. Better chip performance, modern toolchain, lower cost -- seems worth a look indeed, thank you!

This is not always true, and newer is not always better.  I have a project using the S6 because it is just as cheap, or cheaper than the equivalent S7, but also mostly because the 7-series is not hobbyist friendly.  The newer chips are pushing the packages smaller and smaller, and a 0.5mm ball-pitch CSP (or smaller) is just not doable for hobbyists yet.  The PCB features needed to route and escape the chip-scale stuff are 6-layers minimum and 0.0762mm (3mil) traces.  The "standard" affordable boards are 4-layer and 0.127mm (5mil) at best, with 0.25mm (10mil) drills for vias.

edit: I stand corrected, the S7 has just about the same size and ball-pitch packages as the S6 in the low-end of the chip range.

For me, the S7 did not offer the right size package + features + price that was right, but I could get the S6 in exactly what I needed (15mm @ 0.8mm ball pitch), it was available at DigiKey and Mouser, it was cheap ($20 per chip), and I can manage to assemble the prototypes in my reflow oven.  I could not go to a larger package because I'm space constrained by a PCB size requirement.

edit: The S7 has the same package, but only half the available physical I/O in that package and price.

Also, IMO, Vivado is awful compared to ISE.  I have a few 7-series devboards, and the first time I went to use Vivado, I thought I had done something wrong because my "blink an LED" design took, literally, 10-minutes to generate a bit-stream.  I could not believe it.  And Vivado is a huge bloated mess.  At lease ISE is smaller-ish, and works pretty well.

edit: I have been "informed" I am doing something wrong and I should get on the bandwagon.

Yes, it is unfortunate and really crappy the way Xilinx handled the transition from ISE to Vivado, right on the cusp of Win7 to Win10, and dropping support for S6 in Vivado.  They lost some of my respect for sure, but clearly they do not care about that.  Also, I managed to find (somewhere) on the Xilinx website that the S6 line is going to be in production through 2024 or 2026 (can't remember exactly), and that was enough for my project.

Sorry for the rant, it just gets old when people always push the latest thing, for the sake of it being the latest.  But sometimes you cannot always jump on the latest and greatest, and sometimes the old and reliable is good enough (or better).

As for the timing problem with BRAM, it seems you have gotten a lot of help and I hope something worked for you.  I have used a S6 with a design at 100MHz that used all the BRAM, and did not have too much trouble.  The 100MHz design even came from a Spartan-3E, but the largest single block was only 16K in that case.  All I can suggest is to register your inputs and outputs, and add a pipe-line (register) stage to help ease the routing constraints.

[asmi]

I'm seriously impressed by the amount of crap you managed to stuff in a single post.

This is not always true, and newer is not always better.  I have a project using the S6 because it is just as cheap, or cheaper than the equivalent S7, but also mostly because the 7-series is not hobbyist friendly.  The newer chips are pushing the packages smaller and smaller, and a 0.5mm ball-pitch CSP (or smaller) is just not doable for hobbyists yet.  The PCB features needed to route and escape the chip-scale stuff are 6-layers minimum and 0.0762mm (3mil) traces.  The "standard" affordable boards are 4-layer and 0.127mm (5mil) at best, with 0.25mm (10mil) drills for vias.

This is pure BS. S7 has just one package with 0.5 mm pitch, all other packages are 0.8 and 1 mm pitch. All FPGAs I used so far were in 1 mm pitch packages.
So - year - newer isn't always better, but in this case it is better. MUCH better.

For me, the S7 did not offer the right size package + features + price that was right, but I could get the S6 in exactly what I needed (15mm @ 0.8mm ball pitch), it was available at DigiKey and Mouser, it was cheap ($20 per chip), and I can manage to assemble the prototypes in my reflow oven.  I could not go to a larger package because I'm space constrained by a PCB size requirement.

Well - guess what - S7 comes in the very same 15 mm @ 0.8 mm pitch package (CSGA324), there is also smaller package 13 mm @ 0.8 mm pitch available (CSGA225). But my favorite one is FTBG196 - 15 mm @ 1 mm pitch with 100 user IO and fully routable on any 4 layer process. That just shows me that your didn't bother doing any research.

Also, IMO, Vivado is awful compared to ISE.  I have a few 7-series devboards, and the first time I went to use Vivado, I thought I had done something wrong because my "blink an LED" design took, literally, 10-minutes to generate a bit-stream.  I could not believe it.  And Vivado is a huge bloated mess.  At lease ISE is smaller-ish, and works pretty well.

That's one more sign that you've done something wrong. Vivado is waay ahead of ISE, features-wise ISE is stone age.

Yes, it is unfortunate and really crappy the way Xilinx handled the transition from ISE to Vivado, right on the cusp of Win7 to Win10, and dropping support for S6 in Vivado.  They lost some of my respect for sure, but clearly they do not care about that.  Also, I managed to find (somewhere) on the Xilinx website that the S6 line is going to be in production through 2024 or 2026 (can't remember exactly), and that was enough for my project.

Do you use VHDL for your designs? It fits the pattern.

[ebastler]

I'm seriously impressed by the amount of crap you managed to stuff in a single post.

I realize that you were not talking to me, but since I am also pondering the Spartan 6 vs. 7 decision (triggered by your earlier suggestion -- thanks again for that!), your post does make me wonder. Why the aggressive tone? You seem to be "emotionally invested" in the Spartan-7 line? 

I agree with you that the available packages are not a reason to stay away from the S7. The fact that Xilinx has retained the 0.8mm pitch BGAs is a plus for me; those are nicely usable with the low-cost PCBs available from JLCPCB, Aisler etc.; other FPGA brands don't seem to offer that format.

But I do see other disadvantages vs. the S6 in my current project -- which has some space and power constraints, and needs 64 kByte of on-chip RAM: There seems to be no way around a third power rail for the S7 (1.0V Core, 1.8V Aux, 2.5V or 3.3V I/O). Modelled power consumption for the S7 is actually higher than in the equivalent S6 design, due to its 60mW "static" base load and the power-hungry clock managers. And the smallest S7 which meets my memory needs is the XC7S25, which is 50% more expensive than the XC6SLX9.

So it's clearly "horses for courses", and your "newer is better" statement oversimplifies things.

Do you use VHDL for your designs? It fits the pattern.

Now what's that supposed to mean? Why don't you toss in a "Linux vs. Windows" debate as well, for good measure? 

[asmi]

I realize that you were not talking to me, but since I am also pondering the Spartan 6 vs. 7 decision (triggered by your earlier suggestion -- thanks again for that!), your post does make me wonder. Why the aggressive tone? You seem to be "emotionally invested" in the Spartan-7 line? 

I'm emotionally invested in preventing people from spreading BS. We have too much of it already.

I agree with you that the available packages are not a reason to stay away from the S7. The fact that Xilinx has retained the 0.8mm pitch BGAs is a plus for me; those are nicely usable with the low-cost PCBs available from JLCPCB, Aisler etc.; other FPGA brands don't seem to offer that format.

Yea, that's the part I really like. Even super-high pin count packages retain 1 mm pitch, which is very rare nowadays.

But I do see other disadvantages vs. the S6 in my current project -- which has some space and power constraints, and needs 64 kByte of on-chip RAM: There seems to be no way around a third power rail for the S7 (1.0V Core, 1.8V Aux, 2.5V or 3.3V I/O). Modelled power consumption for the S7 is actually higher than in the equivalent S6 design, due to its 60mW "static" base load and the power-hungry clock managers. And the smallest S7 which meets my memory needs is the XC7S25, which is 50% more expensive than the XC6SLX9.

Take a look at Artix-15. It's got more memory, though it's probably still more expensive than XC6SLX9. I personally don't care for such low end (I use parts mostly in 35-100K cells range), so not sure.
As for power rails - S7 does not require 3.3 V rail, so you can get away with just two - 1.0 V for Vccint and 1.8 V for PLL and IO. 1.8 V rail can be reused for DDR2 memory (which is what the project in my signature does), so it's hardly a waste. And the only disadvantage of DDR2 over DDR3 is this case is capacity (because S7 can only go up to 400 MHz, which is achievable for both DDR2 and DDR3). Though for low power you might want to choose DDR3L. I'm not sure about that because none of my designs are battery-powered, so my only concern as far as power goes is thermal - basically making sure nothing gets too hot.
Also you seem to ignore the fact that 7 series fabric and hard IP blocks are two times faster than in S6. That's got to count for something I think.

Now what's that supposed to mean? Why don't you toss in a "Linux vs. Windows" debate as well, for good measure? 

No, I explained it above - it fits the pattern.

[ebastler]

Take a look at Artix-15. It's got more memory, though it's probably still more expensive than XC6SLX9.

Similar price as the Spartan-25. And unfortunately the Artix series is not available in the 225-ball, 13*13 mm²BGA.

As for power rails - S7 does not require 3.3 V rail, so you can get away with just two - 1.0 V for Vccint and 1.8 V for PLL and IO.

Right -- I neglected to mention that I need at least 2.5V for the I/Os. For the S6, that means 1.2V core and 2.5V or 3.3V combined Aux/IO voltage; for the S7 I need three supplies. Again, the choice of the "right" FPGA depends on the task at hand.

Also you seem to ignore the fact that 7 series fabric and hard IP blocks are two times faster than in S6. That's got to count for something I think.

That might count for something. I need to come up to speed with Vivado and actually try to put my design on the Spartan-7. Looking at the S6 and S7 datasheets, I surprisingly couldn't find the claimed higher speed of the S7. The stated BRAM and CLB access times were actually slower in the S7. I might have overlooked other aspects there, of course; the proof will be in generating the design.

No, I explained it above - [using VHDL] fits the pattern.

I still am not sure I get your drift. If you meant to imply that using VHDL fits a pattern of producing BS, I hereby feel officially insulted. 
(I, for one, use VHDL almost exclusively. I get annoyed with its wordiness at times, but it has easily made up for that with all the errors of mine which it has found already during synthesis. And I am not aware of any difference in the synthesis results. So again, what's your point?)

[NorthGuy]

The stated BRAM and CLB access times were actually slower in the S7.

This is not accurate. Looking at the docs (DS162 vs DS189).

Max BRAM frequency is 280 MHz for S6-2 and 388 MHz for S7-2.

The combinatory LUT delay (for the fastest input pin) is 0.26 ns for S6-2 vs 0.11 ns for S7-2.

S7 is exactly the same as A7, except there's no -3 grade.

[asmi]

Similar price as the Spartan-25. And unfortunately the Artix series is not available in the 225-ball, 13*13 mm²BGA.

If you can make do with a bit over 100 user IO, you might want to take a look at CPG236 or CPG238 packages. They are 0.5 mm pitch, but if you will look at the pinout diagram (see attachment, it shows power pins), you will see that you can fully route it out on just 2 layers (provided you can fit a trace between 0.5 mm pads).

Right -- I neglected to mention that I need at least 2.5V for the I/Os. For the S6, that means 1.2V core and 2.5V or 3.3V combined Aux/IO voltage; for the S7 I need three supplies. Again, the choice of the "right" FPGA depends on the task at hand.

That is not FPGA requirement, If my design requires 5 different power rails, I can't hold it against FPGA. But again - the current trend is towards lowering interface voltage, so I appreciate that they eliminated 2.5 V rail which is very rarely used (except for LVDS) - typically it's either 3.3 or 1.8 V. So I will choose 1.8 V over 2.5 V any time, because it's actually useful (just about all my boards have some sort of 1.8 V peripherals, so that rail would be required anyway).

That might count for something. I need to come up to speed with Vivado and actually try to put my design on the Spartan-7. Looking at the S6 and S7 datasheets, I surprisingly couldn't find the claimed higher speed of the S7. The stated BRAM and CLB access times were actually slower in the S7. I might have overlooked other aspects there, of course; the proof will be in generating the design.

It only takes a single look at datasheets to see the difference. S6 BRAM Fmax is 320 MHz for the fastest speed grade, but in S7 Fmax for BRAM is 388 MHz for the *slowest* speed grade. The difference is even more impressive for DSP tiles, despite the fact that S7 DSP is more advanced than in S6. BRAM's clock-to-out time is about two times better if you use output register (which you should if you care about performance).

I still am not sure I get your drift. If you meant to imply that using VHDL fits a pattern of producing BS, I hereby feel officially insulted. 
(I, for one, use VHDL almost exclusively. I get annoyed with its wordiness at times, but it has easily made up for that with all the errors of mine which it has found already during synthesis. And I am not aware of any difference in the synthesis results. So again, what's your point?)

There is a bit of a history on this forum, when few avid VHDL propagandists are content to spread all kind of BS without bothering to do any research first to see if their arguments actually have any merit. It doesn't have anything to do with you, unless you are one of them.

[ebastler]

The stated BRAM and CLB access times were actually slower in the S7.

This is not accurate. Looking at the docs (DS162 vs DS189).

Max BRAM frequency is 280 MHz for S6-2 and 388 MHz for S7-2.
The combinatory LUT delay (for the fastest input pin) is 0.26 ns for S6-2 vs 0.11 ns for S7-2.
S7 is exactly the same as A7, except there's no -3 grade.

I was referring to BRAM clock to data out time, which is critical in my design (1.85ns for S6, 2.13ns for S7) and to CLB AX..DX to output times. I may have compared apples to oranges when looking at the CLB times; the slower BRAM access time is clearly relevant to me.

Btw, I did compare the fastest speed grades for both families, i.e. -3 for the Spartan 6, as I did when comparing prices.

[NorthGuy]

I was referring to BRAM clock to data out time, which is critical in my design (1.85ns for S6, 2.13ns for S7) and to CLB AX..DX to output times. I may have compared apples to oranges when looking at the CLB times; the slower BRAM access time is clearly relevant to me.

You can use BRAM with output register, or without. The path from output register is made much faster in 7-series, so you can achieve much faster reading frequency.

The AX .. DX are inputs for dedicated MUXes, which are slow anyway. You probably will never see them on your critical path.

BTW, LUT delays  are sort of phony anyway. The datasheet lists 0.11 ns for LUT for S7-2, but this is only for the fastest pin. For all other pins there are pin delays which dwarf the number. For example, pin delays from the S7-2 speed file are:

Code: [Select]

A1 - 0.435 ns
A2 - 0.428 ns
A3 - 0.283 ns
A4 - 0.231 ns
A5 - 0.090 ns
A6 - 0.004 ns
When this get combined with the LUT delays, you get real numbers. Say, pin A1 will have 0.54 ns delay, nothing close to 0.11 ns for pin A6. That's the same pattern for S-6. So, there's no reason to dwell on posted numbers - these are for marketing. Look at your design closure instead. I can tell you, 7-series are faster.

[dnotq]

I'm seriously impressed by the amount of crap you managed to stuff in a single post.

I'm seriously impressed by the amount of rudeness you managed to stuff into a single reply.

This is pure BS. S7 has just one package with 0.5 mm pitch, all other packages are 0.8 and 1 mm pitch. All FPGAs I used so far were in 1 mm pitch packages.
So - year - newer isn't always better, but in this case it is better. MUCH better.

This is pure BS, that you need to be such a jerk about correcting someone.  Not everyone is unwilling to admit they made a mistake.  Sorry for being human.

It is true, and I stand corrected, the 7S15 does have the same packaging I am using.  I had to go review, since I looked hard and long at the S7 when I was making a choice.  After reviewing again, I see the 7S15 in the CSG225 package only has 100 I/Os over two adjacent banks.  Cost is about $20, so similar to the LX9 I'm using.  It is not until you get into the 7S25 that you get the extra I/O, but the 7S25 is in the $35 to $40 range.

Well - guess what - S7 comes in the very same 15 mm @ 0.8 mm pitch package (CSGA324), there is also smaller package 13 mm @ 0.8 mm pitch available (CSGA225). But my favorite one is FTBG196 - 15 mm @ 1 mm pitch with 100 user IO and fully routable on any 4 layer process. That just shows me that your didn't bother doing any research.

Let me offer an alternative: I did my research over a year ago and did not remember exactly why I had to rule out the S7.  I thought it was the packaging because I really wanted to use it.  I apologize for making the mistake of not remembering correctly, and I certainly should have reviewed the S7 packages before posting.  Your reply just shows me that you must be an intolerant person, and no one should make mistakes around you.

That's one more sign that you've done something wrong. Vivado is waay ahead of ISE, features-wise ISE is stone age.

Clearly I'm a walking mistake and better keep my mouth shut.  Thanks for making that clear.  Never mind trying to suggest looking at Vivado again because maybe it has gotten a lot better since I tried it last, or anything else constructive, to keep the conversation helpful.

Do you use VHDL for your designs? It fits the pattern.

Do you use Verilog or SV for your designs?  It fits the pattern of your attitude.

@ebastler: I apologize for this, it is not what I intended or expected to happen.  I was just trying to help, but I should have checked my facts first.

[OwO]

haha whenever I see asmi enter a thread I just know the pot's about to stir

I'm just here avoiding the S6 vs S7 debate by using $6 salvaged Artix-7 XC7A100T 

[asmi]

Let me offer an alternative: I did my research over a year ago and did not remember exactly why I had to rule out the S7.  I thought it was the packaging because I really wanted to use it.  I apologize for making the mistake of not remembering correctly, and I certainly should have reviewed the S7 packages before posting.  Your reply just shows me that you must be an intolerant person, and no one should make mistakes around you.

I usually do my research before I post anything. When I don't and write from memory, I always explicitly say so ("As far as I remember", "If my memory serves me", etc.). This way readers can see what is fact, and what is opinion (possibly wrong). I would have zero problems with your entire post if it would mention if it's opinion and not fact. I would still correct inaccuracies, but the tone would be totally different.
I certainly admire that you can admit a mistake (very few people ever do that, and even less so online), and I do apologize for a bit of a harsh tone - it's often hard to "feel" the person behind the text.

[asmi]

I'm just here avoiding the S6 vs S7 debate by using $6 salvaged Artix-7 XC7A100T 

For commercial production?

[OwO]

For commercial production?

Nah just hobby projects. The only commercial project I've been involved with so far that used an FPGA used a cheap spartan 6 (XC6SLX9).

[asmi]

Nah just hobby projects. The only commercial project I've been involved with so far that used an FPGA used a cheap spartan 6 (XC6SLX9).

Well we're discussing real commercial products here. The calculus changes quite a bit when you start shipping your stuff to the customers and you are required to provide support in case something happens in the field.
For commercial prototypes the price of chips is not important as it's still peanuts in R&D budget, and majority of it goes towards paying for engineers' time. When you have to pay 600$ or more per day to every single engineer employed in the project, even 500$+ chips are little more than a pocket change in the grand scheme of things.

[ebastler]

Well we're discussing real commercial products here.

Oops, I didn't realize that.
Pure amateur here. May I stay around? 

[asmi]

Oops, I didn't realize that.
Pure amateur here. May I stay around? 

Of course you can. Just keep in mind that nobody should ever buy Xilinx chips from the likes of DK for production. If you talk to Xilinx directly, you can get much better prices even if your volume is not very high.