--- 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
Honored Contributor
