I'm currently working on wiring the XP10 toplevel module together, and I
started with the SPI interfaces. What I'm currently pondering upon is
twofold. First would it make sense to separate the two command FIFOs to
the each SPI. Currently, in the included patch I solved this by having a
wide FIFO, but is better if I split it into two fifos for the read /
write commands ?
Secondly, what should I connect the FIFO buffers to at the other side (
the not SPI side )? The schema seen here[1] shows glue logic, but where
is that located? Should this be done by microprogramming in the HQ?
This would lead to more IO ports in the HQ.
[1] http://www.cse.ohio-state.edu/~millerti/ogd1_vga_diagram.pdf
--
Life on the earth might be expensive, but it
includes an annual free trip around the earth.
Kenneth Østby
http://langly.org
Index: xp10_top_level.v
===================================================================
--- xp10_top_level.v (revision 196)
+++ xp10_top_level.v (working copy)
@@ -62,7 +62,7 @@
output xilinx_din,
input xilinx_done,
output xilinx_programn,
- input xilinx_initn,
+ input xilinx_initn
// Oscillators and such
// ...
@@ -340,19 +340,126 @@
);
+/// SPI BIOS -----v
// FIFO for read commands to BIOS SPI controller
+wire [7:0] spi_bios_command;
+wire [23:2] spi_bios_address; // 21
+wire [3:0] spi_bios_be;
+wire spi_bios_do_write;
+wire spi_bios_dummy;
+// = 36
+wire [35:0] spi_bios_data_out;
+assign spi_bios_command = spi_bios_data_out[0:7];
+assign spi_bios_address = spi_bios_data_out[8:29];
+assign spi_bios_be = spi_bios_data_out[30:33];
+assign spi_bios_do_write= spi_bios_data_out[34];
+assign spi_bios_dummy = spi_bios_data_out[35];
+fifo_16 #(36) spi_bios_command(
+ clock(clock),
+ reset(reset_),
+
+ data_in(),
+ enq(),
+ full(),
+
+ data_out(spi_bios_data_out),
+ valid_out(spi_bios_comm_valid),
+ deq(),
+ empty()
+);
+
+
// FIFO for read return from BIOS SPI controller
+wire [31:0] spi_bios_data;
+fifo_16 #(32) spi_bios_data(
+ clock(clock),
+ reset(reset_),
+
+ data_in( spi_bios_data ),
+ enq(spi_bios_data_valid),
+ full(spi_bios_data_full),
+
+ data_out(),
+ valid_out(),
+ deq(),
+ empty()
+);
+
+
// SPI prom controller for BIOS
+assign bios_si = spi_bios_si;
+assign bios_so = spi_bios_so,
+assign bios_ce_ = spi_bios_ce_,
+assign bios_sck = spi_bios_sck,
+spi_controller xp10SpiBIOS (
+ clock(clock),
+ reset_(reset_),
+
+ busy (spi_bios_busy),
+ addr (spi_bios_address),
+ write_data(spi_bios_data),
+ write_bytes(spi_bios_be),
+ read_data(spi_bios_data),
+ read_out_valid(spi_bios_valid),
+ do_read( spi_bios_do_read && spi_bios_data_valid ), // Is this correct ?
+ do_write( !spi_bios_do_read && spi_bios_data_valid), // Start a write
+
+ // SPI interface
+ SI(spi_bios_si),
+ SO(spi_bios_so),
+ CE_(spi_bios_ce_),
+ SCK(spi_bios_sck),
+
+ // config
+ read_cmd( spi_bios_command), // 8-bit command code for read
+ read_dummy_byte( spi_bios_dummy), // Do I throw away 8 bits when reading?
+ write_cmd( spi_bios_command) // 8-bit command code to write byte
+
+);
+
+
+/// SPI Spartan3 -----v
+
// SPI prom controller for programming Spartan
+assign config_si = spi_prom_si,
+assign config_so = spi_prom_so,
+assign config_ce_ = spi_prom_ce_,
+assign config_sck = spi_prom_sck,
+spi_controller xp10SpiProm (
+ clock(clock),
+ reset_(reset_),
+
+ busy () , // Is the machine busy working on a read request?
+ addr (), // Read or write address of 32-bit word
+ write_data(), // Data to be written
+ write_bytes(), // Byte enables of write data
+ read_data(), // Data to be read
+ read_out_valid(), // Does data in holding buffer correspond with read addr?
+ do_read(), // Start a read
+ do_write(), // Start a write
+
+ // SPI interface
+ SI(spi_prom_si),
+ SO(spi_prom_s0),
+ CE_(spi_prom_ce_),
+ SCK(spi_prom_sck),
+
+ // config
+ read_cmd(), // 8-bit command code for read
+ read_dummy_byte(), // Do I throw away 8 bits when reading?
+ write_cmd // 8-bit command code to write byte
+
+);
+
// fpga_config logic to proram Spartan
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)