waitrequest signal for Avalon MM Slave

[Altera_Forum]

I have created a custom Avalon MM Slave component with SOPC v10.1 which uses chipselect_n, read_n, write_n, address/data, and waitrequest. Long story short I need it to be variable wait states so that's why I need the waitrequest signal. In my first implementation my slave logic asserts waitrequest asynchronously when selected (based on chipselect_n) and then de-asserts when my Slave has the data ready. But in signal tap I see the chip select from the master never deasserts and the R/W hangs (using FS2 console the indication is that the CPU is hung). so my question is how can I assert waitrequest asynchronously (as the avalon spec shows) and then deassert it synchronously based on my logic? I had written this very simple snippet that does not work because when "my_logic_done" goes high...chipselect is still low and so the async preset takes priority. any way around this? the big issue is that the Avalon spec shows the waitrequest immediately (async) with read/write/chipselect. 

 process (rst_n, chipselect_n, clk) begin if (rst_n = '0') then waitrequest = '0'; elsif (chipselect_n = '0') then waitrequest = '1'; elsif rising_edge (clk) then  if (my_logic_done = '1') then --this is a single clock-wide pulse  waitrequest = '0';  end if; end if; end process;   any ideas??

[Altera_Forum]

--- Quote Start ---  In my first implementation my slave logic asserts waitrequest asynchronously when selected (based on chipselect_n) and then de-asserts when my Slave has the data ready.   --- Quote End ---  That is generally never a good idea.  If your device can accept one transaction on the first clock, then just register the waitrequest output based on being selected.    --- Quote Start ---   But in signal tap I see the chip select from the master never deasserts and the R/W hangs (using FS2 console the indication is that the CPU is hung).    --- Quote End ---  You should create an SOPC System with an Avalon-MM BFM and your component and debug it there.    --- Quote Start ---   so my question is how can I assert waitrequest asynchronously (as the avalon spec shows) and then deassert it synchronously based on my logic?    --- Quote End ---  I am sure you can. However, you should not. Timing analysis, and meeting timing, is much simpler to achieve if you implement your slaves in one of two ways;  1) The slave is always ready (waitrequest low), and if it needs to, it asserts waitrequest after accepting the first command, and leaves it asserted until its ready for the next command, or  2) The slave is always not ready (waitrequest high), and when it is selected, it deasserts waitrequest for a clock to accept the transaction, and then it processes it.    --- Quote Start ---   if (rst_n = '0') then waitrequest = '0';   --- Quote End ---  A device that has a waitrequest signal should leave it asserted until after reset deasserts ... this is either in the spec, or its a warning that the Avalon-MM monitor generates ... I forget which.    --- Quote Start ---   any ideas??  --- Quote End ---  Simulate in Modelsim. Use a statemachine to detect chipselect, and manipulate waitrequest, and to check when your logic is done.  If you don't know how to do any of this, ask, and I'll post an example.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   If you don't know how to do any of this, ask, and I'll post an example.   --- Quote End ---    Actually, this one I wrote should work for you:  http://www.alteraforum.com/forum/showthread.php?t=26957  Cheers, Dave

[Altera_Forum]

Dave, 

 Thanks very much for the prompt and detailed response.   I do have a full behavioral simulation that works but I obviously must not be representing the Master correctly. I do need to use the proper BFM but I still don't understand a couple things:   1. How many clocks does my slave have to assert waitrequest after chip select is asserted? I believe in looking at Figure 3-3 it is implying 0 (asynchronous) but if it can be synchronous I can edge detect the chip select signal and always assert waitrequest based on that edge detect - and then clear waitrequest when my Slave is done and ready for another transfer. However, if I edge detect chipselect and set waitrequest synchronously the processor needs at LEAST a second clock cycle to detect my slave's waitrequest.   2. How many clocks does waitrequest have to be deasserted to complete the transfer? For instance if I have asserted waitrequest for 100 clocks, and then deassert it for one clock - will the processor deassert chipselect the next cycle? (Figure 3-3 shows this but in Signal Tap this is what never happened)...???   I was trying to make my waitrequest signal look exactly as it does in Figure 3-3, which is impossible without an asynchronous preset. And even when I made the signal look just as it does in Figure 3-3 (verified in Signal Tap) - it would hang the CPU once I tried to access that Slave.   do you have any example code for the actual synthesizable slave using waitrequest?   John

[Altera_Forum]

