Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Работа с Avalon ST
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
R6L-025
Доброго времени суток! Какое-то время назад столкнулся со следующим вопросом, который перманентно пытаюсь решить. Пусть имеем некоторый блок, на входе и выходе которого стоят буферы FIFO с шиной Avalon ST, а между ними куча регистровой логики (например конвееризированные умножители, без обратной связи, т.е. сигналов ready) задерживающей поток на несколько десятков тактов. Сам вопрос - как в этом случае корректно реализовать работу с шиной Avalon ST? Ведь при опускании in_ready выходного FIFO данные продолжат литься, даже если завершить передачу потока в регистровую логику.

У меня получилось два довольно кривых решения:

1. Размер выходного буфера выбрать большим, чем максимальная задержка внутри блока, и при опускании сигнала out_ready выходного буфера опускать сигналы in_valid и out_ready во входном буфере, тем самым обрывать входной поток, и собирать в это время выходным FIFO данные выходящие из регистров. (см рис.).
2. Ещё более некрасивый - использовать сигнал out_ready как сигнал clk_en для регистров, хотя, как я понимаю, это самый злобный способ, грозящий нестабильностью системы.

Кто как решает подобные задачи?

Думаю есть готовые реализациии в Altera-ских Qsys корках, но пока не натыкался ни на что подходящее под этот случай.
Maverick
Цитата(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. Если в пакете имеется служебная информация, то тоже делаем мультиплексирование (чтобы не "засорять" блочную память) в нужные моменты времени.
krux
работайте с Ready Latency=0, это самый простой и надежный вариант. для согласования с другими стандартными альтеровскими корками используйте соответствующие Qsys-"переходники".

любые другие варианты с Ready Latency>0 действительно требуют либо FIFO-шек, либо буферной логики на N тактов по входу.
R6L-025
Цитата(krux @ Jul 4 2014, 23:21) *
работайте с Ready Latency=0, это самый простой и надежный вариант. для согласования с другими стандартными альтеровскими корками используйте соответствующие Qsys-"переходники".

любые другие варианты с Ready Latency>0 действительно требуют либо FIFO-шек, либо буферной логики на N тактов по входу.


да оно-то понятно, что самый простой вариант, но не всегда получается. А когда задержка довольно большая, Qsys-ский timing adapter на хочет с ней работать (если, конечно, его вручную не править).
doom13
Цитата(R6L-025 @ Jul 4 2014, 21:31) *

Реализуйте свою регистровую логику с входным/выходным Avalon-ST и соединяйте все блоки последовательно.
krux
можно узнать причину, из-за которой вы жестко завязаны на использование шины Avalon_ST между своими собственными блоками?
что мешает завернуть всю свою логику в один qsys-компонент?
Maverick
Цитата(krux @ Jul 4 2014, 22:54) *
можно узнать причину, из-за которой вы жестко завязаны на использование шины Avalon_ST между своими собственными блоками?
что мешает завернуть всю свою логику в один qsys-компонент?

может у R6L-025 идет своя логика потом IP core с Avalon_ST, потом опять своя логика ...
PS тем более в реализации Avalon_ST не сложен и я сообщением выше описал возможный вариант реализации...
krux
Цитата(Maverick @ Jul 4 2014, 23:57) *
в реализации Avalon_ST не сложен и я сообщением выше описал возможный вариант реализации...

при подключении к чужим коркам - требуется проверять свои при помощи BFM.
Тогда не нужно будет править Qsys-ский timing adapter который
Цитата
не хочет с ней работать (если, конечно, его вручную не править).


всё таки спецификация достаточно строгая, и соответствовать ей тоже нужно полностью
Maverick
Цитата(krux @ Jul 4 2014, 23:02) *
при подключении к чужим коркам - требуется проверять свои при помощи BFM.

можно подробнее на этом месте wink.gif
R6L-025
Цитата(krux @ Jul 4 2014, 23:54) *
можно узнать причину, из-за которой вы жестко завязаны на использование шины Avalon_ST между своими собственными блоками?
что мешает завернуть всю свою логику в один qsys-компонент?

У меня, как Maverick и предположил, есть набор корок без Avalon ST + своя логика. Жёсткой привязки к интерфейсу между собственными блоками нет, но всё же хочу раздробить свой проект на отдельные модули со связью по стандартизованной шине, ибо проще отлаживать и вносить изменения в структуру. Пока что мне видится наиболее простым реализовать свой параметризуемый модуль на основе dc памяти (ну или допилить dcfifo ядро FIFO корки).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.