Strange behavior with serial ADC chip select and MISO pin

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

> 
> 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

> 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

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

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