Controlling the TSW1200 via USB/UART interface

Hi,

Yes, the value to write to register x2 is x03 for ADS5463.  What this value means is as follows:  The firmware for the TSW1200 FPGA is organized into two major sections.  The front end section interfaces to the data converter and adapts to the format of the data and reformats the data into four lanes of data with clock, with 16 bits per sample.  The second major section of the firmware is the FIFO buffer itself and the UART connection to the USB.   The register 2 selects which of these data lanes is to be used to write into the FIFO buffer memory.  (The ini files you have looked into have parameters for number of bits and hardware offset.  These parameters identify how many of the 16 bits are valid for that data converter and the position of those bits in the word.  The hardware offset tells how many bits to throw away off the bottom of the word if the data from that EVM were not lsb-justified for some reason.  For example, ADS5474 is a 14bit ADC and the 14 bits occupy the lower 14 bits of the sample.  So hardware offset = 0.  But the ADS5463 is a 12bit ADC that fits on the same EVM circuit board as the ADS5474, with the 2 lsbs not used, so the hardware bit offset for ADS5463 = 2.  This means that the 12 valid data bits reside in the middle of the 16 bit word with 2 invalid bits below the sample and 2 invalid bits above the sample.)

So the register 2 selects which data lane ot of four available is to be chosen to load memory.  But the FIFO blocks themselves can be written to at a maximum rate of 250MHz.  This is a hard limit set by the on-board oscillator on the TSW1200.  The ADS5463 has a sample rate of up to 500MHz.  So for ADS5463 we must write two samples at a time into the FIFOs, and so two data lanes are chosen by setting two bits in the register 2 channel selection field.  One of the these data lanes is rising edge data from the ADC and the other lane is falling edge samples from the ADC.   (If you see the ini file for our new ADS5400 1000Msps device you would see that all four data lanes are chosen to write four samples at a time into the four banks of FIFO at 250M each in order to support the full 1000Msps sample rate.)

When we were writing the firmware for the parallel format data converters, we did not expect to ever support as many as four channels of data converter so we were a little wasteful on assinging these four internal data lanes from the ADC interface to the FIFOs.  The first two lanes always carry rising and falling edge samples, thus the ADS5463 will want x03 written to register 2.  The next data lane always carryies data from a single channel parallel format ADC such as ADS5483, and thus the value x04 is written to register 2.  Dual channel parallel format ADCs such as ADS62P49 will have the two channels available on the thrid or fourth lane, so the ini file shows value x04 for one of the ADC channels and x08 for the other channel for register 2.

One more thing, since the data is loaded into the FIFO memory two samples at a time, the Labview GUI will get back a buffer of data where the samples are *not* continuous.  If you look at 32768 samples, you will get first all rising edge samples and then all falling edge sampes. (or vice versa, i am not sure which edge is first from mmeory, really.)  So the Labview code has to reassemble the sample into proper order by splitting the buffer into two and 'zippering' the samples back into proper order of rising edge sample, falling edge sample, rising edge sample,etc.

For reset, i am not aware of a minimum required length of time for reset.  I will have to look deeper.  I was not aware of a minimum value, but i will need to look to see if the reset goes to the Xilinx PLL that makes the 250MHz clock that goes to the FIFOs.  If that is reset, then there may be some minimum reset time.  I will also have to look into the Labview or Matlab code to see if the original author had added a deliberate wait state.  I am not aware of a need to wait before turing off reset.  The state machine that handles register accesses from the uart is pretty simple.  It always waits for pairs of bytes.  The first byte from the software through the USB and then through the uart into the FPGA is always address, and the next byte is data.  The software has to be careful to not get into a case of the hardware expecting another byte while the software thinks it is done. (For example, if the user presses a reset button on the hardware wile the GUI is still writing registers.)

I'm not sure what you mean by reading back /0.  You mean you get just four bits?  I'm not understanding the question yet, i'm afraid.

We did not expect to support the hardware interface in such detail that customers would want to write their own interface to the hardware.  We expected to just supply the compiled Labview-based GUI and then for good measure supply the Matlab code where the interface to the hardware was already coded up and the customer could add to that.  I looked into writing such a document that would fully describe all that is needed to write a GUI for the hardware, but there are so many cases of data format that it became apparent that the document would be huge.  For further visibility into the structure of the TSW1200 register map and what the registers all mean, i'd suggest starting with email and/or a phone call directly

Regards,

Richard Prentice

rprentice@ti.com

Thanks Richard!  Your patience and thoroughness are appreciated.

Re:  'zippering' the samples back into proper order

FYI: The LabVIEW array-function primitive for this is called: "Interleave Arrays".  On this subject, it looks like reg. 0x13 "controls the selection of whether the first clock edge is rising or falling." Please confirm: In this case we're writing to FIFOs 1 & 3, and FIFO 1 will alway contain the first sample; every sample in FIFO 1 will represent the edge dictated/indicated by reg.0x13, D0.  If D0 is zero (the default) then FIFO 1 will reflect all rising edges.  Important details for me are: when "interleaving" or "zippering" the two arrays, FIFO 1 always has precedence;  also, as buffers are returned serially and concatenated, it's necessary to split the data returned at the precise byte... 

Re: reading back /0

Sometimes after sending Software-reset byte-sequence to FPGA, FPGA returns a single byte with value zero (0).  Maybe (I'm not sure) if a SW reset is being sent while FPGA is transferring ADC results.  Anyway, if the zero-byte shows-up after SW reset, the FPGA is in a minor "hosed" state and needs "long" reset.

Regarding SW reset and reliability.  To do SW reset, I had code send "\00\FF" wait 1ms then send "\00\00", but found that [exactly] half the time this put the FPGA into a state where it refused to [then] acknowledge a Start sequence, or return a register value being read.  I changed my code to send "\00\FF\00\FF" wait 1 ms then send "\00\00" - now the FPGA will subsequently Start and/or let me read register(s).  I'm grasping at straws as to why this works and is necessary  - UART BaudRate mismatch perhaps?.  Until a documented rationale for this code exists, I hesitate to deliver code without some kind of disclaimer.

Thanks/Cheers!