GPIF Issue

[sdr_beginner]

Hi,

I have trouble with FX3_GPIF fpga outputs.
It seems that the driver strength is not sufficient, also I set it to max as described in your sdc.
Especially fx3_gpif[28] is affected.
Sometimes the FX3 captures the wrong (old) bit value; SignalTap monitoring on fpga side is okay.
There are no timing violations on this interface whith your constraints. All according output/input registers are mapped into pad cells.

It depends on temperature and occurs pretty sure when fpga temperatue is over 47°C.
This issue started probably with fx3 firmware version 1.6.0 and we see this on two boards (one of these is slightly better).

Has anyone else seen this behaviour?
Is it possible that in board layout the line length of these signals are different?


Thanks
Andreas

[sdr_beginner]

Hi,

spent some more time for further investigation:

On FPGA side everything is okay: no errors when monitoring with SignalTap.
Timing analysis shows no violation.
Problem is only gpif[28] in direction to fx3.
Sometimes when temperature is more then 47°C, this line is (external) not driven to zero in required time.
(Reason for higher temperature as in reference design is integration of multiple fft blocks.)

Ugly workaround for me: registering of this single output with falling clock edge.

Please, can someone of the nuand board layout team confirm that the routing of gpif[28] is different than the others?

Thanks.

[bpadalino]

Sorry for the late reply.

The layout is matched pretty well. If you go into Time Quest and look at the clock to out, of the GPIF feeding back to the FX3, is GPIF 28 the worst violator?

The timing constraints are probably just incorrect and need to be reassessed. If you force the timing to be more aggressive on the setup/hold, are you able to either see the timing fail or alleviate your ugly hack?

Brian

[sdr_beginner]

Hi Brian,

looked into timing report:
all gpif outputs have nearly the same slack.
Output/Input registers are located directly inside the pad cells.
Couldn't be placed better.

I had not this trouble with older fx3-version (before 1.6.0).
With this something changed on this interface.
I think you know that, because you have increased the drive strength and slew rate of the fpga gpif pads to maximum.
This was not necessary before.
I looked into fx3 code, but it's not easy to understand.

Btw.
Do you have some read/write timing diagrams of the current gpif interface?
I'm a little bit worried about the default output enable in IDLE state for gpif signals on fpga side.
I think, in older fpga version this was different.

Edit:
In my design gpif-output-data are only active driven when they are valid, otherwise the lines are set to 'Z'.
When I enable the output one cycle before valid data, there seems to be no more errors.
I will test my changes overnight.


Andreas

[bpadalino]

I don't have anything readily available for the timing diagrams, but I can try to get those to you.

Regarding your edit - what did you mean there? You are removing the tristate from the FPGA side driving the FX3 one cycle beforehand?

How did your overnight test go?

Brian

[sdr_beginner]

Hi Brian,

Overnight test was much better than before but not without errors.

You are removing the tristate from the FPGA side driving the FX3 one cycle beforehand

That's what I do. Normaly I disable the tristate ony for valid data of a continous dma transfer.
In this case sometimes the first data word (our "magic word") is corrupt (single bit failure). Probably some other words too.
When I add an additional output-enable-cycle directly before the dma-transfer, there are much less errors in the first dword.
Is it possible that fx3 is not really in tristate mode when receiving data?

Andreas

[sdr_beginner]

Sorry for my late posting.
Here is an update to my problem:

I have a timing issue for gpif-out signals!
Imho the delivered constraints for output_delay are not sufficient:

Code: Select all

set_output_delay -clock [get_clocks fx3_virtual] -max 2.0 [get_ports {fx3_gpif* fx3_ctl*}]

I think, the value must be higher.
Unfortunately, a higher output delay can not be reached with the current clock strategy (only a global clock buffer for fx3_pclk).

My solution is to insert an additional pll for fx3_pclk to compensate the delay of clock-pad and clock-buffer.
With this I have a slack of 4.3 ns for output-delay-requirement and no data errors anymore.

The question is now: how reliable is fx3_pclk, coming from fx3 chip?
It takes some clock cycles until pll is locked and I don't want to loose "pll-lock" during operation.

[bpadalino]

That is the same strategy I used in an experimental branch that worked well for me as well.

The clock is always running when the GPIF is up and running/enabled.

This means when we want to TX or RX samples, the 100MHz PCLK will always be running. That clock runs the middle LED that blinks when the device is active.

You should be good.

Let me know how it goes! Patches are always welcome - especially for constraints.

Brian