--- Quote Start ---   I do have a full behavioral simulation that works but I obviously must not be representing the Master correctly. I do need to use the proper BFM but I still don't understand a couple things:    --- Quote End ---    What language? VHDL or Verilog?    --- Quote Start ---   1. How many clocks does my slave have to assert waitrequest after chip select is asserted? I believe in looking at Figure 3-3 it is implying 0 (asynchronous) but if it can be synchronous I can edge detect the chip select signal and always assert waitrequest based on that edge detect - and then clear waitrequest when my Slave is done and ready for another transfer. However, if I edge detect chipselect and set waitrequest synchronously the processor needs at LEAST a second clock cycle to detect my slave's waitrequest.    --- Quote End ---     Figure 3-3 shows a combinatorial version of waitrequest, not an asynchronous. As I commented in the earlier post - this is a bad idea. There is no need for it. The same figure could have been drawn with waitrequest high until the slave was ready.   My general rule is; if its a slow device, eg. SRAM, then waitrequest starts out high, and deasserts after the FSM detects being selected, whereas from something like on-chip SRAM or registers, the waitrequest is there so that it can assert high during reset, but it is otherwise low. I always design synchronous interfaces to the Avalon bus, and I never use any of the tri-state components. This allows the components to be self-contained, i.e., none of the 'magic' of the component is implemented in the fabric.    --- Quote Start ---   2. How many clocks does waitrequest have to be deasserted to complete the transfer?   --- Quote End ---   Each deassertion of waitrequest indicates acceptance of a transaction.    --- Quote Start ---   For instance if I have asserted waitrequest for 100 clocks, and then deassert it for one clock - will the processor deassert chipselect the next cycle? (Figure 3-3 shows this but in Signal Tap this is what never happened)...???    --- Quote End ---    It should. But if you run this component in Modelsim with the verification suite, you will get warnings about the device timing out. So ultimately it depends on how your master will deal with a slow target. Generally you'd want to change the interface to a control/status and data register, i.e., write to the control register, then poll status until done (or use an interrupt), and then read the data register.    --- Quote Start ---   I was trying to make my waitrequest signal look exactly as it does in Figure 3-3, which is impossible without an asynchronous preset. And even when I made the signal look just as it does in Figure 3-3 (verified in Signal Tap) - it would hang the CPU once I tried to access that Slave.    --- Quote End ---    The Avalon bus has a lot of implementation options. Although Figure 3-3 represents a valid implementation, its a bad one.    --- Quote Start ---    do you have any example code for the actual synthesizable slave using waitrequest?    --- Quote End ---    Yes, I have several in VHDL.   However, unless you have the full edition of Modelsim, you cannot simulate with the Avalon-MM BFM and bus monitors, etc.   What type of example would you like to see? A device with a fixed latency, eg. a character LCD controller or SRAM? A device with a variable latency?  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   but in Signal Tap this is what never happened)...???    --- Quote End ---  Where are you probing the bus with signaltap; at the master or at the slave?  Because the Avalon fabric exists between the two, the signals you see will not be identical. This is where simulating in Modelsim can help, as you can look at all the signals much more easily.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   The software team has existing software drivers that were written for a 68000 processor to make transfers as a memory mapped function using synchronous E clk accesses at 1 or 2 MHz (to other very slow PCBs on the backplane). We are replacing the 68000 board with the Nios running way faster and we can not touch the existing drivers. Eventually we will replace the interface with a "Command Queue" using control/status and interrupts. I actually already have this done and working in hardware but the software can not be modified yet for this interface type...alas the reason I need the memory mapped accesses with variable wait states for now.    --- Quote End ---  Thanks for the details. There's nothing wrong with this approach.    --- Quote Start ---   That all being said, I need to have the Nios access these "slow slave PCBs" as a memory mapped function so the software would be compatible. To make matters worse - depending on the PCB (address) the wait states are variable. I have the logic that performs the off-PCB bus transactions fully working and (tested with the Queue version) and when the transaction is done I have a single clock-wide strobe as an indication. I am positive this works 100% with various PCBs in the rack. The interface to the processor using the waitrequest is the issue and as you are suggesting I need to get a precise BFM in there to find out what is happening.   --- Quote End ---  That should be fairly easy - you did not answer my question; Verilog or VHDL?    --- Quote Start ---   I am in a very tight time crunch however, and was hoping I could find something blatently incorrect in Signal Tap...which is where I'm at now - it would seem the master is not doing something correctly.    --- Quote End ---  What is the master in this example? A NIOS processor? Have you tried other masters, eg. I use the JTAG-to-Avalon-MM master for debugging.    --- Quote Start ---   I have tried pretty much everything you are suggesting and no luck so far. Can you please see the attached Signal Tap acquisition (taken at Slave side) and tell me why the Master doesn't deassert CS_n?? my peripheral asserts waitrequest as a combinational function and deasserts one clock later (just as a test...this is not the real timing to the off-PCB slow target) - yet the CS_n stays low forever??    --- Quote End ---  Sorry, I can't really tell anything from traces. Have you created a Modelsim testbench for the design? If you don't know how to, send me the code, and I can try to create one for you.      --- Quote Start ---   ... Okay I just verified in SignalTap that the write occurs perfectly fine with CS_n deasserting when expected by the master. However, during a read transfer, the master never deasserts CS_n after my waitrequest clears. why would this have different behavior from Write to Read? If I'm not using readdatavalid - it should stall until the waitrequest clears - no?  --- Quote End ---  The handshake depends on how you have told the system the slave responds, and that is some of the 'magic' hidden in the _hw.tcl file. Have you checked the settings in there?  I think the only way you will resolve this is if you can simulate the system. I'm pretty sure you will get the same lock-up there, but you might get some useful warning messages from the Altera IP.  Cheers, Dave

