On 5/28/05, Eric Smith <[EMAIL PROTECTED]> wrote: > Patrick wrote: > > Ok, here are some assumptions I made. > > > > Load/store architecture > > unified instruction, data, registers. In other words the 512 memory > > locations contain both code data and registers > > > Looking at the instruction count, I think we can certainly use one of > > the FPGA 512x36 RAM blocks for the nanocontroller. > > The XC3S1500 has 32 of the 18Kbit BlockRAMs, and the XC3S4000 has > 96 of them, so it's probably reasonable to allocate several to the > nanocontroller to provide flexibility. And after all, it's an FPGA, > so tweaking the number of BlockRAMs assigned to the nanocontroller > should only be a matter of changing a few lines of RTL. > > The block RAMs have only two ports, so you can't use a single one > for code, data, and registers.
Unless the processor uses more than one cycle for an instruction, which it probably will need to anyway. > > For a load/store architecture (that doesn't do both simultaneously), > you might be able to share one block RAM between instructions and > data. But if pipelining requires that data written by store > instruction n has to be be written at the same time as data read by a > load instruction n+1, then a separate block RAM is needed for data > (or a stall/pipeline bubble). The lookup-table nanocontroller was going to take gobs of cycles per instruction. Taking a handful per instruction instead without pipelining is going to be a massive improvement. Some things can be pipelined, but not everything. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
