FPGA Pinouts ... documentation error??
Added by Thomas Catalino about 12 years ago
(posted for a customer)
I have purchased one of your MityDsp Development kits to use as a reference platform for a base board design. Things are moving along really nice, at least until I started trying to reconcile Xilinx documentation for the XC6SLX45 FGGA and the carrier board design guide for the MityDSP-L138F...
When I try to compare the listing of the pins on the interface connector with the xilinx pinout for the part (in the Spartan-6 FPGA packaging and Pinouts document) , I get stumped.
For example: pin 191 lists (in the carrier board design guide for MityDsp-L138F ) as B0_1P.C7 . But when I look up IO_L1P on the xilinx pinout for the CSG324 package, I find that it is connected to pin D4 (and pin C7 is connected to IO_L10P_0). No matter how I try, I can't make that add up...
I am sure I am missing something totally vital here, but cannot figure out what that is (and I am pretty sure that my VHDL is not going to be working if I can't connect stuff to the right pins on the FPGA :).
Can you please let me know what I am missing.
Replies (1)
RE: FPGA Pinouts ... documentation error?? - Added by Michael Williamson about 12 years ago
Hi,
In the data sheet as well as the design guide, the DDR3 edge connector pin naming scheme did not map the "pair number" of the BX_YY_P.ZZ or BX_YY_N.ZZ name (where X is bank number, YY is essentially an arbitrary pair number, and ZZ is the FPGA ball number) to the IO_LWWP_0 (where WW is the Xilinx pair number) as found in the Xilinx user guide. We mapped the Bank Number and the ball position, but the pair numbering was renumbered 1 through 48.
I don't know why that was done that way, but I suspect during layout of the SOM the pairs were getting shuffled around, and the engineers and/or spec authors capturing the design stopped renaming the nets for risk of capture error. I appreciate, now, how it could be confusing.
Please accept our apologies.
Our engineers here always use the Ball Number when developing the UCF files (and there is a reference UCF file available in the board support package, BTW). I would recommend you do the same. The Ball number is ultimately the required information for constraint definition.
-Mike
