Or were you after the logic of having an extra array? Hence the possibility of a higher sku?
Well, maybe "in addition to", but it seems to me you'd want redundancy inside the arrays as well, and that is your best leveraging. Larger arrays leverage your redundant unit(s) better (i.e. you need fewer of them), while increasing the cost of having array-level redundancy --if you aren't using that large redundant array it's still dead silicon to you even if it "works". If your arrays are small enuf then the math probably starts working in favor of extra arrays instead. But it seems to me that decoupling and granularity are really the powerful leverager for getting the best bang for the buck, particularly if you are engaging in them anyway for performance reasons and you get to ride that extra addressing/scheduling logic "for free" on the yields side.
Edit: Was writing this before I saw your last. . .
Well, maybe "in addition to", but it seems to me you'd want redundancy inside the arrays as well, and that is your best leveraging. Larger arrays leverage your redundant unit(s) better (i.e. you need fewer of them), while increasing the cost of having array-level redundancy --if you aren't using that large redundant array it's still dead silicon to you even if it "works". If your arrays are small enuf then the math probably starts working in favor of extra arrays instead. But it seems to me that decoupling and granularity are really the powerful leverager for getting the best bang for the buck, particularly if you are engaging in them anyway for performance reasons and you get to ride that extra addressing/scheduling logic "for free" on the yields side.
Edit: Was writing this before I saw your last. . .
