Aleksei_Rostov
-
Постов
313 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Aleksei_Rostov
-
-
Нет, во время Вы не можете, только по прошествии — я же сразу сказал, что входной кадр сперва надо разобрать, а выходной затем собрать, потому что все синхросигналы по определению не совместимы, Вы не можете непосредственно использовать ни один входной сигнал в качестве выходного.
Также, всё в том же одном абзаце чуть выше я показал, что здесь достаточно всего двух буферов, на 640 точек каждый, входной и выходной соответственно, и рассказал, в какой момент они должны меняться местами.
Собираемый выходной кадр необходимо хранить во внешней памяти, а у меня условие использовать только внутренние ресурсы ПЛИС.
-
Суммируете входную точку с буфером, если это чётная строка, либо с нулём, если нечётная, и записываете сумму в тот же буфер, суммируете следующую точку с этим же буфером и записываете сумму в него же, увеличиваете указатель буфера, по окончании работы входного и выходного буферов, т.е. по началу обоих строчных интервалов гашения, меняете буферы местами.
Приходит кадр из 720 строк, за длительность кадра необходимо выдать подряд 360 строк. Причем 360-ую строку буду формировать во время прихода 719 и 720. То есть в любом случае необходимо копить линии, т.к. нельзя выдать одну линию, следующую не выдавать (сигналы hsync и valid бланкированы).
VESA стандарт pdf
-
Берем 4 буфера:
buff0 - на пол строки.
buff1 - на пол строки.
buff2 - на 1 пиксель. (Фактически обычный регистр с сигналом разрешения)
buff3 - на 1 пиксель. (Фактически обычный регистр с сигналом разрешения)
Начинаем писать видеоданные первой строки:
В buff0 - пишем нечетные пиксели.
В Buff1 - пишем четные пиксели.
В итоге мы имеем всю строку записанную в буфер.
Когда пошла вторая строка - опять записываем сначала четные пиксели но уже в buff2 , и нечетные пиксели в buff3.
Как только у вас будут записаны данные в buff3 вы фактически получили 4 пикселя в буфферах из которых можно будет рассчитать банальным усреднением новый пиксель.
Выглядит это так (цифра- номер буфера куда пишутся пиксели):
-- | | Верхняя строка: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 -- | | Нижнняя строка: 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3
Соответственно у вас по горизонтали и по вертикали картинка будет в 2 раза меньше.
Сигнал valid в HDMI в течении линии будет прерываться, если я правильно понял. То есть записали в buf3 данные рассчитали первый выходной пиксель, как сумму четного, нечетного пикселя 1-ой и 2-ой строки, деленную на 4. Ждем пока запишется в buf3 четный пиксель второй строки, рассчитываем второй выходной пиксель. Когда ожидаем в сигнале valid разрыв. Кадр не отобразится на мониторе.
-
Вот почему никто не указывает остальные параметры входного сигнала?
остальные параметры из VESA стандарта
// Pixel Clock 74.25 MHz
// Pixel Time 13.468 ns
// Active Pixels 921,600 total
// 8-bit Memory 7,200 Kbits
// 32-bit Memory 28,800 Kbits
// Data Rate 1.78 Gbps
// Horizontal Timings
// Active Pixels 1280
// Front Porch 72
// Sync Width 80
// Back Porch 216
// Blanking Total 368
// Total Pixels 1648
// Sync Polarity pos
// Vertical Timings
// Active Pixels 720
// Front Porch 3
// Sync Width 5
// Back Porch 22
// Blanking Total 30
// Total Pixels 750
// Sync Polarity pos
А никто вам не предлагал ничего бланкировать в синхре.
На две пришедшие строчные должна выйти одна строчная.
Вывод это я для себя сделал)
Если на две пришедшие выходит одна, то бланкирование через линию неизбежно при уменьшении в два раза, в этом случае монитор кадры не воспринимает.
-
Надо усреднять 2х2 точки, разбирать входной кадр и синхронизироваться с ним вышеописанным способом, потому что интервалы гашения имеют право быть произвольными. Соответственно, для усреднения достаточно буфера на одну строку длиной 640 точек и чередования, но размер FIFO будет определяться качеством синхронизации.
Данное усреднение или прореживание актуально только по горизонтальной развертке, тогда действительно пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой? Просто бланкировать каждую вторую линию для получения 360-ти линий не получится: зона active pixels должна быть без пропусков.
-
Прореживание дает уж больно некрасивый результат. Примените тогда уж алгоритм ближайшего соседа...
А если не сложно то скажите с какими параметрами идет выходной сигнал ?
Частота Pixel_clk как я понимаю соответствует входному разрешению. А полярность кадрового и строчного импульса, их длительность чему должны соответствовать ?
У меня задача попроще чем у ТС. Входной поток 1280х720 60 Гц (74.25 МГц пиксельклок). Необходимо масштабировать с коэффициентом равным 2, т.е. получить 640х360 разрешение. При этом алгоритм использует только внутреннюю память ПЛИС, т.е. места для хранения всего кадра нет.
Решение вижу следующее:
1. Генерировать пиксельклок ниже чем 74.25 (при этом как прочитал выше значение частоты выбирается согласно стандарта VESA), использовать буферизацию только по одной линии и расставлять согласно стандарта vsync, hsync со своими back\front porch'ами и длительностями. При этом в буфер записывать каждый второй пиксель.
Кто нибудь реализовывал аналогичным способом или есть другой вариант?
Если без внешней памяти, то нужна внутренняя память на как минимум на 4*640 точек (может две таких для буферизации двойной)Тогда 800*5 валидных клоков надо заменить на 640*4. Т.е. на каждые 25 входящих выдать 16 наружу.
Собрал свой источник видеосигнала 1280х720 60 Гц, уменьшал зону active pixel в несколько раз, монитор кадры отображает. Если в зоне active pixel бланкировать через линию и в линии через пиксель (для масштабирования на 2), то монитор не отображает видео кадр. Отсюда вывод: зона active pixel должна быть без разрывов.
-
Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (front porch, back porch) допускается менять в определенных пределах. Разумеется pixel clock при этом тоже плавает. Но на параметры изображения это не должно влиять, разрешение и частота кадра остаются постоянными (частота строк может при этом совпадать, а может и нет).
Я делал вывод изображения на промышленную матрицу, в спецификации на нее было указаны разрешенные диапазоны для всех этих porch-ей. Например, Vertical front porch: min = 7, recomended = 51, max = 100. Правда, horizontal back porch и vertictal back porch по спецификации менять не разрешалось, они были заданы строго.
А по задаче, самое универсальное решение это буфер на весь кадр в DDR-памяти.
Решаю аналогичную задачу, только интерфейс HDMI. Действительно porch можно менять в определенных пределах. Масштабирование получилось только если выдавать синхросигналы все на своих местах (кроме datavalid), изменять только datavalid сигнал, причем сначала необходимо выдавать все активные пиксели.
Возьмите картинку 800x600 отскалируйте её до 640x480 и выведите в левом верхнем углу экрана 800х600.Можно поподробней про "отскалируйте". Как я понимаю делаем следующее: прореживаем каждую линию видео кадра, буферизируем полученный масштабированный кадр и выдаем его на экран 800х600. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок?
-
Это сигнал на разъеме, по которому хост определяет подключение. Если он просто притянут к +5V, то нужно быть готовым выдать EDID в любой момент, что с I2C-слейвом на ПЛИС может быть затруднительно.
Большое спасибо! Сегодня только рассуждали, как видеокарта определяет наличие монитора. Данные сигналы заведены в ПЛИС на hdmi mojo shield
-
Тогда нужно в обязательном порядке предусматривать управление сигналом HPD, в противном случае
хост не сможет считать EDID, пока FPGA не загружена.
HPD это сигнал для микросхемы типа ADV7513, мне на вход ПЛИС TMDS сигналы и i2c приходят на прямую.
-
1. С какой FPGA вы работаете ?
2. Как согласовали FPGA с CML (физ. уровень TMDS) ?
3. Как происходит синхронизация с источником сигнала ? Т.е как определяете середину бита и находите первый бит в посылке ?
1. Работаю со Spartan 6.
2. LVDS буфер (вообще использую готовую приставку HDMI https://embeddedmicro.com/products/hdmi-shield)
3. Для синхронизации во входных сериализованных данных вылавливаю Video Guardband (два пикселя длительноситью)
Да. Погуглите эту тему, z давно не работал уже с HDMI. EDID можно прочитать с монитора.Замкнул i2c монитора и видеокарты, побежал клок и сигналы с карты. Rom для EDID с i2c слейвом придется все равно реализовывать.
На гитхабе есть вот такой проект
https://github.com/tmatsuya/i2c_edid/blob/m.../rtl/i2c_edid.v
-
Ваш HDMI-приемник должен содержать EEPROM (или эмулятор) с корректной информацией EDID. В противном случае карта ничего выдавать и не станет.
То есть помимо TMDS с десериализатором в приемнике должен быть реализован I2C слейв, через который видеокарта вычитывает информацию о мониторе? После этого карта генерирует соответствующий пиксельклок и параллельные видеоданные.
-
EDID у вас правильно прописан?
Можно поподробней? Речь идет о параметрах монитора, настраиваемых в ПК или самом мониторе?
-
Добрый день! Поделитесь опытом, кто работал с hdmi на ПЛИС.
Сделал свой HDMI передатчик на 720p 74.25 MHz. Подключаю к монитору, наблюдаю кадры, которые формирую с заданным разрешением.
Сделал свой HDMI приемник на 720p 74.25 MHz. На вход подключил выход своего передатчика. Chipscope вылавливаю данные, которые отправляю.
Подаю на вход приемника выход видеокарты компьютера, при этом разрешение экрана задаю 720p. Выловить данные не могу (даже пиксельклока нет).
Вопрос: видеокарта генерирует пиксельклок постоянной частоты (максимальной), независимо от выставляемого разрешения экрана?
В качестве источника видеосигнала могу использовать HDMI transmiter с MAX 10 Development kit. HDMI выполнен на микросхеме ADV7513. Кто нибудь запускал данную микросхему? Генерирую видеоданные параллельной шиной (hsync, vsync, de, rgb[23:0]) но видео сигнала на выходе HDMI нет.
Там еще I2C интерфейс для конфигурирования контрольных регистров. Может есть у кого готовый паттерн по I2C для запуска микросхемы? Интересует 480p или 720p для RGB.
-
Через год сын будет поступать, какой ВУЗ посоветуете по этому направлению? Вообще стоит на этом направлении учиться или лучше сменить приоритет в сторону экономики пока не поздно?
Жизненный опыт собственный и опыт друзей\знакомых показал, что учишься по одной специальности, а работаешь все равно по другой. Если у парня склонность к математике, технике, воображение развито, то только вперед! Не понравится, всегда можно перестроиться позже к тому, что более нравится (экономика, финансы и тд). А в плане востребованности специалистов переживать не стоит: люди с руками и головой нужны всегда! Если человек специалист в одной области (экономика, радиотехника, математика) и плюс программист, то точно без хлеба не останется.
-
никогда не шил mojo через родной jtag стоковым Platform Cable USB II за неимением последнего.
гружу питон-скриптом отсюда: https://electronix.ru/forum/index.php?showtopic=138102
ЗЫЖ кмк, она изначально была заточена, чтобы без IMPACT и родного шнурка работать (за что и рекомендована к покупке).
Chipscope тоже через питон работает?
-
Переход Done из нуля в единицу говорит о том, что конфигурация закончена.
стр. 25
https://www.xilinx.com/support/documentatio...uides/ug380.pdf
Листаю этот же документ. Проблема в том, что в единицу не возвращается.
Прошиться получилось! В чем причина так и не понял. Возможно где то присутствовал плохой контакт.
-
Проверьте питания ядра и банков ввода вывода в статическом режиме, а потом посмотрите как оно ведет себя при загрузки ПЛИС,
Питание на месте и при загрузке не меняет своего значения (в том числе и питание второго банка, на котором находится пин DONE). Во время прошивки пин переходит в состояние логического нуля из единицы. Пин DONE bidirectional, внешних устройств, влияющих на него по идее нет. Пин выведен через транзистор на светодиоид.
Пытаюсь разобраться не держит ли микроконтроллер на плате данный пин .
-
Снижать скорость JTAG. Смотреть качество сигналов, в частности клока (TCK). Еще Done по каким-либо причинам может быть притянут к земле, тогда эффект будет тот же (но это не точно, не помню наизусть какова там процедура старта у спартана)
Скорость снижал, Done параллельно заведен на светодиод, к земле не притянут (на плате есть возможность сконфигурировать через Atmega контроллер, при данном способе конфигурации сигнал Done срабатывает), качество клока не смотрел, т.к. device ID, device Signature через impact читаются. Настройки в Generate programming File САПР менял на Done high, unused pins pull up, clock JTAG clock и тд. Без результатов.
-
Добрый день! Подскажите пожалуйста, кто какие решения применял для прошивки .bit в Spartan 6 через IMPACT + Platform Cable USB II при возникновении ошибки
'1': Programming terminated. DONE did not go high.
Полный лог IMPACT
PROGRESS_START - Starting Operation. Maximum TCK operating frequency for this device chain: 25000000. Validating chain... Boundary-scan chain validated successfully. '1': Programming device... LCK_cycle = NoWait. LCK cycle: NoWait done. '1': Reading status register contents... [0] CRC ERROR : 0 [1] IDCODE ERROR : 0 [2] DCM LOCK STATUS : 0 [3] GTS_CFG_B STATUS : 0 [4] GWE STATUS : 0 [5] GHIGH STATUS : 0 [6] DECRYPTION ERROR : 0 [7] DECRYPTOR ENABLE : 0 [8] HSWAPEN PIN : 0 [9] MODE PIN M[0] : 0 [10] MODE PIN M[1] : 0 [11] RESERVED : 0 [12] INIT_B PIN : 0 [13] DONE PIN : 0 [14] SUSPEND STATUS : 0 [15] FALLBACK STATUS : 0 INFO:iMPACT:2219 - Status register values: INFO:iMPACT - 0000 0000 0000 0000 INFO:iMPACT:579 - '1': Completed downloading bit file to device. INFO:iMPACT:188 - '1': Programming completed successfully. LCK_cycle = NoWait. LCK cycle: NoWait INFO:iMPACT - '1': Checking done pin....done. '1': Programming terminated. DONE did not go high. PROGRESS_END - End Operation. Elapsed time = 2 sec.
Отладочная плата Mojo Spartan 6
https://embeddedmicro.com/products/mojo-v3
При этом Get deviceID и Get device Signature выполняются без проблем.
-
"Достижимо" каким путём? Путём превращения человека в компьютерного гика-красноглазика, в придаток компьютера, который сутками проводит за компом, а досуг в выходные у которого заключается в чтении даташитов и изучении очередной железяки или софтины? И так годами?
На мой взгляд каждый специалист проходит подобный путь. В диалектике определен только такой путь перехода количественного в качественное, другими словами, заложить фундамент на профессиональное будущее. А вот потом начинается самое интересное: применение накопленных знаний для самореализации.
-
Приветствую!
Если Вы в скрипте делаете add_files ... а не import_files ... то исходники остаются там где и были и не переносятся в project_1.src. В проекте в таком случае будут линки на project_1/verilog/file...
Удачи! Rob.
Спасибо! уже догадался: команды из GUI для tcl, когда импортируем файлы без копирования!
-
Папка project_1/project_1.src управляется средой, поэтому при создании проекта из скрипта перезаписывается. Исходники можно перенести в другую папку, при создании файла write_prj.tcl будут ссылки на файлы в ней, руками править не нужно.
Хорошо, перенес я например исходники в папку project_1/verilog, в скрипте указал, что исходники находятся в данной папке, после запуска скрипта получил проект со скопированными исходниками в папке project_1.src. В процессе работы начинаются правки исходников в папке project_1.src. Делаю commit текущих исходников, в репозитории они сохранятся в project_1/project_1.src. Потом при клонировании репозитория необходимо будет опять переносить исходники в папку project_1/verilog, запускать скрипт для создания проекта.
Можно ли обойтись без данных манипуляций с переносом в папку project_1/verilog?
-
Так а в чем проблема? Файл D:/example_1v/project_1/project_1.srcs действительно уже есть на диске, и попытка его перезаписи приводит к ошибке? Ну так удаляйте его каждый раз прямо в теле скрипта
rm -f D:/example_1v/project_1/project_1.srcs
Хотелось бы:
1. Получить из репозитория в локальную папку example_1v файлы : project_1/project_1.src/... и write_prj.tcl.
2. Запустить write_prj.tcl и получить готовый проект в каталоге project_1 со всеми остальными папками .src, .sim и т.д., и подхваченными исходниками без лишних манипуляций с файлами исходниками.
По первому пункту вопросов нет, по второму - требуются дополнительные манипуляции с файлами исходниками в tcl файле и локальной папке example_1v.
-
Использую tcl в системе контроля версий для сборки проекта из исходников репозитория, скопированных в локальную папку.
В локальную папку из репозитория залил write_project.tcl файл, полученный из vivado, и набор исходников в папке .../project_1/project_1.src/source_1/new/
Запуск tcl скрипта должен привести к сборке проекта с исходниками в папке project_1/project_1.src/source_1/new/
Но после запуска появляется ошибка
ERROR: [Common 17-53] User Exception: Project already exists on disk, please use '-force' option to overwrite: D:/example_1v/project_1/project_1.srcsесли добавлю -force, то папка project_1/project_1.src/source_1/new/ с исходниками удаляется.
В скрипте добавление файлов прописано
# Set 'sources_1' fileset object set obj [get_filesets sources_1] set files [list \ "[file normalize "$origin_dir/project_1/project_1.srcs/sources_1/new/BRAM_Memory_24x24.v"]"\ "[file normalize "$origin_dir/project_1/project_1.srcs/sources_1/new/kernel_3x3.v"]"\ ] add_files -norecurse -fileset $obj $files
Если исходники вынесу по адресу $origin_dir/project_1.srcs/sources_1/new/ , т.е. за пределы папки project_1 и отредактирую пути в скрипте, то новым проектом файлы подхватываются, но каталог project_1.srcs будет находится за пределами папки project_1.
Как отредактировать tcl файл, чтобы происходила сборка проекта в требуемом каталоге с исходниками на своих местах?
tcl файл прилагаю.
Синхронизация вывода видео на VGA монитор
в Работаем с ПЛИС, области применения, выбор
Опубликовано · Пожаловаться