|
Работа с Avalon ST, Как корректно работать с backprssure при регистровых задержках? |
|
|
|
Jul 4 2014, 18:31
|
Частый гость
 
Группа: Свой
Сообщений: 76
Регистрация: 8-04-11
Из: Ростов-на-Дону
Пользователь №: 64 227

|
Доброго времени суток! Какое-то время назад столкнулся со следующим вопросом, который перманентно пытаюсь решить. Пусть имеем некоторый блок, на входе и выходе которого стоят буферы FIFO с шиной Avalon ST, а между ними куча регистровой логики (например конвееризированные умножители, без обратной связи, т.е. сигналов ready) задерживающей поток на несколько десятков тактов. Сам вопрос - как в этом случае корректно реализовать работу с шиной Avalon ST? Ведь при опускании in_ready выходного FIFO данные продолжат литься, даже если завершить передачу потока в регистровую логику. У меня получилось два довольно кривых решения: 1. Размер выходного буфера выбрать большим, чем максимальная задержка внутри блока, и при опускании сигнала out_ready выходного буфера опускать сигналы in_valid и out_ready во входном буфере, тем самым обрывать входной поток, и собирать в это время выходным FIFO данные выходящие из регистров. (см рис.). 2. Ещё более некрасивый - использовать сигнал out_ready как сигнал clk_en для регистров, хотя, как я понимаю, это самый злобный способ, грозящий нестабильностью системы. Кто как решает подобные задачи? Думаю есть готовые реализациии в Altera-ских Qsys корках, но пока не натыкался ни на что подходящее под этот случай.
Эскизы прикрепленных изображений
|
|
|
|
|
 |
Ответов
(1 - 10)
|
Jul 4 2014, 19:20
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(R6L-025 @ Jul 4 2014, 21:31)  Доброго времени суток! Какое-то время назад столкнулся со следующим вопросом, который перманентно пытаюсь решить. Пусть имеем некоторый блок, на входе и выходе которого стоят буферы FIFO с шиной Avalon ST, а между ними куча регистровой логики (например конвееризированные умножители, без обратной связи, т.е. сигналов ready) задерживающей поток на несколько десятков тактов. Сам вопрос - как в этом случае корректно реализовать работу с шиной Avalon ST? Ведь при опускании in_ready выходного FIFO данные продолжат литься, даже если завершить передачу потока в регистровую логику.
У меня получилось два довольно кривых решения:
1. Размер выходного буфера выбрать большим, чем максимальная задержка внутри блока, и при опускании сигнала out_ready выходного буфера опускать сигналы in_valid и out_ready во входном буфере, тем самым обрывать входной поток, и собирать в это время выходным FIFO данные выходящие из регистров. (см рис.). 2. Ещё более некрасивый - использовать сигнал out_ready как сигнал clk_en для регистров, хотя, как я понимаю, это самый злобный способ, грозящий нестабильностью системы. Кто как решает подобные задачи?
Думаю есть готовые реализациии в Altera-ских Qsys корках, но пока не натыкался ни на что подходящее под этот случай. Для передачи данных можно чуть-чуть по другому: производить запись результатов обработки в один порт двуклоковой двупортовой памяти. Со второго порта памяти считываем данные. К адресной шине подключаете счетчик и дешифратором формируете импульсы в необходимых местах (startofpacket, endofpacket), а для valid используем 2 импульса с дешифратора + JK триггер - создание огибающей валидности данных , таким же образом можно сделать "обвеску" для передаваемого пакета - например добавить нумерацию пакетов, служебную информацию пакетов и т.д.. - с помощью мультиплексирования данных в определенные моменты времени (счетчик + дешифратор). Здесь задержками Вы упраляете сами. PS В принципе это же делается и с фифо выводом наружу счетчиков... Для приема данных - у Вас есть сигнал valid для данных - подключаем к write enable памяти (один порт двуклоковой двупортовой памяти), также счетчик который считает только при valid = 1 подключаем к адресной шине памяти. Сброс счетчика делаем по startofpacket. Если в пакете имеется служебная информация, то тоже делаем мультиплексирование (чтобы не "засорять" блочную память) в нужные моменты времени.
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Jul 4 2014, 19:36
|
Частый гость
 
Группа: Свой
Сообщений: 76
Регистрация: 8-04-11
Из: Ростов-на-Дону
Пользователь №: 64 227

|
Цитата(krux @ Jul 4 2014, 23:21)  работайте с Ready Latency=0, это самый простой и надежный вариант. для согласования с другими стандартными альтеровскими корками используйте соответствующие Qsys-"переходники".
любые другие варианты с Ready Latency>0 действительно требуют либо FIFO-шек, либо буферной логики на N тактов по входу. да оно-то понятно, что самый простой вариант, но не всегда получается. А когда задержка довольно большая, Qsys-ский timing adapter на хочет с ней работать (если, конечно, его вручную не править).
|
|
|
|
|
Jul 4 2014, 20:02
|
Профессионал
    
Группа: Свой
Сообщений: 1 700
Регистрация: 2-07-12
Из: дефолт-сити
Пользователь №: 72 596

|
Цитата(Maverick @ Jul 4 2014, 23:57)  в реализации Avalon_ST не сложен и я сообщением выше описал возможный вариант реализации... при подключении к чужим коркам - требуется проверять свои при помощи BFM. Тогда не нужно будет править Qsys-ский timing adapter который Цитата не хочет с ней работать (если, конечно, его вручную не править). всё таки спецификация достаточно строгая, и соответствовать ей тоже нужно полностью
--------------------
провоцируем неудовлетворенных провокаторов с удовольствием.
|
|
|
|
|
Jul 4 2014, 20:25
|
Частый гость
 
Группа: Свой
Сообщений: 76
Регистрация: 8-04-11
Из: Ростов-на-Дону
Пользователь №: 64 227

|
Цитата(krux @ Jul 4 2014, 23:54)  можно узнать причину, из-за которой вы жестко завязаны на использование шины Avalon_ST между своими собственными блоками? что мешает завернуть всю свою логику в один qsys-компонент? У меня, как Maverick и предположил, есть набор корок без Avalon ST + своя логика. Жёсткой привязки к интерфейсу между собственными блоками нет, но всё же хочу раздробить свой проект на отдельные модули со связью по стандартизованной шине, ибо проще отлаживать и вносить изменения в структуру. Пока что мне видится наиболее простым реализовать свой параметризуемый модуль на основе dc памяти (ну или допилить dcfifo ядро FIFO корки).
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|