[Altera_Forum]

Dave, 

 The Slave is written in VHDL.      --- Quote Start ---    What is the master in this example? A NIOS processor? Have you tried other masters, eg. I use the JTAG-to-Avalon-MM master for debugging.   --- Quote End ---     The master is the Nios processor and the Nios is accessed via either running C code: my_reg = IORD_8DIRECT (MYCUSTOM_MM_INTERFACE_BASE, 0x800); I'm not familiar with the other method of using a JTAG-to-Avalon-MM master for debugging - does this mean no CPU at all?      --- Quote Start ---   Sorry, I can't really tell anything from traces. Have you created a Modelsim testbench for the design? If you don't know how to, send me the code, and I can try to create one for you.     --- Quote End ---   I think of the trace signals as being the "real thing" and the simulation as being...just that...a simulation. While I'm not saying by any means the sim is not useful - my sim works fine and yet the target has this strange behavior. In my simulation of the master I deassert chip select on the rising clock edge after waitrequest is deasserted - and that just plain works.   Yes I have a test bech for the design, I have many of them for this whole FPGA. The trace shows the "real" waitrequest signal and the "real" chipselect signal and if we forget everything else and not even connect the address/data ports - why would the CPU stall forever if waitrequest goes low, as it does? Is there ANY situation where the Master will hold chip select asserted after my slave has deasserted waitrequest? It really seems like a bug or something to me becuase it's trivial. I even tried stretching the waitrequest signal (low time) by 2 more clocks. If the "max pending read transactions is set to 0 and I use waitrequest and no readdatavalid - shouldn't the master always release chipselect on the next clock edge after the Slave deasserts waitrequest?     --- Quote Start ---  The handshake depends on how you have told the system the slave responds, and that is some of the 'magic' hidden in the _hw.tcl file. Have you checked the settings in there?  --- Quote End ---    --- Quote Start ---     --- Quote End ---   There's not much magic as far as I can see - it simply has all the settings that I see in the GUI Component editor.     --- Quote Start ---  I think the only way you will resolve this is if you can simulate the system. I'm pretty sure you will get the same lock-up there, but you might get some useful warning messages from the Altera IP.  --- Quote End ---    --- Quote Start ---     --- Quote End ---   I have a simulation and it works fine becuase my representation of the master in behavioral simulation works just as the avalon bus spec says it should...but that is, and must be, different than the actual - which is where I'd be lost without SignalTap.    I did try inserting the BFM (never used it before and I don't know Verilog or system Verilog) but I was finding the documentation on how to make use of it - very poor. The documentation talks about re-compiling an example design, rather than how to make a testbench for the BFM from scratch. I admittedly have no clue what I'm doing with the BFM and reading the doc didn't help much other than how to instantiate it in SOPC builder.  

[Altera_Forum]

