AD1 Interface to Spartan 3E FPGA - loaded data lines?

[tomii]

Hey all,

First off, I apologize - I'm at work, now, with no access to the hardware, o-scope, etc.  So all from memory for now, until I can get some time at home....

NOTE: All development being done under Xilinx ISE 14.7 WebPack.  Target platform is an Opal Kelly XEM3005 (Xilinx Spartan 3E)

Day 1:

Wrote & sim'd Verilog to drive a PMODAD1 12b ADC.  Seemed to work as planned.

Day 2:

Tried interfacing to an Opal Kelly XEM3005 (Spartan 3E) board with 3.3V logic & power.  No joy.  Funky stuff going on.  Began troubleshooting.

Day 3: 

Wrote code for Raspberry Pi Zero W (using WiringPi) to drive the AD1.  Everything works as it should.  Data reads work as close to perfect as I can ask for.

Day 4:

Continue troubleshooting FPGA - realize my constraints file is no bueno, and is assigning FPGA pins incorrectly.  Fixed that. (So, reasonably sure that constraints file is copacetic)

Day 5:

Wrote code to drive a PMOD DA2 2-channel 12b DAC.  Code Sim'd.  Works well.  Integrated into FPGA - code works well, DA2 works as advertised.  Also works well with OK's FrontPanel - I can give a command from the PC, and the DA2 spits out the appropriate voltage.

(This was another step to validate FPGA platform functionality & correctness).

Day 6:

Re-code and re-sim DA1 Verilog.  Works as expected.

Day 7:

Integrate code onto XEM3005 - still no joy.

Probe with oscilloscope:

Power good - 3.3V, rock solid

Ground good: little to no noise.

Chip Select (CS) looks good - ~990kHz rate, normally high, Goes low for readout periods.  Less than perfect due to being on a protoboard connected via a 6: cable.

Serial clock (SCK) looks good - ~16MHz, only active during CS Low periods, high when CS is high (quiet time)

DO and D1 outputs - constant low.  A fair amount of digital noise.  Sometimes, having a probe attached to D0 or D1 with the other probe attached to SCK or CS will couple noise in to the FPGA, giving me a noisy signal that is meaningless (except for the fact that it tells me my inputs are working - or so I think)

