On Nov 30, 2007 4:25 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > > At the moment, the primary goal is correctness. We can put off SOME > > performance issues until somewhat later in the process. In > > particular, if you optimize too early, you obscure the semantics of > > what you're doing, making it much harder to debug. > > I've been worried that we'd still had to change the semantics in order > to reach timing goal. If you thing it looks realisable, then let's > carry on under that assumption.
The nice thing about this situation is that we CAN. As long as we keep the assembler and the code up to date, it'll be fine. > > This is why I did the PCI controller in stages. [...] > > Thanks for the explanation. It's good to know the method of postponing > optimisations kind of works also in hardware design with a lot harder > constraints then in software. Optimizing too early just makes it an incomprehensible mess. Now, PCI is an extreme case, because I had to force restructuring of the logic in ways that ISE would not have done voluntarily. Xilinx even told me, when I opened a web case, that my manual MUX approach was about the best I was going to do. But it's nasty. Instead of burying selections in the logic in a way that makes semantic sense.... well, let me be clearer.... There are, I believe, 3 or 4 different inputs from PCI that we cannot register because we need to use the signals directly on a given cycle. These include #STOP and #IRDY. Let's say we have an internal state or output or whatever that depends on those two. What I had to do was design logic to generate what the state would be for each of the four possible combinations of those signals, force ISE to generate logic for those, and then MUX those based on the inputs. It's vital to use those inputs at the absolute last stage of the logic. Since they're coming in from the PCI bus, there's already a huge delay on them. (Out from the driver, delay on the bus, ad input buffers in our FPGA.) There were cases where I had to MUX 8 different possibilities. IIRC, it wasn't any worse than that, although it will be when we do the Master. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