--- Quote Start ---   The Slave is written in VHDL.     --- Quote End ---  Do you have a full-edition of Modelsim, i.e., can you run mixed-language simulations?    --- Quote Start ---   The master is the Nios processor and the Nios is accessed via either running C code: my_reg = IORD_8DIRECT (MYCUSTOM_MM_INTERFACE_BASE, 0x800);   --- Quote End ---  Does your simulation perform this same action using a NIOS processor?    --- Quote Start ---   I'm not familiar with the other method of using a JTAG-to-Avalon-MM master for debugging - does this mean no CPU at all?     --- Quote End ---  Its another master. I use it without a CPU, but in your case, you could add it to the SOPC system and use it in addition to the CPU.    --- Quote Start ---    I think of the trace signals as being the "real thing" and the simulation as being...just that...a simulation.   --- Quote End ---  In the case that you simulate exactly what you implement in hardware, the two will match.  Its not clear from our discussion that your simulation and hardware are identical. So lets establish that first.    --- Quote Start ---   While I'm not saying by any means the sim is not useful - my sim works fine and yet the target has this strange behavior. In my simulation of the master I deassert chip select on the rising clock edge after waitrequest is deasserted - and that just plain works.   --- Quote End ---  But why in your simulation do you have your own master. Why not simulate with the NIOS processor in the design?      --- Quote Start ---   why would the CPU stall forever if waitrequest goes low, as it does?    --- Quote End ---  I agree, its a strange problem, and the first thing I would do would be to put the same design into the simulator and try and understand if there is a difference between simulation and 'real' hardware.    --- Quote Start ---   I did try inserting the BFM (never used it before and I don't know Verilog or system Verilog) but I was finding the documentation on how to make use of it - very poor.   --- Quote End ---   Yes, I agree, the documentation is not very good. Especially for simulation of VHDL designs, its downright painful ... That is why I am offering to give you an example. But you need to let me know if you can implement mixed-mode language simulation ...  Just to be clear; I'm not telling you that what you are trying to do is wrong, I'm just trying commenting on how I would attack this problem. My recommendation - simulate exactly what is in the hardware, including the NIOS II processor, or use an independently created BFM master, that way you don't have your own incorrect assumptions (or incorrect Altera documentation) folded into both your master and your slave.  Cheers, Dave   

[Altera_Forum]

Dave, 

 I am running Modesim PE 6.1e but I'm not sure if it supports mixed-language. I have a feeling that it doesn't if my memory serves me correctly.   I am posititive of 2 things :-P 1. My simulated master (which is a couple VHDL procedures to support RD/WR is not representative of the actual hardware. 2. The actual hardware does not work the way the Altera documentation is describing it.   I would like to simulate with the processor as part of the simulation but I have to figure out how to do that and I'm really in a bind time-wise. So for now I went to fixed wait states that equate to the slowest PCB in order to get something to the software team that works. After that I can have more time to look into simulating. I got it almost completely working with fixed but the issue now is that when the processor is executing the ldbio and stbio assembly instructions to my 8-bit Avalon Slave - it is actually performing 4 reads of 8-bits...which doesn't surprise me at the same time I'm thinking what if I had to have the processor capable of reading a single byte and no others (maybe other addresses are registers that have status that clears upon a read or something)? The write indeed performs a single access but the read (a single ldbio assy instruction) performs 4 byte access.   Could you point me to some documentation to get me simulating running the processor as part of the sim? Furthermore, how to I get it running my C-code in the simulation?   Thanks a lot for all your time and help

[Altera_Forum]

--- Quote Start ---   I am running Modesim PE 6.1e but I'm not sure if it supports mixed-language. I have a feeling that it doesn't if my memory serves me correctly.    --- Quote End ---  Ok, that makes it difficult to test your VHDL with Altera's SystemVerilog verification IP.    --- Quote Start ---   I am posititive of 2 things :-P 1. My simulated master (which is a couple VHDL procedures to support RD/WR is not representative of the actual hardware. 2. The actual hardware does not work the way the Altera documentation is describing it.    --- Quote End ---  Exactly. This is why you need to use a BFM from Altera (assuming of course they can write to their own specification!)    --- Quote Start ---   I would like to simulate with the processor as part of the simulation but I have to figure out how to do that and I'm really in a bind time-wise. So for now I went to fixed wait states that equate to the slowest PCB in order to get something to the software team that works. After that I can have more time to look into simulating. I got it almost completely working with fixed but the issue now is that when the processor is executing the ldbio and stbio assembly instructions to my 8-bit Avalon Slave - it is actually performing 4 reads of 8-bits...which doesn't surprise me at the same time I'm thinking what if I had to have the processor capable of reading a single byte and no others (maybe other addresses are registers that have status that clears upon a read or something)? The write indeed performs a single access but the read (a single ldbio assy instruction) performs 4 byte access.    --- Quote End ---  The mapping of instructions to bus activity is where using the simulation would be useful. This type of observation also indicates the types of tests you should include in a BFM simulation of your slave interface. That way you can add testcases that reflect actual use of the interface.  If you want to restrict your bus accesses to very specific operations, eg., all accesses are 32-bit reads/writes, then you would need to write a device driver that implemented that restriction.    --- Quote Start ---   Could you point me to some documentation to get me simulating running the processor as part of the sim? Furthermore, how to I get it running my C-code in the simulation?    --- Quote End ---  I do not use the NIOS processor, so have not had to simulate it. There is an application note from Altera on the subject:  http://www.altera.com/literature/an/an351.pdf  However, what you really want to begin with is a testbench that verifies your slave adheres to the Avalon specification, via the use of the Verification IP, and then once you are convinced it does, then simulate with the NIOS II processor. The caveat here will be, what if the NIOS processor is also only available in Verilog format ...  Cheers, Dave

[Altera_Forum]

The nios cpu always asserts all 4 byte enables during read cycles - it discards the unwanted bytes internally. For writes is only asserts the required byte enables. 

This means that the bus width adapter inserted before an 8-bit slave will always generate 4 read cycles. (For writes, it might generate the cycles with no byte enables!) The usual way around this is to make the device be a 32bit slave that ignores the high bits.