On 5/27/06, Timothy Miller <[EMAIL PROTECTED]> wrote:
The objective is to develop a controller that can read, write, and
execute other arbitrary commands. Here's what the controller
interface should look like:
module spi_controller(
clock,
reset_, // async negative reset
// Read/write interface
read_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,
SO,
CE_,
SCK,
// config
cmd_read, // 8-bit command code for read
read_dummy_byte, // Do I throw away 8 bits when reading?
cmd_write // 8-bit command code to write byte
);
input clock_1x, reset_;
output read_busy;
input [23:2] addr;
input [31:0] write_data;
input [3:0] write_bytes;
output [31:0] read_data;
output read_out_valid;
input do_read, do_write;
input SO;
output SI, CE_, SCK;
input [7:0] cmd_read, cmd_write;
input read_dummy_byte;
Tim, Petter, Howard,
After reading over the SPI PROM data sheet, I thought the interface
could be abstractd a little making things easier to code (for me). I
wrote up a glue layer between yours and mine so in practice, it should
be the same, but I had to make some assumptions which should be noted
in the code. I didn't use the PROM simulator when testing because it
wasn't complete (that's on my todo list) and I was aiming for a full
controller. Instead I waveforms up with the data sheet's figures.
Right now, my glue layer isn't perfect. I sent my code through the
project's testbench and it yielded different results on the reads. I
haven't been able to track it down yet, but one possibility is that I
use mode 3 instead of mode 0 on SCK ('1' when not used instead of
'0').
The interface was derived by looking at all the commands. The most
bits any write uses for a command is 8 bits, so write_data was cut
from 4 bytes to 1 byte. The address is the full 24 bits (I know PCI
doesn't send the lower 2, that's what I hoped to fix in the glue
layer). The controller knows all commands and how many cycles it
takes, so I replaced do_read/do_write with a start/command pair.
module spi_controller(
clock,
reset_,
// Controller Iface
busy, // Is the controller currently working on a request
start, // Execute the command
command, // 8-bit command
address, // Address associated with command
write_data, // 8-bits of data to send with the command
read_data, // Data read back by the command
read_out_valid, // Whether data in read_data is valid
// SPI Iface
SI,
SO,
CE_,
SCK,
);
The controller works of the principle that each command takes a
certain number of 1-byte cycles (8 for read, 5 for write, etc) to run.
Reading from SO should start when the cycle count reachs the number
of bytes to read. [It is set to 0 when a command does not read]
I've tested READ, FAST_READ, and BYTE_PRGM. When I get back, I hope
to finish testing out things like AAI.
Attached are the spi prom controller, a testbench for it, and the glue layer.
But if this code doesnt work for OGD, I'm not considering it time
wasted. I think freshening up on verilog (coming from a VHDL
background) should make working on the prom sim easier.
I'm unavailable for a couple days, so I won't be able to respond but
good luck in the mean time!
-Ryan
spi_prom_ctrl_glue.v
Description: Binary data
spi_prom_ctrl_alt.v
Description: Binary data
spi_prom_ctrl_tb.v
Description: Binary data
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
