Granted, I've left out the important numbers in the title. To be more precise: this post is only for those of you maintaining an existing PCB design containing one or more
Xilinx Virtex-II devices.
Many times it happens that you're forced to touch the board again because of discontinued parts (no,
not the Virtex-II), minor circuit improvements or feature requests from your customers. So why not upgrade the Virtex-II to a package-compatible
Spartan-3A at the same time?
No way!? Why should you do that? Valid points but before I'm going to explain why it could make sense in certain situations I want to introduce the prerequisites for the upgrade:
- it works only for the FG256 package (Virtex-II devices from XC2V40 to XC2V1000)
- the system frequency must not exceed 300 MHz
- your VHDL/Verilog design is without (too many) device specific instantiations or physical constraints
If these (heavy) requirements apply to your design this could be your migration path:
| Original part | Potential upgrade part | Upgrade part |
|---|
| XC2V40 | | XC3S200A |
| XC2V80 | | XC3S200A |
| XC2V250 | XC3S400A/XC3S700A* | XC3S1400A |
| XC2V500 | XC3S700A* | XC3S1400A |
| XC2V1000 | XC3S1400A* | N/A |
With the extension of the Spartan-3A family in August 2008 Xilinx now ships the entire device family in the
FT256 package. The
FT256 is slightly thinner but
FG256 "compatible". Now, it's possible to replace a small to mid-range Virtex-II by using a large Spartan-3A.
In the table above I did the logic, multiplier and DCM resources comparison for you to find the appropriate replacement candidates (see third column). The second column lists all Spartan-3A devices that have the same amount of CLB logic than their Virtex-II "counterpart" but less multiplier/BlockRAM resources. So if your design doesn't use 100% of these non-CLB resources they might be an alternative, too. That's why I've called them potential upgrade parts.
Now back to the question: Why? I know it's a lot of work and not as easy as replacing just the FPGA in the next board revision. It requires adjusting the core voltage, changing the layout, rewriting constraints, updating production specs etc. etc. But it will pay off in the following points:
- lower costs per board
- lower power consumption (due to reduced core voltage)
- less heat dissipation
- more logic/CLB resources for future extensions
Which I consider valid reasons for small to large volume products and especially battery powered applications. Please note, this post is not meant to be a HOWTO or guide nor can I guarantee you that it works for all designs. I wanted to share the idea and research work with you. In case you find this interesting or want to exchange experiences I would be glad to hear back from you.
