On Saturday 05 February 2005 22:13, Timothy Miller wrote: > On Sat, 5 Feb 2005 16:29:59 -0500, Daniel Phillips > > I'm sure you've already solved this, Timothy. However, I need to > > get a more accurate handle on what's possible with this hardware, > > so here we go again. > > Well, you do and you don't. The solution to the problem is something > that the driver developer never needs to know about. > > I can tell you how it will work, but it's not really something you > NEED to worry about.
Not knowing how the logic goes together means only ever being able to guess wildly at how features map to hardware resources, which isn't very satisfying. But I guess I "need" to know it because at heart, I am an information packrat. My self assessment of my second attempt is, there's something workable in there but it's comically crude. Now let me see if I can come up with something a little more realistic. I imagine that carry propagation is what gets in the way of the two 8 bit adds completing within 5 ns. So my next attempt staggers the two adders by one clock. Each of the two half sums are fed right back into the adder on every clock, and also fed to output latches. An additional latch delays the low 8 bits of the result so the 16 bit accumulated sum is available to following stages on the same clock (and I finally get to use my queue). This is just a fragment of a floating point adder of course, but the object of the exercise was to convince myself that the interpolater can, in theory, run at full speed. Is the logic roughly right? Now that I've had fun trying to roll my own solution, could you please tell me how it should be done? Regards, Daniel
horizontal.step2.dia
Description: GNU Zip compressed data
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
