On 7/17/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
Some questions:
Is it a good idea to operate banks in parallel, so that we always select
the same row and column in all banks? What granularity do we want for
the data? Eg we could combine two columns of each bank to a 8 bit data
word or 8 columns of each bank to a 32 bit word. I'm thinking we could
have an instruction which shifts 4 bits from all banks into the data
output register, so that a fragment of the program might look like
Well, you can't activate a row in more than one bank at a time. You
can overlap the activation, but you end up waiting longer for the
particular request. Rows are long, and there's a lot of spatial
locality.
In the past, I have arranged memory so that banks divide the memory
into quarters. This way, you can read from something in one bank and
write to a different row in another bank. So, if you put the display
buffer at the beginning of memory and pixmaps at the end, you can
bitblt from pixmaps to screen with a minimum of row misses.
; A jump table at address 0. When the controller gets a request
; it asserts the busy-line of the controller, and sets the PC
; according to the instruction, and start executing.
jump refresh
jump read8
jump write8
...
read8:
; branch if row of requested address matches current row of banks
if_row_hit read8_hit
close_row ; close any opened row on banks
noop^CLOSE_ROW_CYCLES
open_row ; open row of requested address and set
; current column according to address
noop^OPEN_ROW_CYCLES
read8_hit:
shift_out_4 ; shift 1 bit from the 4 banks into output word
; and increment column
noop^NEXT_COLUMN_CYCLES
shift_out_4 ; shift 1 bit from the 4 banks into output word
; and increment column
done ; suspend execution
The noop^CONSTANT is expanded by the assembler to CONSTANT instructions,
if we don't implement repeats in hardware.
You're getting the idea.
What is the difference between a refresh and a precharge-all? You
promised we didn't need to know about hardware... ;-)
We're still conceptual here. :)
A refresh implicitly requires a precharge-all. The explicit one is
required for doing load-mode-register. You would: turn off refresh,
precharge-all, wait (in software), lmr[0], wait, lmr[0], wait,
reenable refresh.
Are there any module declaration available for the memory? I assume the
RAMB16_S36_36.v is not representative since it seems too simple; that's
SRAM, right?
That's an SRAM internal to the FPGA. I posted something about a
simulation model for the DRAMs we're using and how the one from
Samsung doesn't work with Icarus, but no one bit.
I was thinking about doing incremental refresh, using opportunities
where there are no requests, but forcing an incremental request at a
mimimum frequency if there were no opportunities. We could do this with
a behavioural block which has priority to issue refresh instructions. It
would have one counter for the refresh period, one counter for the next
row to refresh, one top-priority refresh request line and one
bottom-priority request line. Would that be good or will there be
larger windows when we can do a full refresh?
You would need to keep track of how long ago each row was refreshed
and issue the refresh for the oldest one, etc. The thing is, if you
just blindly issue an auto refresh every 7 ms, you use like 1% of your
bandwidth. The extra logic isn't worth it.
I'm thinking it may be sufficient with 128 byte of program memory with 1
byte instructions where the top bit selects a jump, and no subroutines.
But if the instruction memory fills up with noop, we might need a (short)
repeat count for it.
Preliminary instructions format
0AAA AAAA jump AAAAAAA (relative or absolute, whichever is easier)
10AA AAAA if_row_hit AAAAAA (relative PC, -32..31 or maybe 0..63?)
1100 RRRR noop^RRRR
1111 0000 open_row
1111 0001 close_row
1111 1000 shift_out_4
1111 1001 shift_in_4
1111 1111 done
I have made some wild guesses here about the character of the problem,
but all these detail should expose the wrong assumptions.
We're heading in the right direction. Have a look at a comprehensive
DDR SDRAM spec. The one I have is for a Micron MT46V16M16.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
