-
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 | ||
timing | ||
wr_dacs | ||
wr_eca | ||
wr_endpoint | ||
wr_mini_nic | ||
wr_nic | ||
wr_pps_gen | ||
wr_si57x_interface | ||
wr_softpll_ng | ||
wr_streamers | ||
wr_tbi_phy | ||
wr_tlu | ||
wr_txtsu | ||
wrc_core | ||
Manifest.py |