On 6/6/06, Timothy Miller <[EMAIL PROTECTED]> wrote:
My first reaction to your code was that it was overly complex, but that's because you actually implement the whole thing! Petter's design, which was done according to my suggestions, is much smaller. In the end, we may not need something quite so thorough, but this makes for an excellent reference design.
True, I did try to handle all commands. I wrote up 'read' and 'write' first then realized it simple enough to modify the design to accommodate the rest. [snip]
One thing to note is that different SPI controllers use different command numbers. That's one of the reasons that I made the obscure commands require that the software supply the command code. Because of the fact that there are different read codes (two for this chip, even), plus that delay period for the high-speed one, but unfortunately, we need reads working on power-up, for the ASIC, we'll have to supply that info on external jumpers. The write command can be provided in a config register. The rest can be the way I had originally suggested, where the command is supplied by software.
Now I think I understand where you're coming from. I figured you wanted a controller for the SST25LF020A / SST25LF040A but you're thinking more generically. So that the flash chip could be swapped with another without requiring the group to write new verilog code. Instead, we'd write a new software driver. Am I correct? In that case, then I would favor Petter's code as well. [more snipping]
Well, if we can get your design completely debugged, it'll be a great design for those who want to use the full capabilities of the SPI PROM. Well, I haven't ruled it out. Petter's design is to my spec, so I'm naturally biased in its favor. But I'm open-minded. Besides, we need to develop a library of modules with explanations, etc. for educational purposes. OGD1 can make a market for itself by teaching people how to design chips! In that case, someone is bound to want to use your design, even if we don't in OGA.
It's gone through a second iteration of coding for the controller and
glue. I put them through the Petter's testbench and I get the same
results, so as far as I can tell, it can operate as a drop in
replacement. Synthesis-wise, I have not yet been able to try it. My
laptop's 5GB harddrive doesn't cut it for ISPLever. The code should
work without many modifications, but that's just a guess.
Additionally, the prom simulator is more fleshed out. [Which helped
debug the controller] Everything but block protection is coded. I
haven't tested the segment and block erase thoroughly enough to call
it good, but it's in there and works for my small test case.
Something to note about the simulator. write protection is in there,
but I compile it out for Petter's testbench so the tb will get the
expected results. The simulator's more exotic commands like chip id
and status register write were tested out using my own testbench and
controller.
I do have a few questions about the expected operation of the controller:
busy: Should this only be asserted during read operations and not writes?
byte_enables: It's ignored in a read operation for the low two bits of
the address, correct?
I am unclear on the expected behavior when byte_enable is 1111. When
it's not, I have do_write imply byte program and do_read imply read.
Otherwise, the command in the read_cmd and write_cmd are used.
However, up above you mentioned you expect the default commands for
read and write to be programmable. Does that mean using
read_cmd/write_cmd or a different register?
This is how I interpreted the mailing list's conversation on it so far
[with hard coded defaults]
always @(read_cmd or do_read or write_cmd or do_write or byte_enables) begin
// Check whether command is implied by do_write/do_read
if (byte_enables == 'hf) begin
// command is special
command = (read_cmd & {8{do_read}}) |
(write_cmd & {8{do_write}});
end else begin
if (do_read) begin
command = 'h03; // Do_read implies PROM_READ
end else if (do_write) begin
command = 'h02; // Do_write implies PROM_BYTE_PRGM
end else begin
command = 'h00; // No command present
end
end
end
Something I wanted to bring up about the PROM is that byte_program
resets the write enable latch after it completes. So to program with
it would require alternating write enables with byte programs. AAI
mode, if we can support it, is the only writing operation which
doesn't reset the write enable latch when it finished. (The erase
operations also reset the latch)
We'll also have to keep in mind while writing the driver that an erase
must be called first before writing because the memory must be in the
cleared state of 0xff for a write to be successful.
Attached are my own files and a modified spi_test.v to hook in the
prom sim and controller. There are two make targets. 'test' runs the
spi_test 'prom_test' runs through the simulator testing
-Ryan
spi_prom_alt-0.1.tar.gz
Description: GNU Zip compressed 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)
