Signal timing problem

I am having difficulty solving a timing problem using a Spartan 3 embedded platform. We are using a MicroBlaze core with some user IP modules and some Xilinx modules attached through the OPB bus. One of the IP modules is a 3-wire serial data interface. We have to be able to generate multiple protocols so this module handles all of that. The "data" line is bidirectional. It is connected correctly to a bidirectional buffer at the top level. We write data to a "part" and then can read that data back from the part. The part sends back a bit of data on the FPGA's "data_clock" rising edge. The FPGA clocks that data in on the falling edge of the "data_clock" signal. All was working fine unitl we placed an extension board on our platform. This effectively makes the external path from the "part" to the FPGA much longer. The readback does NOT work when using this board. The FPGA reads back data, but not the correct data.

There are test points on our platform that allow us to look at the

3-wire interface signals in between the part and the FPGA. These signals look fine (with respect to timing) when using the board that works and the one that doesn't. It seems that the critical delay is happening in the FPGA. It seems like the data going in to the pin is not getting to the module IP logic before the critical clock edge occurs. Is there a way to tell the Xilinx tools (via UCF constraints) to constrain that path to a certain time spec?

Another problem is that I have looked at the ngc file for the EDK-produced wrapper for my module. The correct three signals ("data_O", "data_I", and "data_T") are I/O pins on the module, but once I dive down into the mapped implementation, the "data_I" is not longer anywhere to be found! I don't know where it goes, so I can't find a net name or anything like that to constrain! What is going on there?

Thanks....

Reply to
motty
Loading thread data ...

clk __--__--__--__--__-- data ___----____----_ sample-____|___|___|___ wastes half of your setup time vs sample+__|___|___|___

-- Mike Treseler

Reply to
Mike Treseler

Mike--

Seems you are telling me to sample the data on the rising edge. This is the same clock that the external part is seeing. The external part changes data on the rising edge. I can't be sure that data is valid then. The part is spec'd to interface to a device that will sample on the falling edge. If I look at an o-scope of the data vs. clock signal, the data becomes "valid" about halfways throught the positive cycle of the the clock. It is definitely valid on the falling edge of that clock. But that is external to the FPGA. Those signals look entirely different at the logic interface in the FPGA. I need to understand what is happening from the pin to the path inside.

Reply to
motty

You can specify how early the data will arrive with respect to the active clock edge that will register it. This can be done in the UCF file using the OFFSET-IN-BEFORE constraint.

eg. NET "" OFFSET = IN ns BEFORE "" HIGH/LOW;

The static timing analyzer will calculate the clock path and data path delays and ensure that X - data_path_delay + clock_path_delay > setup_time_required. Where X is from your constraint above. If not timing for that path will fail.

As Mike said, I think you are better off using the the rising edge. Don't worry about the hold time, Xilinx devices are designed to have zero hold time.But, you will have problems if the clock delay is more than the data delay, but that is unlikely.

Kunal

Reply to
Kunal Shenoy

The external part can't change its outputs immediately with the rising edge of the clock -- there's always some clock-to-out time. RTFDS. While you're at it, add in some prop delay between the external device and the FPGA.

Capturing the "previous" data on the rising edge of the clock is basically how all synchronous systems work.

-a

Reply to
Andy Peters

Thanks guys.

But Andy, what is there to do when there is no F'in data sheet to read (in scared )? The part is a company internal ASIC on its first spin and actually that spec is not a problem right now . I KNOW that there is a delay associated with respect to when the external part presents valid data after a rising edge of the clock it sees. By the way, the clock that all my synchronous logic is being driven from is 2x the clock the external part sees. The whole state machine is rising edge driven from that clock. The clock the external device sees is generated in synchronous logic by that clock too. I use the derived clock's levels (not edges) internally to see when I need to clock data out and clock data in. Those specs (when data transitions) are different depending on which company part I am writing/reading so it HAS to be flexible. Anyways, I digress....

I can monitor the delay from rising edge of the clock the part sees to when data is valid. I am looking at it on an o-scope. No problem. All setup times are WELL within margin. The problem occurs somewhere in the FPGA. If I could sample the data at the external pins I am looking at on the o-scope, then I would read back correctly ALL of the time. The FPGA works fine when we are NOT using the extender board...the part is much closer to the FPGA. When using the extension, the read back data is incorrect. Again, it looks fine on the o-scope in BOTH cases. In a simplified delay equation of: total delay = delay from part to FPGA pin + delay from FPGA pin to internal logic module, I need to use the delay from FPGA pin to internal logic module as my variable. That is the value I need to tweak.

This is hard to make sense of in a forum without typing a document! Thanks.

Reply to
motty

For a synchronous interface to work properly without a handshake, both ends need to see the clock rising edge at exactly the same time. The only practical way to do this for more than an inch or two is use a zero-delay clock distribution chip and wire equal length transmission lines from the chip to the clock input at each end of the interface. You have to cover both the normal and extended cases somehow.

Or add a handshake. Or go source synchronous. Or tune up the clock delay using the fpga PLL.

-Mike Treseler

Reply to
Mike Treseler

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.