• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 47 subscribers
  • Views 1890 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC3174: DAC3174 IOTEST PATTERN GENERATOR AND ALARM ISSUES

Chris Burton24
Prodigy 70 points
Part Number: DAC3174
Other Parts Discussed in Thread: DAC3283,

Hi,
I am having some issues with the IOtest pattern checker operating in 14bit dual DAC mode (single clock obviously).
The CONFIG4 results register seems 'stuck' at 0x3FFFF. With The SYNC PINS (pins 6 and 7) showing a LVDS logic '0' continuously between clearing
and reading, I cannot change this register to read zero. I also cannot clear the CONFIG5 alarm bits 3 and 4 as well!
I have slowed my clocks down to 62MHz, and confident with DATA_CLK and DAC_CLK clock levels and stability. I am confident that when I send the SYNC pulse,
it arrives at the device pins with correct LVDS levels and only one pulse is present.

The process I am using is as follows:

0) The Device is configured for syncrx_ena, synconly_ena, and NO sifsync_ena, running in single clock full bus, dual dac modes. Note I can get waveforms
through device and presented on output that look correct on both DACs(just want to be able to prove no timing issues on power up).
1) CONFIG1: bit15 (iotest_ena) is set to '1' to enable the test process. (does this mode stop the output?)
2) CONFIG4, write all zeros to clear iotest_results register
3) CONFIG5, write all zeros to clear alarms register
4) SEND IOTEST SEQUENCE. The sequence I am sending looks exactly like that indicated in the DAC3283 datasheet (8.4.7 "Data Pattern Checker"), Figure 34.
I reference this because there is no clear decription in the DAC3174 datasheet.
5) READ CONFIG5 and CONFIG4 to assess errors. A '1' in the associated alarm register bits3,4 to indicate a failure, with a '1' in a bit channel
of CONFIG4 to indicate which bit channel failed.

6) After this process the register dump is as follows:

CONFIG0 : 42ed
CONFIG1 : e04e
CONFIG2 : 3fff
CONFIG3 : 0000
CONFIG4 : 3fff
CONFIG5 : 0018
CONFIG6 : 2f00
CONFIG7 : ffff
CONFIG8 : 6000
CONFIG9 : 8000
CONFIG10 : f080
CONFIG11 : 1111
CONFIG12 : 3a7a
CONFIG13 : 36b6
CONFIG14 : 2aea
CONFIG15 : 0545
CONFIG16 : 0585
CONFIG17 : 0949
CONFIG18 : 1515
CONFIG19 : 3aba
CONFIG20 : 0000
CONFIG21 : ffff
CONFIG22 : 2d04
CONFIG23 : a3c4
CONFIG24 : c9a8
CONFIG25 : 87ff
CONFIG127 :  0049

Because I can never clear the alarms or results registers, I cannot tell if I have a problem or not!

I note that the DAC3283 datasheet has an interesting statement:
"It is recommended to enable the pattern checker and then run the pattern sequence for 100 or more complete cycles
 before clearing the iotest_results(7:0) and alarm_from_iotest.
 This will eliminate the possibility of false alarms generated during the setup sequence"

Is this the same/similar issue? I have tried writing the sync + pattern 101 times to the device before clearing results and alarms registers just in case,
to no avail.

CONFIG4 Table 10 Register Field Description says: "The values of these bits tell which bit in the input word failed during the io-test pattern comparison.
[13:7] match up with the 7 bits from port A and [6:0] match up with bits from port B.". This does not have any description of operation in 14bit full word interface
mode, but have assumed it works as it suggests in figure 25. Can you please confirm that IOTEST does work in this mode?

