1. Home
  2. Field-Programmable Gate Arrays
  3. FPGA and ZBT/NoBL SRAM timing issue

FPGA and ZBT/NoBL SRAM timing issue

Greetings comp.arch.fpga group,

I am having some trouble implementing a ZBT or NoBL SRAM interface. I am using a Xilinx ML402 board but my trouble is generic in nature.

I am trying to divide the interface into four ports, each port having a particular time slice to read or write to the SRAM. In my case I am trying to do one write slice and three read slices, however, my issue happens with any write followed by a read.

The design is synchronous lets say at 50MHz to make the numbers easier. So a 20nS period.

Let's say at t=0nS the FPGA issues a write enable along with the write address.

I have a separate DCM clocking the SRAM and say for setup purpose I delay this clock by

4 ns. So at t=4nS, the SRAM has a write command and the write address.

At t=20nS, the FPGA does a read at a specified read address. This gets clocked into the SRAM at t=24ns.

At t=40ns the FPGA issues the write data, according to the staggered data delivery architecture of the ZBT or NoBL SRAMs.

At t=44 the SRAM gets another clock. Let's say it's another write enable and address, although it doesn't matter.

After Tco(time clock to output) about 3ns, or at about t=47ns, the SRAM is outputing data for the read clock at 24ns.

There's the issue. The FPGA is outputing data from t=40ns to t=60ns and the SRAM is outputting data from 47 ns to perhaps 67ns creating a collision on the bidirectional lines.

I have thought of minimizing this affect by using a clock pin that is negatively delayed by the FPGA clock, something of the order of Tco, but it doesn't seem right that I should have to split hairs like this. Isn't the point of the ZBT architecture is so you can have write and read effortlessly meshed?

Any insight will be appreciated.

Best Regards,

Brad Smallridge aivision dot com

Reply to
Brad Smallridge
Loading thread data ...

You might find some good app notes with the memory manufacturer. I recall looking at the ZBT/NoBL format and came across the same trouble. Say, isn't there a Xilinx App note, too? The first hit in the Xilinx search for ZBT referenced the 3rd hit: XAPP136.

It appears the devices are designed for limited bus contention but I don't recall values anywhere near 7 ns. The contention of the app note (I had to say it) is the total power dissipated during contention is a quickly calculated value that the designer includes in the overall power numbers. This makes sense if series impedances are part of the connection to the SRAM such as the SSTL or HSTL standards might recommend.

As long as the contention doesn't present power problems and is resolved within the setup time, the process should flow. If you can shift your clock to guarantee *just* meeting the setup time at the SRAM for writes, all the better. This gets a little complicated since you want to *just* achieve the hold time on the other side of the clock, too.

Happy reading!

- John_H

Reply to
John_H

Yes, but you made it complicated again be delaying the clock. The ZBT is designed to have a full clock cycle of setup. If anything you need to have a negative delay on the clock to avoid hold issues. But in principle the ZBT interface is design for SRAM an FPGA using the same undelayed clock.

At t=0 you cycle the clock and simultaneously change address and set the command to read. The SRAM clocks in whatever the FPGA has output before. At t=20 the the SRAM clocks in your read command, you simultaneously set the outputs of the FPGA to a write command. At t=40 the SRAM clocks in your write command and starts driven the output At t=47 the SRAM read data will be on the bus At t=60 the FPGA can latch the read data and start driving the bus, the SRAM stops driving it. Bus contention only occurs in the time difference between the FPGA clock_to_out and the SRAM clock_to_Z times.

Application note:

formatting link

Kolja Sulimma

Reply to
Kolja Sulimma

Yes. I see now. Thank you.

Reply to
Brad Smallridge

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.