Forum Discussion

host's avatar
host
Icon for Occasional Contributor rankOccasional Contributor
3 years ago

Serial Lite III "start_of_burst" and "end_of_burst"

I'm using the Serial Lite III IP in duplex mode on a Stratix 10 FPGA.
In the Tx direction the IP has the following user driven input signals:

start_of_burst_tx
end_of_burst_tx

My mode of work requires driving the valid_tx signal discontinuously ( as I don't always have data to send ). However, the data itself isn't segmented into packets and doesn't have a defined "start" or "end".

Question:
Can I tie start_of_burst_tx and end_of_burst_tx to GND

8 Replies

    • host's avatar
      host
      Icon for Occasional Contributor rankOccasional Contributor

      If my data isn't really segmented into packets , do I have to assert the "end of burst" signal EVERY TIME that I de-assert valid ?

      If I don't - doesn't this mean that I can simply tie it to GND ?

    • host's avatar
      host
      Icon for Occasional Contributor rankOccasional Contributor

      Hi K**bleep**ij_Intel,
      Can you please comment on my last question ?

  • Kshitij_Intel's avatar
    Kshitij_Intel
    Icon for Frequent Contributor rankFrequent Contributor

    Hi,


    If my data isn't really segmented into packets, do I have to assert the "end of burst" signal EVERY TIME that I de-assert valid ?

    [KG] - Not EVERY TIME, I assume you are having continuous data or you are sending data in burst form, so you have to assert the "end of burst" signal one-time at the end. See Figure 13 5.8. User Data Interface Waveforms (intel.com)


    If I don't - doesn't this mean that I can simply tie it to GND?

    [KG] - You cannot tie to GND.


    Thank you,

    Kshitij Goel


  • host's avatar
    host
    Icon for Occasional Contributor rankOccasional Contributor

    You say:

    Not EVERY TIME, I assume you are having continuous data or you are sending data in burst form, so you have to assert the "end of burst" signal one-time at the end.

    But my data doesn't have an "end"
    It's an endless stream of data that starts when the FPGA is powered on and NEVER seizes.

    When would you assert "end of burst" in that case ?

  • Kshitij_Intel's avatar
    Kshitij_Intel
    Icon for Frequent Contributor rankFrequent Contributor

    Hi,


    It means you are using the continuous mode, in that case it is dependent on valid, valid should be continuously high. For the example waveform please refer 5.8. User Data Interface Waveforms (intel.com) Figure 13.


    As continuous mode is one long burst, in this mode the "start_of_burst" signal is asserted only once at the start of the data. And you can optionally send an end of burst signal at the end of continuous mode.


    Refer 5.9.2. Signals for Intel® Stratix® 10 Devices for more info.


    Thank you,

    Kshitij Goel




  • host's avatar
    host
    Icon for Occasional Contributor rankOccasional Contributor

    Thanks for trying to help - but you're incorrect.

    In my use case - I'm de-asserting valid so by definition I'm using BURST MODE - and NOT continuous mode.

    The data I'm sending is NOT "packet oriented" - so although valid isn't continuous my data stream can be treated as a SINGLE INFINITE PACKET.

    So in my use case:
    1. I have to assert "start_of_burst" (on the first valid).

    2. I don't have to assert "end_of_burst" - because my packet NEVER ENDS.

    I simulated the design with discontinuous valid and "end_of_burst" tied to GND - and it works fine.

  • Kshitij_Intel's avatar
    Kshitij_Intel
    Icon for Frequent Contributor rankFrequent Contributor

    Hi,


    I’m glad that your design is working now, I now transition this thread to community support. If you have a new question. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


    Thank you,

    Kshitij Goel