- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Xilinx 14.1 - TMDS differenti al IO map "Packing" error - Atlys Spartan6 LX45
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-19-2012 04:17 PM
Hello,
I've come across an error in my project that has stumped me. When I based my design off Digilent's supplied HDMI "echo" project, everything worked fine.
However, when I generated my own system in XPS (using the BSB support files on Digilent's site), I get a map error for each of the hdmi_in component's signals <see attached system_map.mrp>, along the lines of:
ERROR:Pack:2908 - The I/O component "hdmi_in_0_TMDSB_pin<0>" has an illegal IOSTANDARD value. The IOB component is configured to use single-ended signaling and can not use differential IOSTANDARD value TMDS_33. Two ways to rectify this issue are: 1) Change the IOSTANDARD value to a single-ended standard. 2) Correct the I/O connectivity by instantiating a differential I/O buffer.
What's troubling me is that:
1) The hdmi_in component *does* instantiate an IBUFDS for each of the input signals (see line 255 in serdes_1_to_5_diff_data.v and line 137 in dvi_decoder.v)
2) The hdmi_in component (as well as the hdmi_out component) hasn't been modified one iota from what's used in the working system, and the corresponding lines in the MHS and UCF files are either identical or functionally equivalent (i.e. perhaps a different name, but that's all).
Can anyone shed some insight into *why* I might be getting this error, when quite clearly the differential input buffers are indeed being instantiated, and the components are properly mapped in Xilinx 14.1 in another design?
I really appreciate your help!
Solved! Go to Solution.
Re: Xilinx 14.1 - TMDS differenti al IO map "Packing" error - Atlys Spartan6 LX45
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-20-2012 04:51 PM
Well, that was dumb. It appears I acidentally hit backspace in my MHS file, and erased the 'B' from the end of the signal name connected to the hdmi_in port. Oops.
But, now I have another troubling problem. The MPMC component instantiates a BUFPLL_MCB to drive the memory, but this BUFPLL_MCB cannot be placed, because it "needs to have all of its IOB loads placed into its same IO bank." Specifically, it complains that the BUFPLL_MCB and the IOB load "udqs_p_pin" cannot be placed onto the same IO bank.
Of course, after outputting this message, map.exe crashes....
I do not understand why this is the case, when the automatically-generated NCF file for the MPMC is identical to that generated in the working system, and the relevant MPMC parameters are also the same.
I only instantiate one BUFPLL in the system, and only one BUFPLL_MCB. I suppose it's possible that the BUFPLL and the BUFPLL_MCB (which uses two BUFPLLs on the same bank and so cannot be used with another BUFPLL on the same bank) must be mapped to the same bank, but I really doubt it. The other BUFPLL is instantiated for the TMDS transmitter, and the HDMI output port is on bank 1 while all DDR2 connections (and the MCB configured to be used) is on bank 3.
At this point I'm really unsure how to proceed. How can I view the proposed placements? How can I see the conflict? And, more importantly, how can I resolve this?
Thanks.
Re: Xilinx 14.1 - TMDS differenti al IO map "Packing" error - Atlys Spartan6 LX45
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-22-2012 02:48 AM
I solved this problem by manually LOCing the BUFPLL_MCB to the appropriate BUFPLL_MCB for Bank 3 (where the DDR2 signals are on the Atlys board.
For any potential Googlers, this is just one line in the UCF file, something like:
INST "MCB_DDR2/MCB_DDR2/mpmc_core_0/gen_spartan6_mcb.ge
Of course, the instance name should be changed to whatever the corresponding name is in your design.











