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.

TSW1400 firmware for 2 wire 14 bit use of ADS6445

Other Parts Discussed in Thread: ADS6445

Hello, I am trying to use the TSW1400 and high speed data converter pro GUI to collect data from an ADS6445.  The ADS6445 is on our own board bot connected to the TSW1400 with the same connector as the ADS EVM boards use.  What firmware should I load for the following ADC setup?

CFG1 = LVDD DDR Bit CLK & 2-wire interface

CFG2 = LVDD 14x serialization at rising edge

CFG3 = GND (reserved)

CFG4 = 3/6 LVDD MSB first & offset binary

  • Hi,

    you would want to use the same firmware as the ADS6445 selection would use if it were an EVM connected to the TSW1400 - and in the ini file for that device is the firmware name:  Interface name="ADC_2W_16b"

    The TSW1400 does not have a firmware for 14-bit mode.  It uses the 16-bit mode which is 8x serialization on each of the two LVDS lines and the two most significant bits zero-padded.  The ini file goes on to say Number of Bits=14 which tells HSDCPro to do the FFT processing on 14bits of the word and throw away the two padded zeros.

    If you look at the datasheet timing diagram for the 16bit mode, you see that with 8x serialization on each LVDS line and a DDR (dual data rate) bit clock, then each sample starts with a rising edge of the bit clock.   But in 7x serialization mode on each LVDS, one sample will begin with a rising edge of the bit clock and the next sample would begin with a falling edge of the bit clock.    This greatly complicates the Verilog for the ADC interface, and we did not create a firmware for this case.  its not impossible, but more complicated.  And we do not use SDR option on the bit clock because of the limitation that would impose on the supported sample rate (table 24).

    If you look at the 12bit versions of this family. the firmware was written to use the 6x serialization without any zero padding for the same reason - with 6x serialization and a DDR bit clock, each sample begins on the same edge of the bit clock.

    I expect that soon we *will* have a firmware written for the 14 bit (7x serialization) mode, but as of now we do not.

    Regards,

    Richard P.

  • Richard, I appreciate the response.  I am now having a seperate issue.  When down load the firmware with power on the ADC, all the user_LEDs light up except the User_LED4.  Looking at the paperwork for the TSW1400, this light inticates when the FPGA PLL2 is locked to the ADC input clock from port 1.  When I try to collect data I also get the following message: "Frame Clock error in Read DDR to file".  These two issues would indicate that the TSW1400 is not receiving a clock from the ADC.  I have verified with a scope that the following clock signals are being sent over the cable between the ADC and the TSW1400.  Any suggestions?  Is this PLL2 expecting any particular wave form or frequency?  Is there somewhere I can probe and see if it is actually receiving one or not? 

     

    Thanks,

    Chris

     

  • Hi,

    it would be normal with this EVM to not have User_LED4 lit.  This device only has one bit clock output for all the channels.  The TSW1400 has available two clock inputs, but the vast majority of our EVM only need to use one clock signal into the TSW1400.  Only in the case where an EVM requires that you use clock A for channel A and clock B for channel B would you need to use two clocks into the TSW1400.  In that case both User_LED3 and User_LED4 should be lit.  But in this case, just User_LED3.  The other LED is not meant for Frame Clock.

    I suspect that there is still some mismatch in the configuration of your ADC and what the TSW1400 expects.  That, or the board routes Frame Clock to dfferent connector pins than we want to see it on, or inverted, or something.

    The TSW1400 firmware for the 2-wire and 1-wire serial formats do not use the frame clock to find the boundary of the sample in logic in the FPGA.  (In our old TSW1200 and the newer TSW1405 we *do* use Frame clock to find the sample boundary in FPGA logic.)   The TSW1400 firmware uses a 1->4 deserialization block on the serial lanes, so the data is deserialized into nibbles to start with.  The Altera 1:4 deserializer cell has a 'jog' input to move its boundary one bit.  What the HSDCPro does when you press capture is it first captures Frame Clock all by itself and does a pattern match against a pre-set pattern stored in the .ini file for that EVM.  Software determines if the data needs to be shifted 1 bit, 2 bits, or 3 bits, and the software issues the right number of jogs to the firmware.  *Then* the HSDC Pro captures the data.  (That is just the way the author of the code wanted to do it.)

    If the HSDC Pro cannot match the captured Frame Clock to the pattern in the ini file, then it issues the error message that you saw.  So for some reason, HSDC Pro cannot 'see' the Frame Clock pattern it expects.  Are you now in 2-wire 16-bit mode so that the Frame Clock is 1111 0000 in pattern? 

    The ini file has this for the pattern match:

    fclk_code=0F0F0F0F, F0F0F0F0

    (The software is smart enough to know that shifting 5 bits is the same as shifting 1 in a 1:4 deserializer, so it should match either of those two pattens.  That doesn't mean that Frame Clock can really be inverted and all would still work.)

    Regards,

    Richard P.

  • Richard, I have confirmed that the HSDC Pro software has selected the 2-wire, 16 bit firmware.  and our ADC is set up as follows:

    CFG1 = LVDD DDR Bit CLK & 2-wire interface

    CFG2 = LVDD 14x serialization at rising edge

    CFG3 = GND (reserved)

    CFG4 = 3/6 LVDD MSB first & offset binary

    Since our ADC board is not easily configurable we decided to do a test with our exsisting ADS6445EVM.  Firsts we set up the jumpers on the EVM as:

    CFG1 = DDR, 2wire

    CFG2 = 16x, rising edge

    CFG3 = Divide by 1

    CFG4 = MSB first & offset binary

    In this configuration, the HSDC Pro could collect data with the 2w_16b firmware.  Then we changed the CFG2 jumper on the ADS6445EVM to 14x, rising edge and when we went to collect data we received the "Frame Clock error in read DDR to file" Error.  If I read your first response correctly, the software should know how to treat both of these configurations with the 2w_16b firmware.  Is this correct?  If so do you have any suggestions? 

    Thanks,

    Chris

     

  • Hi,

    No, the TSW1400 firmware requires the ADC to be in 2-wire 16 bit mode.  It needs the serialization factor to be 8x on each lane so that the Frame Clock has a period of 8 bit times and is of the pattern 1111 0000, and also so that the DDR bit clock sees each sample start with the same edge of the bit clock.  14bit mode does not satisfy either of these requirements.  That is just how the TSW1400 firmware was written.

    Regards,

    Richard P.

  • Hi, a couple of months ago I had some questions about the firmware available for the TSW1400.  One of TI's representatives told me the following: "I expect that soon we *will* have a firmware written for the 14 bit (7x serialization) mode, but as of now we do not".  Has any progress been made on this yet?  If not, any idea if it will happen in the foreseeable future?  It would really help our trouble shooting process on the system we have built. 

    Thanks,

    Chris

     

     

     

  • Hi,

    We have 14bit 2-wire (7x serialization) working in the TSW1400 now.  If you have a relatively recent installation of HSDCPro such as version 2.50 that has been on the TI web for a while now then you already have a firmware file called ADC_FIRMWARE that is used by some other devices, and this firmware already supports the 7x serialization.  The trick is creating an ini file for the specific ADC EVM that gets all the parameters right to tailer that firmware to support the format from the EVM.  I have two ini files in hand now to support 4 channels of 14bit 2wire and 2 channels of 14bit 2wire.  But I have not yet tried them with the ADS6445 EVM and Iwould like to verify it my self before passing on the ini files.  I should be able to do that next week.  These two ini files are new and are not yet in the release of HSDCPro.

    Regards,

    Richard P.

  • Richard, that sounds great.  I will make sure I have the most recent release of the HSDCPro software.  It would be great if you provide those ini files that support the 4 channels of 14bit 2wire mode once you have tested it with the ADS6445 EVM.  It will really speed along my testing process. 

    Thanks again,

     

    Chris

     

  • Hi,

    I have tried the new ini files with an ADS6445 EVM.  Please see attached for the ini files for the quad and dual options.  The firmware should already be in the HSDCPro installation. 

    One wrinkle is that I found the new firmware wants to see the serial data from the ADC in lsb-first and 2's complement format.   The old firmware wanted to see msb-first offset-binary.  I set up a stock ADS6445 with the TSW1400 and got good captures from the original ini selections and firmware.  Then I selected the new device type ini files, and moved the jumper on the EVM from 16-bit to 14-bit.  And also the jumper from msb-first offset binary to lsb-first 2's complement.  And again I got good captures.   I went through all the channels for the quad and dual cases. 

    Do you know where to copy in the ini files before using them?  (The ADC files folder in the TSW1400 Details folder where HSDCPro was installed.)

    Regards,

    Richard P.

    ADS6445 14b.zip
  • Richard, I appreciate the ini files and continued effort on this matter.  I have a question and a concern.  First, should I just drop the ini files in the ADC files folder (as mentioned above) and select the ADC_FIRMWARE.rbf in the HSDCpro software to use the 14bit firmware?  Now I have a problem, we are not using the EVM6445, rather we have hardwired the ADC into our own board.  It is set up as follows:

    CFG1 = LVDD DDR Bit CLK & 2-wire interface

    CFG2 = LVDD 14x serialization at rising edge

    CFG3 = GND (reserved)

    CFG4 = 3/6 LVDD MSB first & offset binary

    If the new firmware only wants to see lsb-first and 2's complement format, it will not work with our system.  Do I have any other options to use this software with our set up?  Can the ini files be modified or is this more detailed in the firmware?

    Chris

  • Hi,

    Yes, for HSDCPro - just drop the ini file into that folder and relaunch the HSDCPro GUI.  Once the HSDCPro finds the new ini file in there, then the new device selection should be present in the drop-down list of available devices to select.  And selecting that device should prompt the HSDCPro to load the proper firmware  You would not need to use the menus to tell it to load that firmware. 

    Hmm - looking at the ini file I see the entry near the bottom of hte file:

    LSB/MSB first=0
    //0 - LSB, 1 - MSB

    So it looks like the HSDPro could accept msb-first if the ini file were edited appropriately to have:

    LSB/MSB first=1
    //0 - LSB, 1 - MSB

    Regards,

    Richard P.

  • How to check the 1 wire or 2 wire 16 bit firmware of HSDC?
  • Hi,

    what do you mean 'check'?   From your other posting it would appear that you are getting an error message in HSDCPro when you try to capture, and I have replied to that posting as well.  but I would need to know just what EVM you are trying to use, and in what mode, and screenshots of your HSDCPro to be able to see how you are setting up the HSDCPro and what device selection you have.

    Regards,

    Richard P.