On Friday 04 February 2005 23:21, Daniel Phillips 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?
Because the producer and the consumer are one and the same piece of logic, and it can only do one thing at a time (ie, read new input, process it, and put it into the queue, or read something from the queue, process it, and pass it on). Lourens _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
