On Wed, Dec 07, 2005 at 11:49:25AM +0100, Attila Kinali wrote:
> On Tue, 6 Dec 2005 16:50:19 +0100
> Luc Verhaegen <[EMAIL PROTECTED]> wrote:
> 
> > This is probably very alluring from a business point of view, but more 
> > people are budget conscious than Free Hardware conscious. Either you 
> > sell only to those who are willing to splash out a lot of cash for Free 
> > Hardware. Or you can sell the base board to a much larger crowd and sell 
> > the modules to those who are willing to pay the premium.
> 
> 
> > Provide 3 DVO headers on the base board and a whole range of submodules 
> > (which are rather simple to design).
> > - Offer the baseboard bare for the lowest price.
> > - Offer the modules seperately.
> > - Offer the baseboard together with a few common combinations for a 
> >   price lower than baseboard + seperately bought modules.
> 
> I think this idea is quite good, especialy if such modules
> are already available and they use a common standard.
> 
> If there are no such modules or they are incompatible,
> then we should not waste our time trying to support it.
> 
> And yes, this is now a bussiness decission rather than
> a technical decission.
> 
>                       Attila Kinali
>
These modules are of course not very compatible, as no-one really has a 
standard header. Hence the whole ADD card mess; intel vs nvidia vs sis 
vs via, all using a different AGP pinout.

But the only real technical problem is the header pinout and the 
placement on the board, because you really should pick a single header 
and a single layout so that all modules can be interchanged.

The design of the submodules is then rather simple, just as simple as 
placing these on the board. All that should should be taken into account 
is that the actual bus tracelength is kept as short as possible, then 
the incurred interference can be kept low. This can be solved by having 
these headers close to the fpga (much like the placement on the gladiac).

The use of headers for submodules might even ease routing on the board 
itself. You have at least 2 chips (the sil178s for duallink) and 
their "dressing" that you don't have to place on the board, all you need 
to route is the headers.

As for the dual link submodules, a tiny impedance difference between 
both links is probably acceptable, and this is about the only way in 
which the actual encoder to display device link could cause problems.

For these duallinks submodules the following layout could be a 
possibility.

If the FPGA is sitting roughly where the geforce 2 is sitting on the 
gladiac (or nvidia reference design), then the DVO header could sit 
around where it is sitting on the gladiac. Since this board is going 
to have 2 DVI-I connections, the layout of the blanking plate is 
already known, and the position of the secondary TMDS links are already 
known too. These secondary links could get a 4*2 header too, as close to 
the dvi connector as possible. These two headers combined are enough to 
provide for duallink DVI with the second sil178 sitting on a submodule.

If the exact same layout is used for the lower and upper halve of 
the board (and the lower and upper DVI connector), then you have 
interchangable modules.

Since the submodule has ample room for a 64 pin TQFP (and dressing) in 
the space between the headers, then the board itself must have ample 
room for a similarly sized chip on the fpga side of the board. The other 
side of the board could hold the other output, onboard, device. Routing 
will be a lot easier than it is now.

You might even get away with a 2 layer process for the submodules, 
further reducing the cost.

It makes technical sense (to someone with my low level of experience and 
electronics knowledge), it makes commercial sense, the only reason why 
one can be against this is the fact that this is being dug up this late 
in the development of the fpga based board.

Luc Verhaegen.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to