On 6/5/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
I attach a new version of the SPI controller. I incorporated most of the
hints from you and Howard, except:
* I didn't introduce the state reg since I found that the state was
already
implied by the other variables. Instead I added comments to indicate
states.
Well, yeah, state is either explicit or implicit in other things.
There have been designs I've done where I had some outputs, and the
output bits were unique for each state, so I just made them the state.
* I'm not quite sure I understood your comment about busy and
read_out_valid, but read_out_valid is now asserted 10 ns after the read
data is valid. Also, note that read_out_valid is kept high until
there is
another request that will invalidate the buffer.
read_out_valid should only be asserted in response to a read command.
Some notes:
* In the test case of your orginial post, you wrote
do_read = 1;
while (busy) #20;
#20;
I assume this should be
do_read = 1;
#20;
while (busy) #20;
You might be right. I have to think about it. The protocol is a bit
weird and best expressed with synchronous logic.
If busy=0, and you want to send something (a read command), you pulse
do_read for one cycle. If busy=1, you assert do_read and hold it
until one cycle after busy goes away. Requests are transferred only
on cycles where busy=0.
for otherwise, we could not register 'busy' and we'd need some extra
logic.
* The current proposal is to use 32 bit writes to configure the device.
This does not cover read-status-register and read-ID. For the latter, I
have assumed that byte-enables are also available for reads, so that we
can use 4'b0001 for read-status-register and 4'b0011 for read-ID.
Otherwise, maybe we could feed the MSB of the 32 bit address to enable
any configuration.
I intentionally omitted those two commands. I think we don't need
them. The thing is that we need to have the prom working to get BIOS
code before we can have any code that would run to check the status.
Thus, we need to hard-code at least the read command, and that, of
course, depends on the speed and type of prom. For a TRV ASIC, we'll
have to have that specified by external jumpers, I guess.
The configuration is not well-tested. Maybe someone else on this list wants
to complete the PROM simulator? That way it's more likely to catch errors
due misreading of the SPI specs.
Yes, we need to do this. I think it's great that
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
