Answers Database
Virtex: Things to be careful with when converting 4K designs to Virtex
Record #7180
Product Family: Hardware
Product Line: Virtex
Product Part: Virtex General Hardware
Problem Title:
Virtex: Things to be careful with when converting 4K designs to Virtex
Problem Description:
Urgency: Standard
Problem description:
Things that need to be aware of when converting an existing 4K or Spartan design
into Virtex
Solution 1:
Converting an existing 4K design into Virtex is not an easy task, there are many
things the customer needs to be aware of.
For schematic based designs:
1. Any 4k arithmetic schematic components in 4K families can't be used in
Virtex due to the carry chain differences. This includes adders,
subtractors, comparators, counters, large size of AND, OR gates, etc.
Note: For viewlogic schematics, as long as there is a Virtex library component for that
arithmetic function in 4k family, all that needs to be done is to change the library alias from
xc4000 family to Virtex library alias, and run the Altran utility. For more informatin on Altran
please see http://support.xilinx.com/techdocs/1225.htm
2. Global buffer usage is different. IBUFGs must be used before BUFG if the
clock comes in from an external source.
3. Be careful with the cores that worked in 4K, they may not work for
Virtex because of the architectural differences. Arithmetic cores will
definitely not work.
4. Some RPMs (RLOCs, H_SET, U_SET) will not work in Virtex.
5. Virtex library contains components that 4K families don't have, such as
blockRAMs, SRL16, synchronous SET, RESET FFs, etc, the customers may want
to take the advantage of the new conponents.
6. There are also 4K specific components that Virtex doesn't have, such as
FDSRE, WAND, DECODE, etc. Users need to change them or redesign the logic.
7. Virtex doesn't have IFD and OFD components that 4k families have. To effectively
push the FFs in the IO blocks, users can use IOB=True attributes, or -pr b option when
running MAP. For detailed information, please see http://support.xilinx.com/techdocs/6214.htm
Solution 2:
For HDL based designs:
1. If the codes are written in pure RTL, all that needs to be done is retarget the design to Virtex
and resynthesize them.
2. If there are cores instantiated in the design, some cores will not work in Virtex, especially
the arithmetic cores, such as adders, multipliers, etc.
3. For any other instances, make sure the components exist in Virtex family and the functionalities
are the same. Otherwise, user must find the corresponding components in Virtex and instantiate those
.
4. Take the advantage of BlockRam, SRL16, CLKDLL or any other Virtex specific components.
5. Global clock buffers usage is different. BUFGs must be used for clocks only. Use IBUFG in front
of the BUFG if the clock comes in from the external source.
6. Virtex has no IOB registers primitives. Users need to use the -pr option in MAP or use IOB=true
attribute. For detailed information on how to use IOB FFs, please see
http://support.xilinx.com/techdocs/6214.htm
7. The use of FMAP cells should be discontinued. To place a particular function in a
Look-Up-Table simply instantiate a LUT and add an EQN property or INIT values to it.
8. IPAD, OPAD, and IOPAD cells
The Unified library for the XC4000X series has defined these cells as external
connection points. The use of the cells is inappropriate for HDL based designs for
board level test cases and should be removed from the design. The output of
these cells should be brought to the top level of the design as an input, output, or
bi-directional port.
End of Record #7180 - Last Modified: 10/06/99 10:42 |
