Reply by Nicholas Kinar●December 27, 20092009-12-27
Hello Thomas--
Thank you so much for your response!
>
> Your suspection is almost right. As you already found the problem on
> the pin, I suggest to get rid of these Warnings before they bite you
> next.
Yes, this is exactly what I have done. After changing my Verilog code,
it finally passes timing analysis!
> If the timing requirement could not be achieved, you are not
> guaranteed, that your design will always work in the intended way, as
> in some situations your data will need longer to be correct than your
> clock signal allows, which means your clock will sample wrong data.
> It may be possible, that the slack is so small, that you will
> experience this only on some devices or on some temperatures, a large
> slack might affect every device on every temperature, but due to the
> nature of the path it may be undetected for longer time, until you set
> the device in the condition, when this long path is sensible.
I found that the timing analysis warnings were caused by signals
crossing between clock domains. I implemented a synchronizer with
flip-flops to safely propagate the signals. (Reference:
http://www.fpga4fun.com/CrossClockDomain.html) Now that the signals do
not explicitly cross clock domains, I have no problem with the classical
timing analysis.
>
> A typical long path in an adder through the carry. This adder will
> have no problem for pairs of input numbers that didn't stress the
> carry (e.g. 0 and n, 1+4,...). If you want to add two numbers that
> stress carry you will see that some bits have the correct value and
> other the wrong value, leading to complete strange results.
>
Yes, you are very right about this weird behavior. I was wondering why
these strange results were observed. Hopefully I will not see anything
strange now that there are no problems with timing analysis.
> bye Thomas
>
Thank you once again for your help!
Nicholas
Reply by Thomas Stanka●December 24, 20092009-12-24
On 22 Dez., 16:03, Nicholas Kinar <n.ki...@usask.ca> wrote:
> -------
> Warning: Can't achieve timing requirement Clock Setup:
> 'my_pll:pll|altpll:altpll_component|_clk0' along 166 path(s). See Report
> window for details.
>
> Warning: Can't achieve timing requirement Clock Setup: 'clk' along 95
> path(s). See Report window for details.
>
> Warning: Circuit may not operate. Detected 76 non-operational path(s)
> clocked by clock "altera_internal_jtag~TCKUTAP" with clock skew larger
> than data delay. See Compilation Report for details.
> -------
>
> I suspect that these warnings may indicate that there is a problem with
> the timing analysis.
Your suspection is almost right. As you already found the problem on
the pin, I suggest to get rid of these Warnings before they bite you
next.
If the timing requirement could not be achieved, you are not
guaranteed, that your design will always work in the intended way, as
in some situations your data will need longer to be correct than your
clock signal allows, which means your clock will sample wrong data.
It may be possible, that the slack is so small, that you will
experience this only on some devices or on some temperatures, a large
slack might affect every device on every temperature, but due to the
nature of the path it may be undetected for longer time, until you set
the device in the condition, when this long path is sensible.
A typical long path in an adder through the carry. This adder will
have no problem for pairs of input numbers that didn't stress the
carry (e.g. 0 and n, 1+4,...). If you want to add two numbers that
stress carry you will see that some bits have the correct value and
other the wrong value, leading to complete strange results.
bye Thomas
Reply by Nicholas Kinar●December 23, 20092009-12-23
> Even more bizarre is that the problem seems to take care of itself after
> the FPGA reads data from the ADCs. Apparently after the ADCs are
> triggered, MISO goes high, and then drops low again just in time for the
> data to be read from each ADC.
>
Strange but true: it appears that CS[5], which is the chip-select of the
6th ADC, was never being assigned in the Quartus II pin-planner. Oddly
enough, the pin planner showed that the pin was indeed being assigned.
Could this be a bug in the pin planner? I don't know. However, it
now appears that the problem is gone, and all of the MISO pins go high
on startup.
Nicholas
Reply by Nicholas Kinar●December 23, 20092009-12-23
>
> What is really weird is that according to SignalTap II, the MISO of the
> 6th ADC does not want to go high after startup. All of the other MISO
> outputs of the ADCs go high after startup. The signal is represented as
> MISO[5] in the Quartus II pin planner, and is an input in the associated
> Verilog code. Moreover, SignalTap II tells me that the chip select #CS
> output of the 6th ADC is high. Using Verilog code, I have attempted to
> toggle the #CS of all ADCs. Doing so causes all MISO outputs of the
> ADCs to drop low (when #CS is low), and then to go high again (when #CS
> is high). However, according to the SignalTap II logic analyzer,
> MISO[5] remains at logic low.
>
Even more bizarre is that the problem seems to take care of itself after
the FPGA reads data from the ADCs. Apparently after the ADCs are
triggered, MISO goes high, and then drops low again just in time for the
data to be read from each ADC.
Nicholas
Reply by Nicholas Kinar●December 22, 20092009-12-22
Hello--
I am working on a custom board with a Cyclone II FPGA. Attached to the
pins of the FPGA are six serial ADCs (AD7690 from Analog Devices).
Each ADC has three pins which are controlled by the FPGA: #CS, MISO,
SCLK and CNV. I am using the ADCs with the #CS-mode, 3-wire with busy
signal interface. This means that a rising edge on CNV will initiate a
conversion, and since #CS is always held high, a pull-up resistor on
MISO will allow the ADC to signal to the master when the conversion is
complete. This occurs when the ADC MISO output goes from high impedance
to low impedance, causing the MISO signal to drop logic low. A data
word is then read from the ADC by toggling the SCLK. The data word is
output on MISO in a synchronous fashion to the SCLK signal.
Strangely enough, it appears that when power is initially applied, MISO
is low, although the pull-up resistor is present. With the FPGA not
programmed, I have noticed that I can touch the #CS input with a
multimeter probe, and MISO will go high. This behavior is similar for
all of the six ADCs. Note that there is also a pull-up resistor on the
#CS input.
Using the Quartus II software, I have ensured that all un-used pins are
tri-stated on startup. To verify operation, I am using the SignalTap II
Logic Analyzer, which is bundled with the Quartus II software.
What is really weird is that according to SignalTap II, the MISO of the
6th ADC does not want to go high after startup. All of the other MISO
outputs of the ADCs go high after startup. The signal is represented as
MISO[5] in the Quartus II pin planner, and is an input in the associated
Verilog code. Moreover, SignalTap II tells me that the chip select #CS
output of the 6th ADC is high. Using Verilog code, I have attempted to
toggle the #CS of all ADCs. Doing so causes all MISO outputs of the
ADCs to drop low (when #CS is low), and then to go high again (when #CS
is high). However, according to the SignalTap II logic analyzer,
MISO[5] remains at logic low.
I have verified the connections from the FPGA to the ADCs, and all
connections seem to be good.
However, I have noticed some strange warnings in the Quartus II software:
-------
Warning: Can't achieve timing requirement Clock Setup:
'my_pll:pll|altpll:altpll_component|_clk0' along 166 path(s). See Report
window for details.
Warning: Can't achieve timing requirement Clock Setup: 'clk' along 95
path(s). See Report window for details.
Warning: Circuit may not operate. Detected 76 non-operational path(s)
clocked by clock "altera_internal_jtag~TCKUTAP" with clock skew larger
than data delay. See Compilation Report for details.
-------
I suspect that these warnings may indicate that there is a problem with
the timing analysis.
Would anyone be able to shed some light on why the MISO[5] pin would
always be at logic low?
What would explain the behavior of touching the #CS pins with the
multimeter to cause the MISO output to go high?
Nicholas