On 6/5/06, Ryan Osial <[EMAIL PROTECTED]> wrote:
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.
Wow. The ball had begun rolling. Thank you for helping to contribute
code on this.
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.
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').
Well, you look like you're going for the two-level sort of machine.
That was how I first implemented it, and the result was that it was
impossible to debug, at least the way I did it. I'll have to
examine yours more carefully. The fact that the last address bit and
the first read data bit are on different edges of the same clock pulse
makes it a bit tricky.
So the way I first tried it, I too made the observation that things
are done in bytes. The first benefit is that you end up with fewer
bits in your counters, so it can use a faster clock rate. In response
to my trouble debugging, I suggested to the list that we use a simpler
design with bigger counters. In this case, we're only going to run at
33MHz, so it's not a problem to use 6-bit counters instead of 3-bit
counters.
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.
Well, it looks like you're doing it right. 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.
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.
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.
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.
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.
I'm unavailable for a couple days, so I won't be able to respond but
good luck in the mean time!
Thanks for the help!
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
