• Maciej Lipinski's avatar
    [streamers] bugfix of streamers simulation · f56b734e
    Maciej Lipinski authored
    For simulation, the second duration is forced to be shorter with the
    generic g_sim_cycle_counter_range. The problem is that the tai/cycle
    counters are still counting full seconds, the trick was done only
    when calculating the delay in function f_cycles_counter_range()
    in fixed_latency_ts_match.vhd. This worked fine unless the timestamps
    were at the edge of the "shorter" second and fixed-latency was
    enabled. In such case, it happened that the time of releasing
    data from streamers was calcualted for TAI+1, yet TAI was incremented
    after the "true" second, not the shorter one. So, the simulation
    was stuck.
    
    To avoid messing up with PPS gen in which the tai/cycles are
    generated, for simulation the tai/cycle values are overriden
    in the xwr_streamer top module. This "alternative" TAI time
    is counted from the time when time_valid goes HIGH.
    
    This solution should work for streamers, provided that tx/rx
    instances have the time_valid go HIGH more or less at the same time.
    As far as I can tell, this is usually the case.
    f56b734e
Name
Last commit
Last update
..
fabric Loading commit data...
timing Loading commit data...
wr_dacs Loading commit data...
wr_eca Loading commit data...
wr_endpoint Loading commit data...
wr_mini_nic Loading commit data...
wr_nic Loading commit data...
wr_pps_gen Loading commit data...
wr_si57x_interface Loading commit data...
wr_softpll_ng Loading commit data...
wr_streamers Loading commit data...
wr_tbi_phy Loading commit data...
wr_tlu Loading commit data...
wr_txtsu Loading commit data...
wrc_core Loading commit data...
Manifest.py Loading commit data...