Kind Regards,
Chris Burton

  • 0
    TI__Genius 9675 points
    Chris,

    We are looking into this now.

    Jalen
  • 0
    TI__Mastermind 29220 points

    Hi,

    I have used the iotest feature on my bench.  I am attaching a ppt file that I made a while back on its usage with the EVM and the TSW1400.  it took me a while to get comfortable with its usage.  they key of course is to make sure that the data on the bus matches exactly what the device is expecting to see in the stored pattern, and at the right time as indicated by the SYNC input.   The SYNC input tells the pattern verifier that the pattern on the bus at that clock edge is the sample that should be compared against the first of the 8 stored patterns, and then the pattern match should run in lockstep from there.  On my EVM with the TSW1400 for pattern generation I had to play with whether the 14 bit sample was msb-justified or lsb-justified - but that was an issue with the way the firmware for my FPGA was created.  I had to make the stored pattern be msb-justified in order for the FPGA to get the right bits to the right inputs.    one way to debug the process is to clear the 8 stored patterns to all zero, and then make the pattern from the FPGA into the DAC also be all zero.  That has *got* to work.  there is no way to mess it up if the feature is enabled and the clocking is as expected.  Then I set a single 1 in the least significant position of the first sample in both the pattern from the FPGA and in the stored pattern, and make sure that works.  if there is an error in the least sig position, then it is either SYNC not aligned with pattern 0 or the bit position on the bus is off.   Then after getting a toe-hold established in that manner, I was able to fill out the rest of the pattern.  (I had to make a new SPI GUI at the time that would support reading the EVM SPI port as the original SPI GUI on the TI web did not support that.  in the ppt screenshots, the SPI GUI did not have the 'default' settings coded in for some of the pattern regs, but you can see that the value read back was as expected.)

    Regards,

    Richard P.

    7532.DAC3174 Pattern Test Feature.pptx

  • 0 in reply to Richard Prentice
    Prodigy 70 points
    Hi Richard,

    Thanks for the awesome info and ideas. I noticed that the device is set in 2's compliment - I had offset binary, so I made this change.
    I am confident I am sending correct data orientation to the device via the SIF as I can reliably do things like swap twos-compliment - offset binary and physically see a sine wave input from a device change to and from the expected wave shapes. I can also physically see the output turn ON/OFF when I program the iotest_ena bit 15 in config1.

    I notice the FIFO is "DISABLED" on page four of the PPT - is this required for the IOTEST to work?

    Note I don't have an "align" input - and have align disabled. I have rxsync_only enabled along with the sync input.

    I have 4-pin serial interface mode working.

    Can you write to the CONFIG4 register or the IO Alarm Bits to clear it before you do a test? I cant - they seem to be completely stuck!

    I set the LVDS bus input to all zeros, the test pattern registers to all zeros and toggle SYNC. This pattern looks correct with both signaltap (Altera's analyzer) on the IO ports and also on an oscilloscope at the device.

    I can write and read from the IOTest Registers perfectly fine.

    There has to be something different between what you have and what I have.

    Note that I do get a signal through out of the device - but it only has about 10bits performance - and expecting I have a timing issue. Hence getting this iotest pattern generator working is an important step for me.

    Kind Regards,
    Chris Burton
  • 0 in reply to Chris Burton24
    TI__Mastermind 29220 points

    Hi,

    The pattern verifier logic hangs off the input bus before the FIFO, so what the FIFO is doing has no effect on the pattern verifier.  The FIFO could be enabled or not, the ALIGN input could be used or not, etc.  The SYNC signal for the FIFO even has no effect, except that the SYNC input *is* needed for the pattern verifier to tell the pattern verifier when the pattern0 is on the input bus.    The only thing that is on the data bus before the pattern verifier is the delay elements, as the delay elements are there to allow for meeting setup/hold time into the input latches, and the verifier is there for checking that the timing into the device is good.   Keep in mind that that the delay settings will usually have one setting for the clock, and the other three fields all set the same for the two halves of the data bus and SYNC.   that is, since SYNC is latched by the device along with the data bus by the clock, the SYNC input gets the same delay setting as the data busses.   in that ppt you can see one delay element gets a value, and the other three delay settings get a different value.

    Since the pattern verifier is before the FIFO and right after the input latches, there is not really any notion of channelA sample and channelB sample.  It is just rising edge data, falling edge data, etc.    But in the pattern file I made for the TSW1400 I had to make a two-column file of samples - one column is what the TSW1400 considered channel A on rising edge, and the other column is what the TSW1400 considered channel B of falling edge. 

    I don't know what the register config4 returns if you 'clear' it when the iotest is not even enabled yet. but after the iotest is enable, then the verification pattern matching starts, comparing bit of pattern against bit on latched data.  (exclusive or gates, essentially)  anytime the latched bit doesn't match the stored bit, then the result bit is set and held for that position until the result register is cleared.  If something is drastically off, such as the SYNC at the wrong time, then the result register would likely be set again faster than you could get back to it to reread it after clearing.  But if there are occasional errors then you can just read and read and read that register until you see bits get set.   and writing zero to the result register clears it again.

    looking at my SPI GUI to see if there is anything else - the input buffers for the SYNC input and DATACLK must be enabled.  LVDS delay must be set properly.  There is a bit called bsideclk_ena in Config1 that must be set as well.  The input buffers for the LVDS data bits must be enabled in Config2 also.  That should be it, I think.

    Regards,

    Richard P.