lennox 0 1 апреля, 2018 Опубликовано 1 апреля, 2018 · Жалоба здравствуйте, хотел сделать 2 эквивалентных куска генерации входных воздействий на фифо. initial begin fork ///////////////////////////////////////////////////////////////////////// pulse_gen: begin forever begin randcase 1: rand_pulse = 1; 5: rand_pulse = 0; endcase @(posedge aclk); end end ///////////////////////////////////////////////////////////////////////// push_data: begin wait(aresetn_done); forever begin s_axis_tlast = 0; s_axis_tuser = 0; if (s_axis_tready == 1) // FIFO ready to receive data begin s_axis_tvalid = rand_pulse; if (rand_pulse) s_axis_tdata = $urandom_range(255,0); @(posedge aclk); end else begin s_axis_tdata = 0; @(posedge aclk); end end end ///////////////////////////////////////////////////////////////////////// join_none end и always_ff @(posedge aclk) begin if (aresetn == 1'b0) begin s_axis_tvalid <= 0; s_axis_tdata <= 0; end else begin s_axis_tvalid <= s_axis_tready & rand_pulse; if (s_axis_tready & rand_pulse) s_axis_tdata <= $urandom_range(255,0); end end получилось, что корка по-разному реагирует на входные воздействия в двух случаях. в первом случае работает неверно (пропускается первый байт в пачке), во втором - все хорошо. подскажите в чем проблема и как исправить? спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OM-S 0 1 апреля, 2018 Опубликовано 1 апреля, 2018 · Жалоба Кажется эта ситуация называется race condition. Данные и valid меняются "одновременно" с клоком, поэтому новые значения могут захватиться либо на текущем клоке, либо только на следующем (на усмотрение симулятора). Поставьте после @(posedge aclk) небольшую паузу #1 и тогда изменения сигалов будет гарантированно после фронта слока. По этому поводу (и по многим другим) очень рекомендую почитать книжку Verilog and system verilog gotchas. 101common coding errors and how to avoid them. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 2 апреля, 2018 Опубликовано 2 апреля, 2018 · Жалоба Кажется эта ситуация называется race condition В моделсиме (и вообще в стандарте) приоритет одновременных операций в процессе симуляции четко задан. Откуда там может быть расизм? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sergey_Bekrenyov 0 2 апреля, 2018 Опубликовано 2 апреля, 2018 · Жалоба Посмотрите clocking block http://www.asic-world.com/systemverilog/clocking1.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
OM-S 0 2 апреля, 2018 Опубликовано 2 апреля, 2018 · Жалоба В моделсиме (и вообще в стандарте) приоритет одновременных операций в процессе симуляции четко задан. Откуда там может быть расизм? Расизм я вижу между параллельными fork-ами и собственно захватом данных в фифо по фронту aclk. begin ... 1: rand_pulse = 1; 5: rand_pulse = 0; @(posedge aclk); ... end и begin ... s_axis_tvalid = rand_pulse; if (rand_pulse) s_axis_tdata = $urandom_range(255,0); @(posedge aclk); ... end Какой из блоков выполнится первым и какое значение (старое или новое) s_axis_tvalid, s_axis_tdata защелкнится на входе ФИФО по фронту клока? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться