1. Home
  2. Field-Programmable Gate Arrays
  3. Spartan3E - problem in creating LVDS DDR pads

Spartan3E - problem in creating LVDS DDR pads

Hi all,

I am trying to create LVDS, bidirectional, DDR I/O pads in a Spartan-3E chip (xc3s500e).

I've created an I/O pad in VHDL which simply instatiates and connects Xilinx library components: * IOBUFDS = bidirectional, differential I/O pad, * IDDR2 = S3E input DDR logic, * ODDR2 = S3E output DDR logic, Tri-State control is not DDR - I've added a simple FF instance.

The pad matches a subset of the S3E description of the I/O pad logic.

When I try to implement a chip using these I/O pads, the synthesis and Translate stages complete without errors, but the Map stage outputs the following error for each I/O Pad:

ERROR:Pack:1564 - The dual data rate register Data_Pad/IO_Pad6/Out_DDR_Reg/Data_Pad/IO_Pad6/Out_DDR_Reg/ODDR2.C0D1

failed to join the DIFFSI component as required. Symbol Data_Pad/IO_Pad6/Out_DDR_Reg/Data_Pad/IO_Pad6/Out_DDR_Reg/ODDR2.C0D1

is not a kind of symbol that can join a DIFFSI component.

From what I've been able to find, the DIFFSI is the "negative"

pin of the I/O pad - the I/O logic is placed at the "positive" pad, but borrows resources from the negative pad, which can't be used for anything else.

The error is connected to having bidirectional pads; when I used separate input and output pads, there were no errors.

There is no difference in the errors when I place LOC constraints on the positive, negative, both or none of the I/O pads.

The IDDR2 and ODDR2 have Generic options to control clock alignment, some of which borrow FFs from the negative pad; changing these Generics make no difference in the errors.

I am using ISE7.1i, SP4 (problem appeared in SP3 as well). The Xilinx knowledge base doesn't have anything about this error.

Anyone knows what is the problem and if there is any way to fix it? please help, I am getting pretty desperate (need to start board layout).

Thanks in Advance

Reply to
assaf_sarfati
Loading thread data ...

Hi,

LVDS is not a bidirectional standard. It is a standard that has sinks, and sources (as in one each, a source at one end, and a sink at the other).

You will have to do something a bit non-standard to do this.

I saw one suggestion to use a bus-LVDS output, with an LVDS input, where now you can actually control the output (go tristate).

But, perhaps there is someone else out here who has managed to figure out how to do this (in spite of the fact it isn't a standard, so we have little reason to support it).

Austin

assaf snipped-for-privacy@yahoo.com wrote:

Reply to
austin

We have been using the LVDS BUS mode for some time now and it works well enough... haven't tried it as DDR so can't qualify that part.

I have found that you have to be excessively explicit about tieing things down.. and you MUST use the UNISIM libraries or it won't work... XST keeps optimizing things down until it won't connect correctly any more.

I ended up creating a standard IO block which has 3 latches (can be inferred) the inverter (from UNISIM) and the LVDS tri-buffer and receiver (FROM UNISIM) Inside the block I use pragmas to force the flip flops into the IO buffer although I have seen it ignore this but it doesn't seem to matter at the speeds I'm running at. I also use a few keeps to prevent optimizing of the inverters etc....

What would be better, of course, is to have a standard symbol which when placed, allowed you to select the IO standard, tri-state or not, receiver or not, IO latch or not. It would simplify things down.

Simon

other).

Reply to
Simon Peacock

What I meant was: I want to create a bidirectional, differential I/O pad, using LVDS voltage-levels and signaling, and Dual-Data- Rate transfers.

My problem is in the low-level entity encapsulating the I/O pad and the assicated DDR logic.

BTW, the same problem occured when I created separate input and output pads (each with the required DDR logic), and tied the I/O pins together at the top level. I guess the mapper recognizes that both input and output paths go to the same pad, places them together and THEN chokes on it. If the I/O pins are kept separate without any other change, everything is implemented correctly.

I wasn't trying to implement a "real" LVDS standard, and my design has the provisions to change direction cleanly without glitches and bus contention.

Reply to
assaf_sarfati

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.