On 2006-07-18, Timothy Miller wrote: > 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.
Sounds good, so if the controller just uses the bank select as upper address lines, the client hardware can take care of efficient utilisation. > >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 found it. Posted 2006-06-07 if someone on the list is up to fixing Icarus (hint, hint, hint). The code: http://www.samsung.com/Products/Semiconductor/DDR_DDR2/DDRSDRAM/Component/256Mbit/K4H561638F/k4h561638f_0501.tar > >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. That clears up a few things. I can see that pins connect differetly depending on access width. Are we going to use 16 bit mode? Also, what widths shall the controller support? I think we can support 16 and 32 bits almost for free with a programmable controller. As follows is a revised instruction set, exploiting a direct mapping from opcode bits to some of the control signals for most opcodes. ==== opcode[4:1] is roughly (CS_, RAS_, CAS_, WE_) opcode[0] is one of {A[10], CKE, BA[0]} for some of the commands opcode instruction operands special ----------------------------------------------------------------------- 1vvvvvvv S jump target = opcode[6:0] 01000000 S done 01vvvvvv S if_row_hit target = opcode[5:0] 001vvvvv S wait count = opcode[4:0]; 0 means 32 00010000 dselect 0001001v S set_cke level = opcode[0] 0000111x no_operation 0000011x active (bank, row, _) = addr 0000101x read16 (bank, _, col) = addr 00001000 write8 (bank, _, col) = addr DM=2^addr[0] 00001001 write16 (bank, _, col) = addr DM=3 0000110x burst_terminate 00000100 precharge_bank (bank, _, _) = addr A[10]=0 00000101 precharge_all A[10]=1 00000010 self_refresh CKE=0 00000011 auto_refresh CKE=1 00000000 E load_mode_reg 13 bit operand BA[0]=0 xxxvvvvv vvvvvvvv 00000001 E load_extmode_reg 2 bit operand BA[0]=1 xxxvvvvv vvvvvvvv Flags (second column): S: software or special instruction, operand bits do not correspond to the CS_, RAS_, CAS_, WE_ lines. E: 16 bit extended operand loaded from program memory ==== One possible complication is the operand of load_mode_reg and load_extmode_reg. It would be convenient to have the operand for those in program memory, at least for some tasks like initialisation. That means that the hardware must fetch two consequent bytes from program memory and shift them into the address. Maybe not a big deal, just two extra states. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
