This is more of a stating point than a proposed design and request for
comment. Some more thought needs to be put into how other blocks
communicate with this (fifos, etc.), and we need to work out the
issues associated with the two-cycle latency of any signals crossing
the bridge (busy signals, etc.).
/*
This is the low-level control logic for the XP10 side of the bridge.
This assumes that other logic enforces the fact that address, read, and
write commands are mutually exclusive and that commands cannot be sent
while reads are pending.
Somewhere, we need to keep track of the number of pending reads.
Obviously, the logic in the Spartan does, but for this side, we need
to be able to tell when reading is done so we can send more commands.
We could do that here and incorporate that into the busy signal.
What probably needs to bolt into this is something with fifos.
For writes, we know when the address changes, so we should just include
in the fifo data a bit that indicates whether the data is an address.
*/
module xp10_bridge(
input clock,
input reset_,
// Status
output reg busy,
// Providing an address
input [27:0] address,
input [3:0] access_target,
input do_address,
// Read requests
input [6:0] read_count,
input do_read,
// Read return
output reg [31:0] read_data,
output reg read_valid,
// Writes
input [31:0] write_data,
input [3:0] write_bytes,
input do_write,
// External interface
input [31:0] bridge_ad_in,
output reg [31:0] bridge_ad_out, // connect in and out signals to same pins
output reg bridge_oe; // output enable on bridge_ad
output reg [3:0] bridge_bytes,
output reg [1:0] bridge_cmd,
input bridge_rdata_valid,
input bridge_busy
);
// Note: All bridge I/O signals are registered, both in the Xilinx and
// the lattice. That adds two cycles of extra latency on anything
// getting through. One important consequence is that fifos on the
// other side must report busy 3 cycles early (we also register our
// internal busy signal).
// Concern: If both FPGAs default to tristate for the ad bus, that could
// cause oscillations if we have no pull up/down. Or is that not the case
// with CMOS?
// bridge commands
parameter b_idle = 2'b00;
parameter b_addr = 2'b01;
parameter b_rcount = 2'b10;
parameter b_write = 2'b11;
always @(posedge clock or negedge reset_) begin
if (!reset_) begin
busy <= 0;
bridge_oe <= 0;
bridge_ad_out <= 0;
bridge_cmd <= 0;
bridge_bytes <= 0;
end else begin
bridge_cmd <= 0; // clear the command
busy <= bridge_busy;
bridge_oe <= 0; // default to reading
read_data <= bridge_ad_in;
read_valid <= bridge_rdata_valid;
if (do_address) begin
bridge_oe <= 1;
bridge_ad_out <= address;
bridge_bytes <= access_target;
bridge_cmd <= b_addr;
end
if (do_read) begin
bridge_oe <= 1;
bridge_ad_out <= read_count;
bridge_cmd <= b_rcount;
end
if (do_write) begin
bridge_oe <= 1;
bridge_ad_out <= write_data;
bridge_bytes <= write_bytes;
bridge_cmd <= b_write;
end
end
end
endmodule
--
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)
