Timing Analysis

[airturk]

Dear Members;

 I have a question related to required timing constraints for

• sending data and clock out from the FPGA to a processor and 
• receiving data back from the processor. 

This is, in fact, for the JTAG communication between FPGA and the processor while the FPGA creates and sends the clock/data and receives data with the same clock. 

The figure below shows the 4 I/Os:

• 3 outputs sent to the processor -> Clock, Data Out and Control (each 1 bit)
• 1 Input is received from the processor -> Data In (1 bit)

CLK is internally generated by dividing incoming clock (input to the FPGA, SYS_CLK) using combinational logic.

SYS_CLK -> PLL -> combinational logic -> CLK

As an additional information, combinational logic divides the incoming clock with any number between 3 to 16 and sends it out as an output. 

What type of constraints are required for these to function correctly?

Any recommendation is appreciated.

Regards, 

[eteam00]

I sincerely hope you are not using purely combinatorial logic for dividing clocks.

The only timing constraint you should need is for defining the operating frequency of your internal clock.  Of course, if you don't use registers in your FPGA design, then there is no need to use timing constraints for your internal clock.

A properly designed FPGA JTAG (IEEE 1149.1 Standard Test Access Port) controller design should have very little use for timing constraints.  The biggest 1149.1 design hasard is a signal integrity issue due to poor circuit board layout of the JTAG clock.

Have you done state machine design before?

Are you familiar with IEEE1149.1 (JTAG) signal timing and protocol?

-- Bob Elkind

[airturk]

This is purely combinatorial...

But I know that there are more stable ways of doing it, mainly the methods mentioned here: http://forums.xilinx.com/t5/Timing-Analysis/Two-clock-frequencies/td-p/230867

Have you done state machine design before? 

Are you familiar with IEEE1149.1 (JTAG) signal timing and protocol?

Yes, I am, in general, familar with the JTAG Timing and protocol. And sure, with the state machine design.

The JTAG design was tested throughly and it was working without an error for a pretty long time. However, the FPGA device utilization has increased lately (~%80 slices) and I started to have some problems with the JTAG communication.

These problems are very rare when I divide the clock with 16 (low frequencies), however the number of errors increases while the divide_value decreases such as 3 (high frequencies). 

I was looking for some recommendations before going in for detailed testing/debugging. 

I am currently looking into its functionality using SP605 so I wouldn't worry about the circuit board layout (well hopefully).

Regards, 

[airturk]

I should rephrase this

"These problems are very rare when I divide the clock with 16 (low frequencies), however the number of errors increases while the divide_value decreases such as 3 (high frequencies). "

I meant its more likely to get an error when it is running at a higher frequency. It does not create an error when it is running using the slowest frequency. And this likelihood increases when the divide_value decreases.

[rcingham]

"I meant its more likely to get an error when it is running at a higher frequency."

So, run it at a frequency you prove to be reliable during temperature testing.

[ajmirg]

Hi,

This sounds like your design is not fully constrained. When you change the divide_by value, it is possible that some setup or hold time violation occur at the interface or internally.

Do you think that the data corruption occured while the FPGA receives data from the processor or the other way around?

I would suggest that you LOC down the PLL, associated BUFGs, the whole divider circuit as per the working design...and let us know if you see improved consistency.

[eteam00]

I sincerely hope you are not using purely combinatorial logic for dividing clocks.

This is purely combinatorial...

But I know that there are more stable ways of doing it, mainly the methods mentioned here: http://forums.xilinx.com/t5/Timing-Analysis/Two-clock-frequencies/td-p/230867

The divider discussed in the linked thread is not combinatorial.

-- Bob Elkind