Q91 + modelsim ae 6.5 + avalon, непонятная проверка сигнала writedata Опции

[torik]

Есть самодельный компонент SOPC, который получает данные по Avalon-ST, записывает их в память (для простоты on-chip), читает оттуда и выдает на TFT.
То что приходит по Avalon-ST пишется в FIFO, из которого данные и пишутся в память по Avalon-MM.

Все это дело моделируем в modelsim. Он выдает следующее предупреждение:

525 ns: VFB_11_0_VWR_writedata did not heed wait!!!

Смотрю чё там:

Код

//VFB_11_0/VWR waited last time, which is an e_register
  always @(posedge clk or negedge reset_n)
    begin
      if (reset_n == 0)
          active_and_waiting_last_time <= 0;
      else
        active_and_waiting_last_time <= VFB_11_0_VWR_waitrequest & (~VFB_11_0_VWR_read_n | ~VFB_11_0_VWR_write_n);
    end

Код

  //VFB_11_0_VWR_address matches last port_name, which is an e_process
  always @(posedge clk)
    begin
      if (active_and_waiting_last_time & (VFB_11_0_VWR_address != VFB_11_0_VWR_address_last_time))
        begin
          $write("%0d ns: VFB_11_0_VWR_address did not heed wait!!!", $time);
          $stop;
        end
    end

Мне непонятно, о чем меня предупреждают?

Что не так с сигналами записи?

Эскизы прикрепленных изображений

 

[vadimuzzz]

не прошла транзакция, инкрементить/писать в следущий адрес нельзя, пока wait_request не установится в 1

[torik]

Ну дела, и чем это может быть вызвано? На вид вроде и с сигналами все нормально. В железе все тоже работает без вопросов, просто захотелось промоделировать для обучения и некоторой доработки...

[vadimuzzz]

ну это авалон так работает, при любой операции нужно ждать свой wait_request, это для разделения полосы пропускания шины между устройствами. иначе одно устройство может забить весь канал. нужно просто еще одно условие в проверку добавить в операциях чтения/записи. так, как у вас сейчас сделано, вообще говоря неправильно - в момент записи в память все остальные операции блокируются, для систем реального времени это м.б. недопустимо.

[torik]

ну это авалон так работает, при любой операции нужно ждать свой wait_request, это для разделения полосы пропускания шины между устройствами. иначе одно устройство может забить весь канал. нужно просто еще одно условие в проверку добавить в операциях чтения/записи. так, как у вас сейчас сделано, вообще говоря неправильно - в момент записи в память все остальные операции блокируются, для систем реального времени это м.б. недопустимо.

Безусловно, про wait_request я не забыл. Забыл, что схитрил для эксперимента: перевернул clk FIFO, с которого читаю данные для записи в мастера (т.к. первый байт иначе неверный, на рисунке между двумя курсорами).
Хитро придуман тест...

Эскизы прикрепленных изображений

 

[torik]

Теперь перейдем к более сложной картинке.

В предыдущей данные для записи менялись в неположенное время и это было хорошо заметно. Теперь та же ситуация с чтением:

# Break in Module VFB_11_0_VRD_arbitrator at D:/altera/modelsim/VFB_11_test/sopc1.v line 368
2625 ns: ~VFB_11_0_VRD_read_n did not heed wait!!!

Причем ошибка возникает только в месте, где курсор поставлен, соседние транзакции не ругаются.

Эскизы прикрепленных изображений

 

[vadimuzzz]

ну из той же оперы. read_n всегда 0, даже когда wait_request=0, ему это не нравится.

[torik]

Ну спецификации это не противоречит.
На картинке из спецификации сигнал записи или чтения удерживается, пока waitrequest установлен.

Эскизы прикрепленных изображений

 

[vadimuzzz]

~VFB_11_0_VRD_read_n did not heed wait!!!

означает, что в момент назначения сигнала read_n не учитывается значение wait. может там случайно совпали диаграммы? код покажите. картинка, что вы привели не показывает случай последовательного чтения.

[torik]

Прикладываю проект. Video_rd_11 - чтение, video_wr_11 - запись. моделсим запускаю из ква, диаграммы загружать из wave1.do.

Код там еще тот, ногами меня не пинать за это. Давно делал, и хотя все работает, но необходимо констрейны прописать, выловить глюки и повысить частоты...

Прикрепленные файлы

 VFB_11_test.rar ( 433.18 килобайт ) Кол-во скачиваний: 27

 

[vadimuzzz]

вот такую же проверку в чтение и воткнуть :
if ((avm_VRD_waitrequest == 1'b0)&&(FIFO_VRD_cnt > 0)) begin //выдрал из записи

[torik]

И все-таки нет, сигналы read_n, write_n не нужно сбрасывать когда waitrequest = 1 (я конечно попробовал, но результат вполне предсказуемый - более медленное чтение и... то же самое предупреждение моделсима).
Вот на картинке показана запись, желтой полосой - момент выдачи предупреждения. Происходит это в момент установки сигнала write_n одновременно с сигналом locked, причем не всегда, а только через раз-другой.

Эскизы прикрепленных изображений

 

[vadimuzzz]

сейчас работает вот эта проверка:
if (active_and_waiting_last_time & (~VFB_11_0_VWR_write_n != ~VFB_11_0_VWR_write_n_last_time))
только вы курсор на один такт сдвинули, не учли задержку. говорит, видимо, о том, что если сигнал write_n был назначен в момент wait_rq=1, то на след. такте его менять нельзя, транзакция не завершится.

а вот со случаем выше я наврал
# Break in Module VFB_11_0_VRD_arbitrator at D:/altera/modelsim/VFB_11_test/sopc1.v line 368
непонятно, как вообще могла выполниться проверка
if (active_and_waiting_last_time & (~VFB_11_0_VWR_read_n != ~VFB_11_0_VWR_read_n_last_time))
ведь у вас всегда VFB_11_0_VWR_read_n=0

[torik]

Про то и речь...

[vadimuzzz]

active_and_waiting_last_time

(~VFB_11_0_VWR_read_n != ~VFB_11_0_VWR_read_n_last_time)

а наверх их вывести можно? поглядеть бы в момент ошибки.