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.

DAC3482: IOTEST doesnt work

Part Number: DAC3482
Other Parts Discussed in Thread: DAC3484

Depending on the reseverd Bit in config1 bit8, I get different behavioures. But both give not the expected behavioure. 

If I let the reserved bit in config_1 in default state: 

The IOTEST works, but databit D12 and D3 are inverted. If I invert these bits in my data interface the IOTEST gives a error free output.

If I clear the reserved bit in config_1 (bit8) as recommended in data sheet:

The IOTEST gives always the same error pattern in config_4. I'm not able to clear the register. 

The strange thing is; the DAC output seems O.K. I can change the parameter of both DAC channels as expected. 

What can that be? 

  • Hi Enrico,

    We may need to look into this further. This config1, bit 8 basically set between DAC3484 and DAC3482 mode

    The DAC3482 allows wider bus, but I expect the same interface test on the IO

    It is possible there are some logic manipulation on the back end of the IO test when switching between two modes. I do not believe the signal integrity check (i.e. BER) will be affect though (besides the logic inversion). It seems the inversion are occurring at some integer of 4 bits. (i.e. D3 and D12). 

  • Thank you for your explanation. That helped to understand what happened in the DAC. 

    In the meantime I got the IOTEST work. But sometimes I still get an unexpected behaviour.

    I use the iotest as follows:

    ---------->  force a bit error in testpattern[0] at POS[0]

    current_pattern0  = 0x7a7a
    new_pattern0      = 0x7a7b
      Do IOTEST
    PRE IOTEST_RESULT        = 0x0000                  // result is ok. 
    POST ALARM_FROM_IOTEST   = 1                       // ALARM is ok.
    POST IOTEST_RESULT       = 0x0001                  // test_result is ok. because I test against 0x7a7b

    test iotest_soll == iotest_ist =>  0x0001 == 0x0001
    ---------->  clear the bit error in testpattern[0] at POS[0]

    current_pattern0  = 0x7a7b
    new_pattern0      = 0x7a7a
      Do IOTEST

    PRE IOTEST_RESULT        = 0x0001               // test_result is ok. because that is the old one

    POST ALARM_FROM_IOTEST   = 0                    // ALARM should be 1, if the result is != 0
    POST IOTEST_RESULT       = 0x0080               // reslut should be 0x0000, because I test against 0x7a7a
    The ALARM_FROM_IOTEST Flag seems to be not sensible for this error pattern. What can be the reason for this. 
    Greetings!
  • Hi Enrico,

    I would like to confirm your programming for the rest of the patterns to be checked:

    Please advise the other patterns to be checked.

    To actually have the best check for bit errors, you should do something like the following:

    1. Pattern0 = 0xAAAA

    2. Pattern1 = 0x5555

    3. Pattern2 = 0x5555

    4. Pattern3 = 0xAAAA

    Note: pattern0 and pattern2 are different to ensure the two rising edge data latching are switched to check for error. 0xAAAA pattern or b1010....pattern are used and 0x5555 or b0101.... are used to check for different LVDS toggling

    Also, please advise if you have cleared the alarm by writing 0 to it first before reading. The alarms are sticky and the error could be a result of the switching of LVDS waveform or switching of pattern programming over SPI. 

  • Enrico,

    I am closing this thread for now. You may always re-open the thread by replying back to the post. Thanks.

    -Kang

  • Thanx for you answer. 

    I followed your recommendations and got results as follows. 

    With your rcommended pattern I got only Errors. :

    ---------->  test_pattern_dac_[0] <==> test_pattern_fpga[0]  0xaaaa <==> 0xaaaa
    ---------->  test_pattern_dac_[1] <==> test_pattern_fpga[1]  0x5555 <==> 0x5555
    ---------->  test_pattern_dac_[2] <==> test_pattern_fpga[2]  0x5555 <==> 0x5555
    ---------->  test_pattern_dac_[3] <==> test_pattern_fpga[3]  0xaaaa <==> 0xaaaa
    ---------->  test_pattern_dac_[4] <==> test_pattern_fpga[4]  0xaaaa <==> 0xaaaa
    ---------->  test_pattern_dac_[5] <==> test_pattern_fpga[5]  0x5555 <==> 0x5555
    ---------->  test_pattern_dac_[6] <==> test_pattern_fpga[6]  0x5555 <==> 0x5555
    ---------->  test_pattern_dac_[7] <==> test_pattern_fpga[7]  0xaaaa <==> 0xaaaa
    ---------->  Test pattern in FPAG and DAC are equal. IOTEST should deliver valid results.
      Do IOTEST
    PRE ALARM_FROM_IOTEST   = 0
    PRE IOTEST_RESULT    = 0xffff
    POST ALARM_FROM_IOTEST   = 1
    POST IOTEST_RESULT    = 0xffff
     
    If I program the pattern inverted to each other, the test runs through:
     
     
    ---------->  test_pattern_dac_[0] <==> test_pattern_fpga[0]  0xaaaa <==> 0x5555
    ---------->  test_pattern_dac_[1] <==> test_pattern_fpga[1]  0x5555 <==> 0xaaaa
    ---------->  test_pattern_dac_[2] <==> test_pattern_fpga[2]  0x5555 <==> 0xaaaa
    ---------->  test_pattern_dac_[3] <==> test_pattern_fpga[3]  0xaaaa <==> 0x5555
    ---------->  test_pattern_dac_[4] <==> test_pattern_fpga[4]  0xaaaa <==> 0x5555
    ---------->  test_pattern_dac_[5] <==> test_pattern_fpga[5]  0x5555 <==> 0xaaaa
    ---------->  test_pattern_dac_[6] <==> test_pattern_fpga[6]  0x5555 <==> 0xaaaa
    ---------->  test_pattern_dac_[7] <==> test_pattern_fpga[7]  0xaaaa <==> 0x5555
    ---------->  !!!! Attention !!!! Test pattern in FPAG and DAC are not equal.
     
    ---------->  force a bit error in testpattern[0] at POS[0]
    current_pattern0  = 0xaaaa
    new_pattern0      = 0xaaab
      Do IOTEST
    PRE ALARM_FROM_IOTEST   = 0
    PRE IOTEST_RESULT       = 0x0000
    POST ALARM_FROM_IOTEST  = 1
    POST IOTEST_RESULT      = 0x0001
    assert iotest_set == iotest_actual =>  0x0001 == 0x0001
    ---------->  clear the bit error in testpattern[0] at POS[0]
    current_pattern0       = 0xaaab
    new_pattern0           = 0xaaaa
      Do IOTEST
    PRE ALARM_FROM_IOTEST   = 0
    PRE IOTEST_RESULT       = 0x0001
    POST ALARM_FROM_IOTEST  = 0
    POST IOTEST_RESULT      = 0x0000
    check iotest_set and iotest_actual =>  0x0000 <==> 0x0000
     
     
    Do I have a problem with the read edges? Can I change that in a config register ? 
     
    Greetings!
  • Hi Enrico,

    To help with the debug, please do the following:

    1. have one high speed probe probe the LVDS DATACLK rising falling edge.

    2. have another high speed probe probe the LVDS Data[0].

    3. check the setup/hold time of the DATACLK and LVDS data. Check if the pattern matches the programmed Patter[0] to Pattern[8]

    4. adjust the setup/hold time of the LVDS dataclk with respect to LVDS data accordingly to clear the data. You may also use our dataclk or data delay feature of the DAC3484 to adjust the timing

    This feature had been verified with these types of pattern both during characterization and also final test before shipment. In my experience, user will typically have to probe the signal to get an actual sense of the transmitted signal from the FPGA/ASIC to get an understanding of actual error.