QSYS Generic Tristate Controller. Issues on Waitrequest-Signal

[SDost]

Hello,

I want to biuld an interface to a very special dual-port RAM.

I already can access it with the Generic-Tristate-Controller to read and write Data. The timing is correct.

But the RAM has a signal to pause the Controller while the other Interface is active. I thought the Waitrequest-Signal would be an easy method to implement this, but when I implement it into the Controller, all my Timings seem to get very buggy.

For example: The Read signal should be at least 500ns long. But with the Waitrequest implemented it is only 40ns long. The Turnaround-Time is also far too short.

What is going on there?

As I read in the Documentation (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_avalon_tc.pdf) The Signal should just pause the Controller, but not destroy its timing.

Am I doing anything wrong? How to achieve a Signal to pause a transfer?

[SDost]

Anyone out there?

How can I set the waitrequest Output on Generic Tristate Controller without completely messing with the Signal-Timing-Requirements?

PLEAAAAAAASEEEEEE, HEEEEEELLLP!

[Ahmed_H_Intel1]

Hi,

Are you using NIOS II processor?

what is the frequency of the generic Tri-state controller. Please help to share a screen shot of qsys settings?

Regards

[SDost]

Hello,

The FPGA is acting as a PCIe to Dual-Port-RAM bridge.

The Generic Tristate-Controller is a Avalon MM Slave and directly connected to the PCIe Hard-IP.

Connections and configurations of the QSYS-System are shown in the added pictures. The Signal-Polarities are active high because I invert the needed signals outside the QSYS-System.

The clock of the Controller is provided by PCIe-Hard-IP (pcie_core_clk) and should be 125MHz afaik.

Any more Informations required?

[SDost]

Anybody out there?

Why makes the waitrequest such a mess???

[sstrell]

I'm not sure if this is the issue, but when you enable waitrequest, that means your system is relying on manual assertion and deassertion of waitrequest back to the master (the PCIe in this case) instead of the Platform Designer system handling it automatically. As such, as soon as waitrequest is released by your RAM, it is released back at the PCIe interface, which may be why you're seeing such shorter signal durations. If you want to manually control waitrequest in this way, look at the Read Wait Time parameter to control how long after waitrequest is released that a read should actually take place. See section 3.5.3 of the Avalon spec as well: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/archives/mnl_avalon_spec-18-1.pdf

#iwork4intel

[SDost]

Finally someone who answers my question. Thank you sstrell.

But your answer is not very good for my problem.

As I understand, enabling the waitrequest-Signal in Tristate-Controller disables the "automatic communication" between PCIe-Core and Tristate-Controller and I have to handle it with my slave device (the DP-RAM).

But the DP-RAM can't control this communication. It needs specific timing to be able to do anything. But this Timing is destroyed. It's a very slow Device (ISA like bus) which can't even recognize the Signals coming from PCIe-Core and therefore isn't able to set the waitrequest properly.

Although, when I assert the waitrequest-Signal, the Tristate-Controller deasserts its Signals from bus. But I just need them to stay and pause.

I just need a Signal to pause the Tristate-Controller and not to detach it from the bus.

The second problem is that the Signal coming from my Slave is only asserted when a collision occured. Normally the Signal is not asserted and I need the Timing configured as shown in my previous post.

Is there a Signal somewhere, where I can just pause the Tristate-Controller but keep its timing if there is no such "Pause"-Signal? How could I achieve something like that without writing my own Tristate-Core?