Timothy Miller wrote:
It can be difficult to get logic and block rams in a Spartan to go at 200MHz (the speed I want to run the DDR memories), but we can work on this concept.
The first thing that you need to worry about in registered output. You have an output register (edge triggered) clocked with the same clock as the memory. So you have one clock cycle for the propagation delay (including the board traces) plus the setup time for the memory chip (which might be 0 or less [I didn't check yet]). If the chip can make that, there are tricks to get the logic to run faster than is possible for a standard registered state machine -- although I don't know if these will all work on a FPGA in the same way as they would with hardware logic.
<SNIP>
The other approach is programmable (so it can go into an ASIC). You have registers that are loaded with your timing numbers, and perhaps multiple counters. Only when a counter is zero can you execute its associated command. What I'd like to try to do is once again turn hardware into a program file. Instead of counters, the current machine state is used to generate an address into an on-chip block RAM, and that's used to handle delays.
Actually, before you work on the implementation, you need to do the state machine design.
Here are some random thoughts I have on this: Let's say the delay between an activate and a read is 5 cycles, and the delay between a read and a precharge is 5. BUT the delay between an activate and a precharge is 12 cycles. This is simple enough. Somehow, the read command and the current state generated a starting program counter address for the block ram (maybe via a config register). The data outputs from the RAM indicate two major things to the controller: Which memory commands to assert on the memory control bus (like the precharge and activate commands), and which controller commands are acceptable at a given time. So, rather than having a 3-bit counter to count those 5 cycles, there are 5 "instructions" in our program file.
Specifically which timing parameters can vary? What do you want to make programmable?
<SNIP>
This is a high-level design topic. You don't need to know hardware (much) to help with this. Just think about how the controller needs to behave and see if you can find a way to turn current state and requested controller command into realtime code.
Doesn't matter how this is going to be implemented, you first need to design the Markov chain. I use a spreadsheet program. Have the current state number (0 to N) for the Column labels and a row for each possible input. Each cell will contain an integer entry for the number of the next state.
I also make a suggestion for the design since glitches happen. Have state 0 for the reset state with no other normal way to get there, and have this have only one hard coded transition being to the start of a refresh cycle. State 1 would probably be best as the ready waiting state which would loop until either an access or refresh request.
When you fill out the spreadsheet remember that each cell must be filled. So all cells that would represent illegal state transitions should have a 0 in them so that any glitch will result in a reset state and a refresh cycle.
-- JRT _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
