On 9/15/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > On Thu, 15 Sep 2005 08:45:23 -0400 > Timothy Miller <[EMAIL PROTECTED]> wrote: > > > On 9/15/05, Attila Kinali <[EMAIL PROTECTED]> wrote: > > > > The only drawback of this system is, that we need to compute > > > first what states could come next from the current state, > > > but that could be hardcoded into a few LUTs. > > > > Yeah. Computing the next state numbers based on the current state is > > exactly what I wanted to avoid, because it puts more layers of logic > > between the slow inputs and the state registers. > > You do not have to. The calculation of the possible next > states comes from the current state. You still use the slow > input signals just to select one of the computed states at the > very end (like in your aproach). The only difference is > that "my aproach" might save us some of the duplication by > eliminating more of the "paths" that we do not need to follow.
Ok. That's fair. Unfortunately, I can't quite see how to implement that, because the idea I get from what you said requires too much current-state knowledge in the slow-signal logic. Perhaps we can discuss this further and I'll get it. It's also possible that I'm being extremist. I'm very paranoid about external input signals. I'm the same way about output signals--every one MUST be registered. I have no combinatorial outputs. That makes the design somewhat harder sometimes, since I have to know everything one cycle early, but the result is faster I/O. That's another reason why I am combining the master and target, rather than designing two separate state machines and muxing their outputs. FPGAs are just not suited to doing fast I/O without registering outputs, and it's also quite preferable to register inputs when possible. The propagation delay from input buffer to internal FPGA register is WAY higher than the propagation delay from the input buffer to its own IOB register. The same is true for outputs. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
