On 7/18/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
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.
Actually, I was talking about the routing delays from an internal FPGA
SRAM to a single layer of logic, back to the SRAM. This is all
internal. You can run logic very fast in the FPGA, but the SRAM
blocks tend to cause routing issues.
<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?
I have a list somewhere, but it's on a SMB mount, and for some reason,
the mount has hung up. I can't force an unmount so I can remount or
anything. It's just frozen up. Can anyone help?
<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.
Sounds good. Let's start by looking at what needs to happen for each
kind of activity and we'll see if we can find a way to program it
efficiently.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
