"Kevin Neilson" < XXXX@XXXXX.COM > wrote in message
news:fvo2o9$ XXXX@XXXXX.COM ...
The methodology I use makes use of every clock cycle, DRAMs are running full
tilt, transfers from fast FPGA through a PCI bus to some other processor,
etc., the whole 9 yards.
Then you're waiting for the wrong acknowledgement. Taking the DRAM again as
an example, every data transfer consists of two parts: address/command and
data. During a memory write, all of this happens on the same clock cycle.
When the controller 'fills up' it sets the wait request to hold off until it
can accept more commands (reads or writes).
During a read though, the address/command portion happens on one clock
cycle, the actual delivery of the data back to the requestor occurs sometime
later. The state machine that requests the read does not necessarily have
to wait for the data to come back before starting up the next read. The
acknowledge that comes back from a 'memory read' command is that the request
to read has been accepted, another command (read or write) can now be
started. There are also situations where one really does need to wait until
the data is returned to continue on, but in many data processing
applications, the data can lag significantly with no real impact on
performance, the read requests can be queued up as fast as the controller
can accept them.
Although I've been using the DRAM as an example, nothing in the handshaking
or methodology is 'DRAM specific', it is simply having to do with
transmitting information (i.e. writing) and requesting information (i.e.
reading) and having a protocol that separates the request for information
from the delivery of that information (i.e. specifically allowing for
latency and allowing multiple commands to be queued up).
That's correct...but you can't start one if the pipe is full (which can
happen when a memory refresh or a page hit occurs and the pipe fills up
waiting while those things get serviced). The handshake tells you that the
pipe is full and you absolutely need to have it. The 'pipe full' signal is
a handshake, when it is full, it says 'wait', when it is not full, it says
Then you're not doing it properly. It's called pipelining, not frittering.
Latency can matter in certain situations, in others it doesn't. If there is
some situation where latency mattered, one would have to come up with a way
where the requestor could start up the read cycle earlier...but if there is
such a way to start it up earlier, then that change could be applied equally
well to the lower latency situation as well which means that you could have
a common design