On 3/22/07, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
Timothy Normand Miller wrote:
> It won't be long before we'll have to design a nanocontroller for OGD1
> to manage VGA and DMA. I may be able to just go off and design one
> myself, but I think that many of you would fancy observing and
> participating in the design process, and with more brains on it, we'd
> do a better job.
I will try to help with this. Although I have to report that although I
understand the basics of Verilog that I haven't had the same success
with a self taught crash course as I did in PostScript. :-)
Well, while I think that Postscript is quite different from lots of
other languages, being stack-based, I think Verilog is more different.
Well, not exactly. You can code Verilog like software, but it won't
synthesize. The challenge is in learning how to structure a hardware
design... and then use Verilog to represent it.
Isn't it more usual to have a load store architecture with 2 address
operations? OTOH, there are supposed advantages to register set
processors (no accumulators).
The idea is to have a load-store architecture, except that the "main
memory" is only 512 32-bit words, and the graphics memory is accessed
via I/O ports.
> This is also where we need to deal with branches. If the instruction
> is a branch, the condition needs to be resolved, and the address needs
> to be fed back to stage (1). This is why RISC processors typically
> have a delayed branch. The possible branch conditions are reg-value=0
> and reg-value!=0.
Were you planing to have a skip on condition instruction?
Not as such. Does MIPS have that? (Not to say that we have to be
tied to that.) We COULD have it...
> The MIPS processor stays simple by not having any result flags. That
> is in an x86 processor, math instructions yield carry, zero, negative,
> and overflow flags (among others). MIPS doesn't do that, because it
> causes all sorts of challenging dependencies. You're better off using
> a few extra instructions and having a processor that's simpler and
> faster for everything else.
Yes, the saving the state beyond the next instruction causes real
problems. Exception is that if the next instruction is a BRANCH then
you keep it for another cycle. That allows for multiple way branches.
Speaking of saving state, that reminds me. We could have interrupts.
Having exceptions that are caused by part of the instruction pipeline
complicates things horribly, but we could easily enough allow for
interrupts, as long as they're always initiated from FETCH, and they
never occur right after a branch instruction.
You could use more than one bit and then have a branch instruction use
these.
COMPU R11, R12
BOC <condition>, <location>
COMPU is compare unsigned. You also need COMPS and COMPF.
BOC the condition code (4 bits) is compared to the bits in the condition
register branch is taken if any of them match. BONC condition doesn't
branch if the condition is met.
I've actually considered this. But I like how MIPS is so dead simple.
The result of a compare is stored in a regular register...
> I believe the MIPS processor uses the ALU to add the contents of one
> register to a short immediate value stored in the instruction, and
> that's used as the address. We should do the same. That makes it so
> that the only memory addressing mode is reg-value + offset.
I don't see how this helps. You can't presume that the register with
the base address is available until the start of the execution stage of
the pipeline so instruction fetch is going to take two cycles. One to
do the add and a second to do the fetch. If we eliminate the offset we
would gain speed (one clock) when an offset wasn't required, break even
part of the time (sequential reads on a base address) and loose when we
were doing random access based on a base register.
The adder is in the decode (second) stage. I'll have to scan a
picture of the page in the book with the diagram...
> (5) Register write-back
> The register file read in stage 2 is actually double-pumped. It runs
> at double the clock rate of the rest of the processor. On the first
> half clock cycle, we perform writes. On the second half, we perform
> reads. In fact, you might say that stages (2) and (5) are really
> parts of the same stage.
>
You mean (for example) that write occurs on the rising clock and read
occurs on the falling clock?
That is the effect we want, yes. (We can't do it exactly this way in
an FPGA, but we can fake it with a 2x clock.)
--
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)
