On Fri, 4 Feb 2005 17:21:03 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > On Friday 04 February 2005 14:40, Timothy Miller wrote: > > On Fri, 4 Feb 2005 14:22:56 -0500, Daniel Phillips > <[EMAIL PROTECTED]> wrote: > > > On Friday 04 February 2005 12:01, Daniel Phillips wrote: > > > > It appears that it's impossible to do 16-bit integer adds or > > > > subtracts in 5ns on a Spartan 3. Usually, when you are just > > > > pipelining everything, that's no big deal. Just split the math > > > > into 8-bit stages. (I've done it plenty of times.) > > > > Unfortunately, there are two parts of the design, the vertical > > > > and horizontal rasterizers, that make it a bit challenging in > > > > that regard. > > > > > > Hi Timothy, > > > > > > I'm trying to understand what you mean by this. I imagined that it > > > doesn't matter how many stages it takes to step to the next > > > horizontal pixel pair, because you're only concerned about > > > throughput, not latency. I must have missed something. > > > > You have a single chunk of logic that must iterate over pixel pairs. > > In order for it to know what to compute for one cycle, it must know > > the result of the previous cycle. If the computation takes more than > > one cycle, then it cannot iterate once per cycle. Latency becomes > > throughput. > > But why can't we solve this with an intermediate queue that holds the > same number of entries as stages in the iteration?
Ummm... I'm not sure I understand what you're saying, but it sounds vaguely like the solution I already have. :) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
