--- Quote Start ---
Dear Sir, When should we assert these signals.
1.read---> if "read=1" , generally what should happen,it reads read address . am i right?
2.write---> if "write=1"writes into some write address.
but i have a doubt in these following control signals:
1.readwaittime
2.readdatavalid
3.waitrequest
please tell something about these three signals correctly.what should happen ,when we assert which signals.
thanks in advance.
--- Quote End ---
It appears that your understanding of read, write and address are correct, but let me re-state just in case:
- Read is an output of a master that indicates that it wants to read from 'address'. 'Read' is an input to a slave.
- Write is also an ouput, but indicates that the master wants to write to 'address'. 'Write is an input to a slave.
For waitrequest, imagine you have the case where the slave for some reason cannot immediately respond to a read or a write. Maybe it takes a fixed number of clock cycles, or maybe it varies. Now ask yourself, how does the master know that the slave cannot respond on that clock cycle? The answer is provided by the waitrequest signal which is (optionally) an output of a slave and a required input to a master. Inside the master, a 'write' completes when the 'write' output is '1' and the 'waitrequest' input is '0'. In the situation I described, the slave should be asserting waitrequest to a '1' until the clock cycle when it finally accepts the 'read' or 'write' command. Whenever waitrequest is '1', the master must not change the state of 'read', 'write', 'address' or 'writedata'.
The signal 'readdatavalid' I'll hold back on for now and simply say that this signal is used when the master and slave are capable of queueing up read commands and providing the data later but still allowing commands to be issued on each clock cycle (unlike when waitrequest is set to 1). Since you're just starting on Avalon and you're designing your own interface, my guess is that you can likely get away without the need for 'readdatavalid' at this time. Get the basics of 'read', 'write' and 'waitrequest' down first.
readwaittime is not a signal, but it is a property. The definition per the Avalon spec is:
for interfaces that don’t use the waitrequest signal, readwaittime indicates the number of cycles or nanoseconds before the slave accepts a read command. What this means is that let's say you design some widget and you can read from that widget on some interface. But you can't accept new read commands on every clock cycle. Per the earlier discussion, this would mean that the slave should assert waitrequest until it actually can provide the data. SOPC Builder/Qsys allows an Avalon slave device designer to be lazy, not provide any explicit waitrequest output but just tell it (via the readwaittime property) how many clock cycles to wait for data to be valid. Then when SOPC Builder/Qsys generates the logic for the interconnect it will generate the counter to keep track and send a waitrequest signal to the master for 'readwaittime' clock cycles, even though the slave didn't even have a 'waitrequest' output. Like I said, it's for the lazy guy who doesn't want to specify in their own code the correct behavior. It also means that such a slave device is only useful with SOPC Builder/Qsys since the slave device designer is counting on someone else (i.e. SOPC/Qsys) to generate the wait clock logic.
Kevin Jennings
Honored Contributor
