Timothy Miller wrote:
On 3/17/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
Timothy Miller wrote: Perhaps using LVDS driver chips (also to be
un-populated on the standard board) could be use to free up some
pins. These would need to be mounted very close to the FPGA
Short search found Fairchild FIN1102 rated at 800 MB/s 3.3v supply
would accept 2.5v LVC input levels with no extra parts unless you
wanted a series termination resistor. Priced @ $1.20 (1K). Only
two channel so you would need 18 of them. Doesn't sound like a
great idea, but it would work.
Are you suggesting inserting an extra device in between the FPGA and
the DAC? For a high-speed signal?
Yes I am considering it. The issue isn't speed it is skew, and this
would depend on the skew spec of the FPGA. There might be too
much skew and faster drivers (Ti rated 2 GBPS) are too expensive.
And regarding using the LVDS pins, it's all or nothing. For
high-speed signals, you really want point-to-point.
This is still point to point, there are no stubs. One HiRes LVC output
goes to one channel of the driver IC which drives one LVDS input pair on
the DAC. Note that the trace between the FPGA and the LVDS driver would
have to be a short trace and they would all need to have about the same
length and capacitance.
We're doing badly enough routing them to two places. Also, you seem
to be suggesting that we canibalize pins from the high-speed head to
improve the low-speed head.
Actually, I was suggesting that we use single ended outputs from the
FPGA instead of the LVDS in order to free up pins to improve the HiRes
head and the low-speed head.
What if you wanted to use both at the same time?
Would be the same as it is now, and I'm not certain exactly how that
works, but there are separate data lines for the two heads.
Or are you saying you've identified some totally unused LVDS pins?
Haven't looked at that yet. But, IIUC, we do have some unused "top and
bottom" pins. According to the Lattice dox, these pins can be used for
LVDS with an external resistor network. But, again, skew might be an issue.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
