ADS8568: Contradictory description of configuration register write in the data sheet (SBAS543C)

Hello Andy, we are looking into this and will get back to you.

Any response? The tech support case I created last week via e-mail was unceremoniously closed this morning because I "posted on the forum."

I really do need to know how this thing works.

Hello Andy,
Apologies for the late response.
For page 8 and page 19, they are not the same, each is explaining a liable option. You may have CS low while WR pulses, or have them both pulse together. Either option is acceptable.
As for page 34, this does seem that there is a mistake in the text. If figure 40, following this section, the timing diagram shows CS driven low during the accesses, or following WR in dotted lines. These are the correct options. I will look into this, and confirm this is a discrepancy in the text.
Regards, Cynthia

" I will look into this, and confirm this is a discrepancy in the text."

It must be, as it contradicts the other text and the figures.

Two more questions.

1. This was something that arose during our testing. Is it legal to keep the chip select CS\ tied low and never toggle it? The data sheet doesn't say you can't, and figure 36 on page 29 seems to imply that you can (dotted line showing CS\ low during CONVST and BUSY).

But with the part configured as such, the thing simply doesn't work. The first two RD\ assertions after BUSY goes away don't result in DB[] being driven and the data values for the other six are garbage. See this image. (It uses external clocking, but with internal clocking the result is the same.) The 0x7FFF is from FPGA weak pullups. CONVRT by design meets the required set-up to the first XCLK rising edge. There are 19 XCLKs, per the data sheet. 

Is there a spec on the timing of the last XCLK to the deassertion of BUSY? It would be nice to know that, mainly so I can have a complete bus-functional VHDL model of the converter. (Which leads to my standard complaint: why don't you guys have bus-functional VHDL models of your converters? How are we supposed to verify a design without one?)

This image shows how we have two converters sharing a common data bus, with independent RD\ strobes and CS\ on both tied low. CONVRT and XCLK are common to both converters. fadcard_l is the read enable for converter A and fadcbrd_l is the read enable for converter B. Notice especially how the data bus does not change from undriven until the third read strobe, and notice how the value doesn't change (which should be impossible if the converter was working) and notice how the 33F7 value remains on the bus until the third RD\ on converter B.

---

2. The picture above shows one conversion. Looks (almost) OK, right? But let's zoom out and see what happens next.

This is VERY weird. Notice how the second and fourth conversions never start -- BUSY never goes true. Alternate conversions never actually start. What is going on here? Clearly the first and third conversions complete, so what holds off the second and fourth (and sixth, and eighth, and so on)?

There is some cruft toggling on the data bus during the second and the fourth conversion, even though the read enable RD\ is off. The state machine that does the ADC read of course waits for the busy to go low before starting the data read, so both RD\ strobes are clearly deasserted. The read_wait timer ensures we meet tBUCS, which for external clocking is 0 anyway. 

The data sheet is again contradictory regarding the external conversion clock. On page 29, section 9.3.1.3, we read "The external clock can remain low between conversions." On page 31, it says "Initiate each conversion start during the high phase of the external clock." So of course you cannot start a conversion when the clock is high if you are idling it low. Furthermore, the data sheet shows in Figure 1 on Page 18 the relationship between CONVST and XCLK, and we clearly see XCLK low prior to the assertion of CONVST.

---

I must point out the following: when operating with WR\ tied permanently high and CS\ and RD\ asserted together, the converters work as expected. It was only when we modified the board to allow writing to the configuration register to allow for external clocking did this all fall apart. The reason for tying CS\ to ground permanently is simply, not enough pins going from the controller to the converters.

Hello Andy,
We are still looking into this, I understand your frustration and will get back to you.
Regards, Cynthia

One more:

On page 38 for bit 30, the READ_EN bit, we read:

1 = Configuration register contents output on SDO_A with next two accesses (READ_EN automatically resets to 0 thereafter)

Which seems to imply that the only way to read out the configuration register is by using serial access. Read of this register in parallel mode is not possible. 

Can you confirm this, please?

And please consider providing bus-functional models of these converters. It would make FPGA design and verification easier. As it is, we are guessing as to how the part works based on a crappy data sheet, and the only way to verify our design is to write our own models. And you can't write a proper model without a complete and correct description of how the part works.

Regarding the situation where I provide an external clock and it does not actually start a conversion every other time I assert the convert start. I was providing exactly 19 clocks after asserting convert start. I changed the FPGA to drive XCLK continuously (a 10 MHz clock frequency) and guess what? Every convert-start resulted in a conversion (BUSY going true).

Then I changed the design to drive 20 XCLKs per conversion, instead of the datasheet's explicitly-stated 19. And guess what? Every convert-start resulted in a conversion (BUSY going true).

Come on, did anyone bother to verify all of the functional modes of this part and verify what the data sheet says?

I'm still fighting the problem where the first two data reads after BUSY goes away doesn't result in the converter driving the data bus.

Andy,
This part has many features available which understandably makes it a very complex device.
I have been digging into this part, and found that following information.

Correct, the registers can only be changes in software mode, and read-out using serial interface.

The ADS8568 can use an external conversion clock (CCLK). In this case, you would need to run the CONVST synchronous to the CCLK and the conversion process would be completed in 19 CCLK cycles. When using the internal conversion clock, CONVST would be asynchronous so you have +/- ½ clock uncertainty on when the conversion begins, meaning 20 CCLK cycles should be used.

We have not had much interest in bus functional modules which is why we do offer them. But, seeing how they could ease the design process we will look into it.

Regards
Cynthia

"This part has many features available which understandably makes it a very complex device." 

Complexity is in the eye of the beholder. Other parts in my design are significantly more complex, yet worked without fuss. I suppose it's because the documentation is comprehensive and correct.

"Correct, the registers can only be changes in software mode, and read-out using serial interface."

The first part of that is well understood. The second part, about the readback, is not. PLEASE, update your data sheet to make it CLEAR that readback is available only in the serial-interface mode.

"The ADS8568 can use an external conversion clock (CCLK). In this case, you would need to run the CONVST synchronous to the CCLK and the conversion process would be completed in 19 CCLK cycles. When using the internal conversion clock, CONVST would be asynchronous so you have ± ½ clock uncertainty on when the conversion begins, meaning 20 CCLK cycles should be used."

That is all understood. In external-clock mode, I do indeed assert CONVST well ahead of the first rising edge of my XCLK, it absolutely meets the required set-up time of 6 ns. The conversion started and ended as indicated by BUSY in the specified 19 clocks. But what I noticed was that on alternate conversions, BUSY was never asserted. If I drove 20 XCLKs then every time after CONVST BUSY would go true.

When I tested using the internal conversion clock, I never paid attention to how many CCLKs were required. I realize that the CONVST in that case is asynchronous to CCLK and that's why I monitored the BUSY flag to signal the end of conversion.

"We have not had much interest in bus functional modules which is why we do offer them. But, seeing how they could ease the design process we will look into it."

A correct bus-functional model of any device is always welcome. How is an engineer supposed to verify an FPGA design without a proper model of the things to which the FPGA talks? I wrote one, based on the data sheet description of part functionality, but since the data sheet is awful, I don't have much confidence in the model.