This is the inward-facing interface for the PCI controller.
// Read signals
output [31:0] read_address;
input [31:0] read_data;
output deq_read, start_read, end_read;
input read_valid;
output doing_read;
When reading begins, the start address, given by the PCI bus, is
provided here, along with the assertion of start_read. Typically, an
internal agent would begin queueing reads starting from that address.
read_address does increment after each read has been accepted, so you
can use that directly with some limitations on combinatorial chains.
doing_read is asserted throughout the entire read burst and is a
general indication that reading is or will be requested.
deq_read is an indication from the PCI controller that it is able to
accept a data word from the internal logic.
read_valid is an indication from the internal logic that the data on
read_data is valid and can be given to the host.
An internal agent should only advance to the next word (dequeue if
it's using a fifo) when both deq_read and read_valid are asserted at
the same time.
When a read burst finishes, end_read is asserted, and other logic
should flush any relevant queues at this time.
In terms of fifo protocol, read_valid is valid_out, read_data is
data_out, deq_read is deq. The fifo advances when deq and valid_out
are asserted at the same time.
If you have a read request queue, fill it separately, using your own
counter. Typically, we only pay attention to the read_address on the
first cycle when start_read is asserted. The rest of the time,
addresses come from a separate counter. For graphics memory, it's
actually the read cache that requests a line of words through a single
request over the bridge. Then those N words come back and fill the
cache. As words appear in the cache, they're given to PCI. In this
case, the clock period is so long that we could probably make the
cache memory unregistered and use read_address[x:0] combinatorially on
the cache RAM.
// Write signals
output [31:0] write_address;
output [31:0] write_data;
output [3:0] write_bytes;
output do_write;
input can_write;
output doing_write;
The write path has a separate write_address from read_address. This
is because a write could still be pending at the time that a read
request comes in from PCI. That is, the PCI target can be no longer
in a write state yet a pending (unclaimed) write is still sitting in
its output registers. Internal logic would not normally try to
perform a read and write at the same time; rather, it would simply not
respond to any read requests as long as do_write is high and can_write
is low. Indeed, it is that internal logic that would control the
can_write signal.
can_write is an indication form internal logic that it can accept
write data. do_write is an indication to internal logic that a write
is being given. When both can_write and do_write are asserted at the
same time, internal logic should accept the data word and become ready
for the next (or deassert can_write).
doing_write is a general indication that the PCI controller is working
on a write burst.
write_address, write_data, and write_bytes go together and are valid
with do_write.
In terms of fifo protocol, can_write is !full, {write_address,
write_data, write_bytes} is data_in, and do_write is enq. The fifo
advances when enq and !full are asserted at the same time.
// Common signals
output [4:0] access_target;
access_target is a one-hot encoded indication of which BAR is being
addressed by PCI.
These are the meanings of the bits:
0 - config space
1 - BAR0
2 - BAR1
3 - BIOS PROM
4 - VGA legacy I/O
// Other
output [31:0] decode_address;
input [4:0] decode_target;
[Some of the address decoding is looped through the config space
logic. This just needs to be hooked up right.]
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
