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

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


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




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

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

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

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

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

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

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

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


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

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

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

~VFB_11_0_VRD_read_n did not heed wait!!!

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

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

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

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

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

сейчас работает вот эта проверка:
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

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

active_and_waiting_last_time

(~VFB_11_0_VWR_read_n != ~VFB_11_0_VWR_read_n_last_time)

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

Итак, ключом к разгадке страшной тайны является фраза:


Возьмем сигнал write_n.
На первой картинке вариант, когда моделсим выдает предупреждение. Видно, что write_n "отпущен" не дождавше, когда waitrequest станет равен 0. В результате транзакция, которую логичнее было бы завершить, прерывается.
На во второй все впорядке. write_n отпущен только когда waitrequest = 0. Транзакция завершается как положено.

Первый случай также работоспособен как и второй, но второй все же логичнее.


Теперь весь полученный код еще как-то надо оптимизировать, чтобы частоты повысить...

так с write и было понятно, а вот в первом примере с read? вы же его вообще не дергаете, в чем причина?

У меня подобной ситуации больше не повторялось, глюк какой-то был наверное.

кстати, с версии 9.1 идет интересный документ
www.altera.com/literature/ug/ug_avalon_verification_ip.pdf

Ага, есть такой. Но я пока что обошелся без этого, т.к. задача не очень сложная.