Avalon bus timing question

[Altera_Forum]

I'm trying to understand exactly when the chip select and read/write lines on the Avalon bus change. For a standard write transfer the timing shows the chip select coming high after the address and data and the write lines are set up. The chip select goes low after the transfer is complete. However, the manual states that the chip select line shouldn't be used as a trigger and the rising edge of the clock should be used instead. 

 So far so good but I'm using flow control and wait states for my interface (FTDI 245BM) since I have to monitor the status lines on the external chip and can't assume that each read/write finishes in one cycle.  My question: can I rely on the chip select line becoming inactive or the read/write strobes changing when I use the readyfordata signal to hold off the transfers? Otherwise I don't really know when I should start the next transfer.  The current design uses chip select as a trigger but works only when the clock frequency and wait states are set up just right. I'd like to make things a little cleaner but can't figure out how I can know when the next transfer should start. Can I rely on the chip select or read/write signals to change before the next cycle starts? This device does both reading and writing to a constant address so I'm really only worried about figuring out when the transfers start and stop, not so much about when to latch address and data.  Thanks, Andrew

[Altera_Forum]

If you use the waitrequest signal, you can stall the bus altogether and you decide when the transfers occur. Is this the functionality you are looking for?

[Altera_Forum]

--- Quote Start ---  originally posted by jdhar@Mar 9 2006, 05:15 PM if you use the waitrequest signal, you can stall the bus altogether and you decide when the transfers occur. is this the functionality you are looking for? <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13269)  --- quote end ---    --- Quote End ---    Yes, that&#39;s probably what I should be doing. I looked through all the different options of Avalon cycles and the variable wait state is probably the best fit. Right now I&#39;m using setup,wait and hold with fixed amounts but waitrequest would be cleaner.  I&#39;m still a little unclear about when the strobes and chip select change. In the documentation for the transfers with flow control the control signals may just stay in one state and back-to-back transfers occur on the rising clk. Since my peripheral is so slow there can&#39;t be any back-to-back transfers and I&#39;m wondering if the control signals are guaranteed to change state in that case.  Andrew

[Altera_Forum]

Use variable wait states, and don&#39;t use CS, it&#39;s redundant for a simple peripheral. Simply assert waitrequest IMMEDIATELY upon seeing either READ or WRITE being asserted, and then take your time, deassert waitrequest and the next cycle everything will be over. While you have waitrequest asserted, READ or WRITE should be asserted as well; this proves that the avalon bus is holding off for you.

[Altera_Forum]

That sounds easy, I just looked at the timing diagram in the avalon manual and it&#39;s pretty clear except for what happens after the transfer terminates (at point J, in the figures). 

 Since the read/write strobes are still active at the rising edge that terminates the transfer, how will I know whether the bus is requesting another cycle right away or not?

[Altera_Forum]

Hi queisser, 

 > Simply assert waitrequest IMMEDIATELY upon seeing either READ or WRITE > being asserted,  In some designs, I&#39;ve found it convenient to leave waitrequest asserted, then negate the signal once everything is ready -- asserting again immediately after the clock edge that completes the cycle.  > how will I know whether the bus is requesting another cycle right away or not?  You will know on the next rising edge. The cycle is completed on the rising edge where waitrequest is negated.  Regards, --Scott

[Altera_Forum]

--- Quote Start ---  originally posted by smcnutt@Mar 11 2006, 08:25 AM you will know on the next rising edge. the cycle is completed on the rising edge where waitrequest is negated.  regards, --scott <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13338)  --- quote end ---    --- Quote End ---    Ahh, so the rising edge where waitrequest is negated completes the cycle and the rising edge after that starts the next cycle?

[Altera_Forum]

Hi queisser, 

 > and the rising edge after that starts the next cycle?  That depends on the state of the control signals ... and how you define "next cycle".  Basically, the rising edge where waitrequest is negated completes the current "bus cycle" (the data is latched, for example on a read). The rising edge that completes one bus cycle can be the start of the next. If read remains asserted, the _following_ rising edge can potentially complete the next cycle (if waitrequest is negated).  Regards, --Scott

[Altera_Forum]

--- Quote Start ---  originally posted by smcnutt@Mar 14 2006, 08:34 AM hi queisser,  > and the rising edge after that starts the next cycle?  that depends on the state of the control signals ... and how you define "next cycle".  basically, the rising edge where waitrequest is negated completes the current "bus cycle" (the data is latched, for example on a read). the rising edge that completes one bus cycle can be the start of the next. if read remains asserted, the _following_ rising edge can potentially complete the next cycle (if waitrequest is negated).  regards, --scott <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13413)  --- quote end ---    --- Quote End ---    Ok, thanks, that confirms what I thought. I think I&#39;m back to using flow control since I can never know when my peripheral (the FTDI USB fifo chip) will be able to produce data. I don&#39;t really want to hold off the transfer for minutes at a time with waitrequest so I think I&#39;ll use flow control instead. From the manual it appears that that&#39;s the recommended way of doing it.  Andrew

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  I don&#39;t really want to hold off the transfer for minutes at a time with waitrequest so I think I&#39;ll use flow control instead.[/b]  --- Quote End ---    As far as I can tell, there isn&#39;t any difference to the master whether you hold it with waitrequest or with dataavailable. According to the Avalon spec, a master doesn&#39;t directly receive dataavailable or dataready, it just gets blocked on waitrequest, (the same as per variable wait state).  I can see the flow control being slightly easier to implement if you already have a fixed wait state port -- but the end result will be the same to the master.  If you want to avoid having the master block for an indeterminate time on reads, you need to come up with a different mechanism.