• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 4051 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.

AWR1843: LVDS interface definition

SebastianK
Prodigy 90 points
Part Number: AWR1843

HI,

I would like to use the LVDS output interface of the AWR1843 radar chip, but I'm missing a few details of the interface description which I could not yet find in any manual or document. The open questions at the moment are the following:

1. What is the frequency of the frame clock? In chapter 2.4.1 of the document „TSW140x High Speed Data Capture/Pattern Generator Card” I could find that it is the same as the ADC sampling rate. For the AWR1843 this should then be 25 MHz, right?

2. What is first sent over the serial interface, MSB or LSB?

3. From chapter 24.4.3 of the document „mmWave Studio GUI“ I could learn, that there is maybe a sync-pattern before each packet. Is that true? Does it come before each packet or only before the very first one of the data burst? How is it distributed over the two LVDS lanes? How does it really look like?
| 2047 | 2048 | 2047 | 2048 | …           or           | 2047 + 2^15 | 2048 + 2^15 | 2047 + 2^15 | 2048 + 2^15 | ...

4. What is the spacing between the packets or sync patterns? Are there gaps or is the data stream contiguous (within a burst)? What is sent when there is no data to send?

Many thanks already in advance for helping me with those questions.

  • 0
    TI__Guru*** 147964 points

    Hi,

    Please see this thread related to LVDS clock.

    https://e2e.ti.com/support/sensors/f/1023/p/614946/2277483#2277483

    Are you capturing the LVDS data using the DCA1000 board?

    thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 90 points

    Dear Cesar,

    thank you very much for your answer. This thread is about an "LVDS_VALID" signal and therefore, unfortunately, not related to any of my questions.

    We are designing at the moment our own receiver board, why it would be very helpful to get more information about the interface.

    Regards,

    Sebastian

  • 0 in reply to SebastianK
    TI__Guru 58035 points

    Hello Sebastian,

    1) The frame CLK signal has one CLK cycle per sample. ie if you have configured sample width as 16 bit then frame clk will have one clk in 16 data bits (in 12 bit mode it will be one frame clk in 12 bits). Each data bit is sent at a rate matching the LVDS clock rate configured. For a 600Mbps LVDs clk rate each bit is transmitted at 600Mbps rate (300Mhz DDR clk). So now based on your configuration you can compute the frame clk rate.

    2). The following app note :http://www.ti.com/lit/an/swra555/swra555.pdf explain in detail the format in which the LVDS data is sent out.

    3). As mentioned in the mmwave studio user guide , the SYNC pattern exists only in continuous streaming mode. In the regular chirp mode there is no sync pattern . The SYNC pattern in continuous streaming mode is mentioned in the mmwave studio guide.

    4) The data is always sent in bursts of one  chirp data. In between the burst the data lines and frame clk lines do not toggle. The Frame Clk line is used to identify the valid data.

    Regards,

    Vivek

  • 0 in reply to Vivek Dham
    Prodigy 90 points

    Dear Vivek,

    thank you very much for your answers.

    Since the alignment of the signals in the timing diagram of the LVDS lines (e.g. in the Datasheet for the awr1843) is not optimal and the stopping of the frame clock is probably a bit misleading, I created them according to your information by my own for the three different bit-configuration cases. Is the image shown below correct (for the MSB first configuration)?

    Is the LVDS_CLK running continuously? In the timing diagram of the datasheet it looks like the clock is starting only shortly before the data.

    Then, according to the "AWR1xxx Data Path Programmer's Guide", one can configure the LVDS interface also with SDR. What is the alignment between the LVDS_CLK and the other lines in this case? Is it still centered or is it edge aligned in this case?

    By the way, all information I got from this document is based on the AWR16xx family, because the AWR18xx family is not yet mentioned there. Since both have only 2 data lanes, they should be the same, is this correct?

    Then, the LVDS format can be configured in 12bit, 14bit and 16bit format (as shown above). The same seems to apply to the different data to be sent via the linked list entries. For each individual data type, you can select whether it is to be sent in 12bit, 14bit or 16bit format. For the CQ data it is states explicitly that if the LVDS format is smaller than 16bit, the CQ data is split across multiple LVDS words and the receiver has to reassemble them. How is this splitting done exactly? Are two 12/14bit LVDS words send for each CQ word or is it a continuous stream of appended CQ data words, split into 12/14bit chunks which are then transmitted?

    How does this work for the other data types? In the AWR18xx/16xx/14xx Technical Reference Manual it is stated that "If fewer than 16 bits of the data are sent out, the LSB bits of the CBUFF unit are send out". Does this mean that the remaining MSB bits are lost?

    Thank your very much for your help,

    Sebastian

  • 0 in reply to SebastianK
    TI__Guru 58035 points

    Hello Sebastian,

    The timing diagram you show above is correct, and you are right that 1642 and 1843 would have the same LVDS timing.

    Regarding your question about the 12/14/16 bit modes, for the ADC data in 12/14 bit mode internally we shift the 16 bit data to get only 12/14 valid bits. Its like LSBs are  truncated.  For CQ data is you select 12/14 bit modes , this impacts only the data transfer out on the LVDS interface and not really the valid data size. So if you had 192 bits of CQ data for example, in a 16 bit mode it would sent out as 12 samples (across 2 lanes) while in 12 bit mode it will be sent out as 16 samples (across 2 lanes). Each sample being defined by a LVDS FRM CLK  cycle. Does that help?

    Regards,

    Vivek

  • 0 in reply to Vivek Dham
    Prodigy 90 points

    Dear Vivek,

    thank you you very much, yes that is clear now.

    What is about the other questions:
    Is the LVDS_CLK running continuously or does it also stop if there is not data to be send?
    What is the alignment of the lanes in SDR mode?

    Regards,

    Sebastian

  • 0 in reply to SebastianK
    TI__Guru 58035 points

    Hello Sebastian,

    The LVDs CLK is continuously running. It does not stop inbetween. Only the FRM CLK stops toggling when there is no valid data.

    Regards,
    Vivek

  • 0 in reply to Vivek Dham
    Prodigy 90 points

    Dear Vivek,

    thanks for this information, this makes the design much easier.
    The last open question is the alignment of the data lanes (and frame clock lane) to the clock lane in SDR mode. Do you have any insights for me in this case as well?

    Greetings,
    Sebastian

  • 0 in reply to SebastianK
    TI__Guru 58035 points

    Hello Sebastian,

    In case of SDR each data is aligned to the rising edge of the clock. The frame CLK doubles in width since the sample now takes double the number of CLK cycles.

    regards,

    Vivek

  • 0 in reply to Vivek Dham
    Prodigy 90 points

    Dear Vivek,

    Thank you very much, now everything should be clear for the moment.
    Is there maybe something like a behavioral model of the chip or at least of the LVDS bus, written in VHDL or Verilog, that we can use for our developments and that you could provide?

    Greetings,
    Sebastian

  • 0 in reply to SebastianK
    TI__Guru 58035 points

    Hello Sebastian,

    We don't have a model available. But the relationship between the DATA, FRAME_CLK and CLK is all you need, there is no other information the model would provide in terms of timing. 

    Regards,

    Vivek