On 2006-06-05, Petter Urkedal wrote:
> 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
Parethetical, just to elaborate on this:
I used 'while (busy) #20' to wait for read data to become available,
assuming the client respected timing for writes, and always waited
for reads to finish so that we were never busy on a new request.
Dropping that assumption, I could have written
do_read = 1;
while (busy) #20;
#20;
do_read = 0;
while (busy) #20;
// read_data available
OTOH, if we drop busy, as you indicated we might, I think the fetch
sequence is
do_read = 1; // assuming device is not busy
#20;
while (!read_out_valid) #20;
// read_data is valid;
which is basically the same as 'do_read = 1; #20; while (busy) #20;'.
What is the requirement for read_out_valid? You said that it should
only be asserted in respose to a read request. Does it also need to go
low a cycle later, or could it remain high until a new request is made?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
