1. 30 Aug, 2019 1 commit
  2. 20 Aug, 2019 1 commit
  3. 13 Aug, 2019 1 commit
  4. 08 Aug, 2019 3 commits
  5. 14 Jun, 2019 1 commit
  6. 05 Jun, 2019 2 commits
  7. 31 May, 2019 2 commits
  8. 24 May, 2019 4 commits
    • Maciej Lipinski's avatar
    • Maciej Lipinski's avatar
      8c3ee07c
    • Maciej Lipinski's avatar
      wr_streamers: fixed bug that prevented timestamps from being latched · caa2e084
      Maciej Lipinski authored
      In the mode in which data is provided to wr_streamers with clk_ref_i,
      the timestamps are captured with the clk_ref_i clock. The input data
      then crosses domains via FIFO to clk_sys_i clock. The timestamp is
      used by FSM in the clk_sys_i domain. The pulse from the timestamper
      was expected to happen when the frame is already started to be
      generated by the FSM, thus the latch of the tag_valid pulse
      (indicating the timestamp was generated) was reseted in the IDLE
      state of this FSM. This is OK when the input data and the FSM
      are in the same clock domain. IF there is asynch FIFO in between,
      it can happen that the timestamp is generated still in the IDLE
      state of the FSM... I've changed the reset of the latch to happen
      after the timestamp is embedded in the header (i.e. in the
      FRAME_SEQ_ID state).
      caa2e084
    • Maciej Lipinski's avatar
      wr_streamers: fixed bug that caused flush_p1_i to be missed. · 03448da1
      Maciej Lipinski authored
      In case the data was received in clk_ref_i domain, the flush_p1_i
      was also received in the clk_ref_i domain. However, it was used
      in an FSM that works in the clk_sys_i domain. This could cause
      problems, for example missing the flash_p1_i pulses, thus frames
      not being sent when requested. It was easily seen in the
      spec_fixed_latency-demo testbench. In principle, the tx_flush_p1_i
      does not need to come with data, can be asynchronous to data.
      It should be a pulse, yet it can happen that it is constantly high
      (see Tom's testbench of fixed-latency mode). Thus in cross-domain
      use case :
      1. first the pulse is extended to to cycles
      2. thanks to this, the gc_sync_ffs module can be used to
         pass the signal to clk_sys clock domain, whether it is a
         pulse or not.
      03448da1
  9. 23 May, 2019 4 commits
  10. 22 May, 2019 5 commits
  11. 21 May, 2019 3 commits
  12. 20 May, 2019 1 commit
  13. 16 May, 2019 12 commits