Timothy Miller wrote:
>> * 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.
Well, as soon as the client gives an instruction other than a re-fetch
from the same address, read_out_valid goes low on the next cycle. But,
you probably mean that read_out_valid must only be asserted for one
cycle after busy goes low. I think, in fact, Howard's code did that,
but out of maybe a maybe foolish eagerness to optimise, I didn't
introduce the extra reg to do that.
>> 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.
That makes sense, and read_out_valid actually comes to use in the test case:
do_read = 1;
while (busy) #20;
#20;
while (!read_out_valid) #20;
// read_data is valid here
>>
>> for otherwise, we could not register 'busy' and we'd need some extra
>> logic.
And this does not apply.
> I intentionally omitted those two commands.
I'll go in and give back some real-estate :-)
>> 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
>
That's the way to capture the audience in expectation!
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