It appears as though (bare with me - I'm an analog guy) the lines are heavily loaded - i.e., something is pulling the lines to ground.  I see on the AD1 datasheet that the outputs are protected by 100 Ohm resistors, so this seems a potential (likely?) culprit (?)

Not instantiating IOB's in my code, but those normally aren't necessary except to override defaults in the constraints file.

Double- and triple-checked that the D0 and D1 ports are set up as inputs.

Constraints file does not explicitly turn on Pull-ups or pull-downs. (LOGIC_3v3, IIRC)

Recoded main fixture to move connections to different pins.  No change in results - everything (appears) identical.

 

Day 8:

Just got home - did some double checking and disconnected the PMOD outputs from the FPGA:

With the FPGA disconnected, the signals look pretty darned good:

Took some quick measurements of the FPGA input pins - they seem to hava a constant ~0.75V on them with quite a bit of digital trash...

This is clearly (I think) an FPGA setup problem..

So, here I am...  Looking for clues.  Anyone have any?

Thanks in advance

 

[artvvb]

Hi @tomii

The schematics of the Pmod AD1 are available through the Digilent Wiki, in the sidebar of the linked page, and may be helpful. The protection resistors are in series with schmitt triggers.

I'd recommend double checking that the timing requirements of the AD7476 (page 8 of its datasheet) are being met. I suppose it's possible that if your nCS line is peaking at ~2.5V (I may be reading the scope diagram wrong), it might not be spending enough time high (not meeting the t1 spec).

I also count 15 falling edges in the CS/SCLK scope diagram? While this may not necessarily be an issue, check the specifications to see if there may be consequences. This may end up discarding the least significant bit.

Thanks,

Arthur

 

 

[tomii]

1 hour ago, artvvb said:

Hi @tomii

The schematics of the Pmod AD1 are available through the Digilent Wiki, in the sidebar of the linked page, and may be helpful. The protection resistors are in series with schmitt triggers.

I'd recommend double checking that the timing requirements of the AD7476 (page 8 of its datasheet) are being met. I suppose it's possible that if your nCS line is peaking at ~2.5V (I may be reading the scope diagram wrong), it might not be spending enough time high (not meeting the t1 spec).

I also count 15 falling edges in the CS/SCLK scope diagram? While this may not necessarily be an issue, check the specifications to see if there may be consequences. This may end up discarding the least significant bit.

Thanks,

Arthur

 

 

Looks like you're correct about the missing falling edge - But that's secondary for now, as I can't seem to read any data back.

- Yes, the AD1 outputs run through a schmitt triggers and a 100 Ohm resistor before landing on pins.  This is partly why they are not managing to go high, I think - it appears the FPGA might be pulling the inputs low.  And therein lies the rub - I've moved the pins around to different connectors, and end up with the same results, and it's maddening (for the moment).  

I am beginning to believe that there's configuration issue with the FPGA, and I need to figure out the overloading of the AD1 outputs before I can really move any further along (I think).

In the end this will probably be something stupidly simple that I'm overlooking (or maybe a funky ground loop).

Any ideas for Spartan3E config?

[tomii]

7 hours ago, artvvb said:

Hi @tomii

The schematics of the Pmod AD1 are available through the Digilent Wiki, in the sidebar of the linked page, and may be helpful. The protection resistors are in series with schmitt triggers.

I'd recommend double checking that the timing requirements of the AD7476 (page 8 of its datasheet) are being met. I suppose it's possible that if your nCS line is peaking at ~2.5V (I may be reading the scope diagram wrong), it might not be spending enough time high (not meeting the t1 spec).

I also count 15 falling edges in the CS/SCLK scope diagram? While this may not necessarily be an issue, check the specifications to see if there may be consequences. This may end up discarding the least significant bit.

Thanks,

Arthur

 

 

Okay, just to be sure, I've done 3 things:

1) Moved to a different set of IO pins, and forced them to LVCMOS33

2) I've slowed down CS "up" time to ensure it makes it to 3.3V

3) I've slowed the SCK to about 4MHz

4) I've verified the drive input to the DAC

All results in the same problem.

 

Yes, I realize that maybe CS is going low too late compared to SCK, but when I unload the output pins, they still do the same thing as before - they come alive and properly put out 3.3V data.  So, maybe the data is skewed by an SCK cycle, but the question still remains:

"what is causing the loading of the inputs - why are they acting like outputs?

 

[Ionut]

Hi tomii,

From your posts, it seems that the Pmod AD1 generates data correctly when its data outputs are not connected to the FPGA board.

The series 100 ohm resistors are rather small, so any FPGA input buffer with an input impedance of tens of KOhms should not decrease the signal amplitude (by creating a voltage divider with the series 100 ohm resistor) below the minimum input high level.

You could also try to enable pullup resistors on the FPGA input pins (using the | PULLUP keyword at the end of the respective NET lines in the UCF file). The pullup ressitors should not affect the voltage levels generated by the Pmod AD1:

- The logic high level should not be affected as the pullup is connected to a similar voltage (3.3V);

- The logic low level should not be affected because the pullup resistor value for Spartan 3E is at least 10 KOhms, way larger than the series 100 ohm resistor.

Then measure the values on those FPGA pins with the Pmod AD1 module disconnected from the FPGA board:

- If the measured value is close to 3.3V, you can then try to connect the Pmod AD1 module to it and see if it works.
- If the measured value is closer to 0V, it means there may be a problem with the FPGA IC or with the FPGA board. If so, as the board is manufactured by Opal Kelly, I recommend contacting them.

For more information about the PULLUP keyword, you can go to https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/cgd.pdf#page=215.

Best Regards!