zombi 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба В изделии есть некая плис с SDRAM или DDRx. Нужно организовать экранный буфер во внешней памяти. Понятно что частота работы памяти должна в N раз превышать пиксельную частоту необходимого видео режима. Тогда используя burst можно "быстренько" прочитать во внутренние регистры плис N пикселей и затем выдавать их на цап на нужной пиксельной частоте. А оставшееся время использовать для записи в экранную область новых данных. И все вроде бы хорошо, но поскольку запись (как и чтение) производится пачками по N пикселей, то записывать получится только начиная с адреса кратного burstу. Как сделать так что-бы писать в экранную область можно было теми же пачками но начиная с любого адреса? Может я не совсем ясно выразился, может не понимаю как это все должно реализовываться... Заранее благодарен за советы. Ув. модераторы, если не совсем та ветка форума для такого вопроса, то перенесите куда надо. Про то что буферов должно быть два и как избежать необходимости регенерации писать не надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 41 minutes ago, zombi said: то записывать получится только начиная с адреса кратного burstу Я с AXI работаю недавно и могу ошибаться, но начало записи вроде можно производить в любой начальный адрес. А вот количество пачек и вправду должно быть кратно некой величине. Вам ничего не мешает вычитать, потом поменять на нужный адресс и начать запись/чтение заново Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
warrior-2001 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба Ну если кратко - читайте и пишите пачками. Адрес все равно выравнивать необходимо будет! А что именно выдавать на "ЦАП", тоесть начиная с какого байта - должен будет определять алгоритм на вашей стороне! Ну либо читайте не словами, а байтами. Чтение внешней памяти всегда будет по выравненным адресам и пачками. А ваша задача - в обвязке уже сдвигать данные так, чтобы на выход они шли начиная с нужного байта. Способов сдвига много. 2 минуты назад, Nick_K сказал: Я с AXI работаю недавно и могу ошибаться, AMBA AXI 3/4 конечно, как интерконнект, поддерживает невыровненные транзакции. А вот слейв в виде памяти - нет! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 3 minutes ago, warrior-2001 said: AMBA AXI 3/4 конечно, как интерконнект, поддерживает невыровненные транзакции. А вот слейв в виде памяти - нет! Вы говорите про обычную передачу или Burst? Опять же, даже в память ничего не мешает передавать пакет добитый нулями, просто в нужный момент выключать WSTRB. Или в чём сложность?) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zombi 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 36 minutes ago, Nick_K said: Опять же, даже в память ничего не мешает передавать пакет добитый нулями, просто в нужный момент выключать WSTRB. Как я понял WSTRB это что-то типа маски (как у памяти сигнал DQM) ? Но в таком случае для записи одной пачки равной бурсту но не выровненной по адресу бурста необходимо будет выполнить две полные, равные бурсту, транзакции но с разными масками. Это же потеря в скорости записи в два раза! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 44 minutes ago, zombi said: Но в таком случае для записи одной пачки равной бурсту но не выровненной по адресу бурста необходимо будет выполнить две полные, равные бурсту, транзакции но с разными масками. Я честно слабо представляю Вашу архитектуру, но что мешает складывать данные в два буффера параллельно? Или разделить сигналы разрешения записи. Тогда достаточно выровнять на уровне адрессного слова и асинхронно выставлять для разных буферов. Опять же - маска то не глобальная, а для текущего слова WDATA. И AXI позволяет манипулировать этим значением как угодно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zombi 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 28 minutes ago, Nick_K said: Я честно слабо представляю Вашу архитектуру Сейчас есть изделие в двух вариантах. Бюджетный с MAXII и SRAM. И более дорогой с MAX10 и SRAM. В обоих случаях SRAM одинаковая со временем доступа 8 нс. VGA режим 800x600@60Hz. Глубина цвета 16 бит (565-RGB). Пикс. частота 40MHz. На плис поступает частота 120MHz. На первом такте плис читает цвет пикселя из SRAM и параллельно новое значение пикселя извне в формате 22 бита (6565-ARGB). На втором такте читает пиксель для вывода на экран и параллельно умножает прочитанное в первом такте из SRAM на обратное значение A и новое значение цвета на A и складывает. На третьем записывает результат умножений и сложения по тому адресу откуда читались данные на первом такте. В результате получается писать новые данные в видео буфер со скоростью 40MHz да еще и с учётом альфа-канала. Можно ли такое сделать на одной плис и одной мс SDRAM (DDRx)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба Приветствую! 15 minutes ago, zombi said: ... Глубина цвета 16 бит (565-RGB). Пикс. частота 40MHz. У вас сейчас получается полоса памяти равна 160 MB/s, То есть можно ее заменить любой DDRx c пиковой полосой >200 MB/s НО если в вашем алгоритме доступ к памяти близок к линейному. Если это не так (рандомный доступ) то увы, так просто все не получится. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zombi 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 9 minutes ago, RobFPGA said: У вас сейчас получается полоса памяти равна 160 MB/s, А почему 160? Ведь за секунду происходит 80 MT чтение и 40 MT запись. 1T=2 байта. получается 240 MB/s не? 14 minutes ago, RobFPGA said: НО если в вашем алгоритме доступ к памяти близок к линейному Пишу прямоугольниками с произвольными XY Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба Приветствую! 2 minutes ago, zombi said: А почему 160? Ведь за секунду происходит 80 MT чтение и 40 MT запись. Не заметил что 2 раза чтение делается - тогда да всего получается полоса 240 MB/s Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quato_a 3 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 5 hours ago, zombi said: Можно ли такое сделать на одной плис и одной мс SDRAM (DDRx)? Без проблем можно. Вам нужна DDRx со скоростью обращения не менее в 2 раза больше скорости передачи видеопотока, а лучше побольше с запасом (потеря времени на рукопожатия при новые транзакциях). Обращайтесь к памяти (запись и чтение) пачками построчно. Пример: для буферизации (записи и чтения) двух видеопотоков (24-бит 1920х1080х60fps 148.5 МГц и 16-бит 640x480x60fps 25.175 МГц) хватило c запасом памяти DDR3-1066 2 мк/сх с общей шиной данных 32-бит. Т.е. за одну циклограмму происходит последовательно запись двух линий и чтение двух линий. Используется burst8. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pavlovconst 2 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 5 hours ago, zombi said: Пишу прямоугольниками с произвольными XY В худшем случае все равно нужно уметь раз за разом вычитывать буфер целиком. Так зачем усложнять алгоритм попытками читать частями? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zombi 0 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 31 minutes ago, quato_a said: Пример: для буферизации (записи и чтения) двух видеопотоков причём здесь буферизация? нет у меня входных потоков. 22 minutes ago, pavlovconst said: В худшем случае все равно нужно уметь раз за разом вычитывать буфер целиком. Так зачем усложнять алгоритм попытками читать частями? ну вот ничего не понял. что за худший случай? чего не усложнять? Кадровый буфер Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pavlovconst 2 16 октября, 2019 Опубликовано 16 октября, 2019 (изменено) · Жалоба 17 minutes ago, zombi said: чего не усложнять? Чем больше площадь прямоугольников, тем большая полоса памяти нужна для чтения-записи (если оставить в стороне особенности использования берст-режимов). Самый худший случай, с самыми высокими требованиями к полосе памяти - это когда размер прямоугольников будет равен размеру экранного буфера. Такой случай может и маловероятен, но, наверняка, возможен. И память должна такую полосу обеспечивать. Я предлагаю на таком режиме и остановиться, раз его в любом случае нужно будет поддержать. Возможно, при вычитке только части экранного буфера - вы сэкономите "несколько" тактов.Но этот выигрыш будет различным от кадра к кадру. Алгоритм усложнится, количество ресрсов ПЛИС , занятых под задачу, увеличится. А преимущества чтения буфера по частям какие? Я не понимаю. Поэтому и предложил не усложнять =) Изменено 16 октября, 2019 пользователем pavlovconst Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quato_a 3 16 октября, 2019 Опубликовано 16 октября, 2019 · Жалоба 15 minutes ago, zombi said: причём здесь буферизация? нет у меня входных потоков. Кадровый буфер сами же пишите про экранный буфер. тогда что под этим подразумевается? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
