>Jaap,
>
>The waveforms will look different at any point OTHER than across the
>termination.
>
>You can see this for yourself in the simulation, by placing the
>package element in the simulation (i.e. two short -- 10-20mm t-lines
>before the termination and IO pin loading model).
>
>If you have already done this, then you are aware of where you look
>influences what you see.
>
>Looking directly across the termination is what the receiver sees, so
>that is what matters.
OK, clear from a simulation point of view. We are measuring as close as
possible to the receiver e.g. the termination, but this is not always
possible, due to the location of via's (micro-strip to stripline and v.v.),
which may not always be as close to the termination as you would like them
to be.
Anyhow, what we see is not a "normal" reflection, but a RC-curve on top of
the reflection. This RC-curve is "killing", the reflection itself is more
or less as expected. If we manually place a 100 ohm resistor on the board,
and disable the on-die termination, the RC-curve has disappeared, and the
signal looks as neat as you can possibly expect. In this case, the
reflection is there but very OK, and the eye-diagram is well open.
The problem is that we need about 40 of these extra 100 ohm resistors, on a
board which is already loaded....
>
>The termination is not a carbon resistor, but it is as good as one
>when it comes to looking like a resistor, so that is not the issue.
>Often, the attribute is not set properly, and the resistor is not
>enabled. Have you checked in FPGA_editor, and do you clearly see the
>resistor termination enabled?
Yes, we did this check, the attribute was set both in the VHDL as in the
UCF, and we checked the results using the FPGA Editor, and the pinning
file.
>Does the receive voltage appear twice
>as high as it is indicated in the simulation? (clearly indicating the
>resistor is not enabled)
>
>You do not mention the problem: bad data, occasional incorrect data,
>bad data when other IOs switch only, etc.
Basically all of the items mentioned above. Bad data could be the result of
many issues (internal FPGA I/O timing, SSN, clock jitter requirements,
etc.).
We are trying to eliminate them one by one, to narrow down on the real
cause(s).
>
>As a customer, the magic words are "lines down." If you say this, the
>case MUST be escalated. If unresolved, it must be escalated again and
>again, until it gets to the "Fire Marshall" who reports to the Senior
>VP and CEO on unresolved cases, and their status.
>
>Since I invented, implemented, this system, and was the first Fire
>Marshall, I am very familiar with the system, and it works really well
>-- use it!
>
>A case number is very useful: if you email it to me, I can check on
>its status, and help get it escalated.
OK, thanks. As I said, Xilinx is already involved, a RMA procedure was
started but temporary halted on our request because we needed more time to
do our homework. Until now, we haven't been able to find anything that we
have done wrong ourselves. Today, I have been working with some collegues
to connect a DSP evaluation board (ADI EZ-Lite TS201) with LVDS-based DSP
Link Ports direcly to a FPGA evaluation board (Xilinx ML403), e.g. without
any hardware being designed by ourselves (only interconnect consisting of
two RJ45/UTP cables). The FPGA only will contain a loopback (TX to RX and
v.v.), elimination any possible internal timing issues.
If we encounter the same RC-curves on this design, we can stop our attempts
to find the error in our own designs (PCB/board/FPGA), and
redesign/relayout all our boards, which will be extremly costly and also
time consuming. We have already started these redesigns (in parralel), to
reduce leadtime and risk.
We are finishing a report on our measurements, simulations, etc this week,
and we will forward it to our Xilinx representatives.
>
>
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com