Вчера вечером наконец-то собрал плату — в общей сложности ушло часов 5 на обе стороны. Причём, что интересно, бОльшая часть времени ушла на крупные компоненты, а вот мелочь 0402 я накидал очень быстро — и всё благодаря вот этому инструменту! Фишка в том, что он сам "отпускает" деталь после того, как она коснётся платы — а потому процесс установки идёт быстро — настолько быстро, что обратную сторону я целиком сделал меньше, чем за час (при том, что там около 50 деталей, и подавляющее большинство 0402)! Стоит эту штука, конечно, немало (вместе с набором насадок для мелких деталей мне обошлась в $493 + $78.95 shipping & handling + ещё почти сотка на НСП, brokerage и прочая трансграничная бюрократия), потому рекомендовать новичкам её не буду, но всем, кто решил заняться электроникой всерьёз, однозначно советую инвестировать в неё — она съэкономит огромное количество времени! Так же использовал стереомикроскоп — он обошёлся в $200 + $60 экспресс-доставка — хотя если деньги поджимают, стоит купить комплект с только двумя парами окуляров на 10х и 20х (мой комплект с четырьмя парами — 5х, 10х, 15х и 20х). Вот его точно стоит купить каждому — паять под ним сплошное удовольствие, да и для инспекции пайки 20х вполне достаточно.
Использовал обычную свинцовую пасту, сначала сделал обратную сторону, потом — лицевую. При пайке лицевой стороны с оборота ничего не отвалилось — даже крупные кондёры остались на месте.
При пайке выявился косяк — оказывается, разъём JTAG не является термостойким, а потому он в процессе некисло оплавился (см. фотку, там он уже обрезанный и "облагороженный" ), но я отрезал лишнее, и программатор всё равно нормально подключается. Урок на будущее — читать внимательнее раздел пайки в даташите
В этой ревизии я не стал распаивать компоненты блока питания, а вместо этого использовал точно такой же, но внешний (я использовал его для подбора компонентов, чтобы выдавал нужные напряжения). Сделал это для экономии компонентов, если вдруг что-то пойдёт не так — зная себя, вероятность того, что где-то будет косяк, была довольно велика Но не в этот раз Разъём для такого подключения я предусмотрел во второй ревизии платы, также исправил целую кучу косяков первой ревизии — кривой футпринт чипов памяти и флеша, выбрал неправильный пин ПЛИСа для входного тактового сигнала , неправильное подключение кнопок , добавил забытый сервисный разъём для блока питания, также забытые подтягивающие резисторы для шины I2C этого разъёма, добавил кнопку сброса чипа питания, ну и ещё по мелочи. Хорошо, что все эти косяки я нашёл ещё до того, как начал собирать плату — а потому напрасно потратил только деньги на изготовление плат В очередной раз убеждаюсь в справедливости совета сначала собирать и "отрабатывать" субмодули платы отдельно — так дешевле выйдет, несмотря на то, что придётся заказывать отдельные платы под субмодули.
Общая цена распаяных компонентов — около $100. Прикидка очень грубая, т.к. бОльшую часть деталей я использовал из имеющихся запасов, приобретённых ранее для других проектов, а разъёмы слева мне достались нахаляву (производитель прислал бесплатные сэмплы). Ну и сами платы вместе с трафаретом для обоих сторон и доставкой обошлись в $108: заказал 10 штук, прислали 11, размер платы 92х80 мм, 4 слоя, техпроцесс 0.15/0.15 мм дорожки и 0.3 мм отверстия, толщина платы 1.2 мм, толщина всех слоёв меди по 0.035 мм (1 Oz), покрытие ENIG (напылённое золото поверх напылённого никеля, паста прилипает к нему намного лучше, чем к HASL — после нанесения пасты через трафарет только в нескольких местах пришлось немного подправить пасту зубочисткой, плюс оно идеально ровное, что важно для BGA).
Пока проверил работу RGB-светодиодов, самой ПЛИСки (опять же для снижения риска распаял самую дешёвую из семейства Artix-7 в корпусе FBGA-256 — XC7A15T-1FTG256C с ~16К логических элементов) и SPI Flash (на фотке нижняя BGAшка справа от ПЛИС, U301). ИДЕшка (недавно обновлённая Xilinx Vivado 2017.2) сходу определила чип, запрограммовала его напрямую, а также запрограммовала чип флеша. Ещё проверил корректрую закрузку ПЛИС напрямую с флешки (использовал предварительно прошитый туда битстрим). Для проверки всего остального надо писать код.
Фотки
Блок питания (в напечатанном на 3D-принтере корпусе):
P.S. Сорри за капс — эмоции через край! Когда плата в первый раз замигала, я так заорал, что соседка прибежала узнать, что тут происходит Хорошо, что она русский мат не понимает Вот ради этих эмоций я всё это и делаю!
P.P.S. Следующая цель (после проверки всех чипов) — разводка и распайка DDR3 Но это уже будет дороже, т.к. шаг шариков у всех чипов памяти DDR3 — 0.8 мм, а потому надо будет использовать существенно более дорогой техпроцесс 0.125/0.125 мм дорожки и 0.25 мм отверстия.
Здравствуйте, Sharov, Вы писали:
S>В чем смысл процесса? Что собираемая железяка делать должна? Помимо того, что "для души" и любопытства ради.
Цели данного проекта такие:
1. Отработать схему подключения ПЛИС (загрузка с флешки, программирование, правильность подключения и верность выбора деталей "обвязки") на относительно дешёвых компонентах, дабы уменьшить финансовый риск в более сложных проектах.
2. Потренироваться разводить относительно сложные многослойные платы так, чтобы их можно было реально произвести — то есть выдержать все допуски, минимальные размеры и прочие производственные ограничения. А также научиться разводить высокоскоростные последовательные (дифференциальные пары) и параллельные (с матчингом длины дорожек) шины с заданным импедансом. То, что называют DFM (Design For Manufacturing). Это моя первая успешная многослойная плата.
3. Попрактиковаться в сборке сложных плат с большим количеством компонентов, а также отработать пайку BGA.
4. Получившаяся плата будет использоваться как девборда для проверки софта на реальном железе. Для этого на плате предусмотрены два высокоскоростных порта расширения для подключения дополнительных модулей. Это позволяет при отработке нового проекта сначала сделать только небольшой дополнительный модуль, и только после проверки и отладки уже разводить весь проект на финальной отдельной плате.
5. На плате установлен чип моста из 8-битной параллельной шины в USB (FTDI FD221XQ) — но нём планирую отработать относительно высокоскоростной ("относительно" потому что только USB 2.0) обмен данными с компьютером, также разберусь с разработкой интерфейсной части со стороны компа.
6. Ну и само собой потренироваться в разработке прошивок для ПЛИС, а также софта под ядра бесплатного софт-процессора Microblaze — он настолько компактный, что даже в этот самый младший чип влезет по крайней мере 4 ядра, а то и больше.
В дальнейшем хочу сделать систему computer vision для pick-and-place машины, систему наложения данных телеметрии на видео в реальном времени для квадрокоптера, а также в более отдалённой перспектике — систему стереоскопического computer vision опять же для квадрокоптера, которая позволила бы ему самостоятельно летать избегая препятствий, а также держать "в фокусе" некоторый подвижный объект (если кто помнит "Терминатор 3" — там было что-то подобное — летающая штука сама поворачивалась за подвижной целью ). В планах есть ещё несколько проектов, но они не будут использовать ПЛИС. Короче, планов полно — где бы только взять столько времени и денег, чтобы всё это сделать
Здравствуйте, koandrew, Вы писали:
K>Вчера вечером наконец-то собрал плату — в общей сложности ушло часов 5 на обе стороны.
Молодез, возьми вакуум пикером пирожок с полки =))) записал сам пикер в список на покупку.
Но что касается микроблейзов и прочей требухи... После того как мне показали как правильно готовить SoC (на примере Cyclone V). За уши ж не оттащишь.
Бут линуха, загрузка FPGA и старт совместной работы... меньше 2 секунд.
Zynq 7020 (parallella) у меня тоже есть, но софт зайлинкса мне нравится еще меньше альтеро-интеловского...
Еще один урок полученный от мудрых людей — делать прототипы проектов надо... на evaluation board! Когда заработало — тогда можно думать о слоях, шарах BGA и прочем. Иначе можно встрять на совершенно ровном месте — типа косяков с EMI на шине памяти и придется с ней работать на частотах в разы меньше необходимых.
Но сам драйв от разработки схемотехники, PCB и потом пайки-налаживания — он, конечно, никуда не девается. Только с точки зрения достижения результата — нерационально.
Пока пришлось SoC тему чуть притормозить, оказалось что под виндой нет нормальных тулов для формирования загрузочных SD карт для embedded linux. Только тупые записывальщики имиджей фиксированного размера с потерей остаточной емкости карты (или танцы с бубном по ресайзу). В качестве payback за науку сижу лабаю тулзу. Здравствуй MBR и прямая запись на физическое устройство в винде, немного WMI и прочий адок, которого не существует в linux =)
...
K>В дальнейшем хочу сделать систему computer vision для pick-and-place машины, систему наложения данных телеметрии на видео в реальном времени для квадрокоптера, а также в более отдалённой перспектике — систему стереоскопического computer vision опять же для квадрокоптера, которая позволила бы ему самостоятельно летать избегая препятствий, а также держать "в фокусе" некоторый подвижный объект (если кто помнит "Терминатор 3" — там было что-то подобное — летающая штука сама поворачивалась за подвижной целью ). В планах есть ещё несколько проектов, но они не будут использовать ПЛИС. Короче, планов полно — где бы только взять столько времени и денег, чтобы всё это сделать
А можно в более ближней перспективе про систему стереоскопического CV? =)
Есть такая же идея замутить недорогой девайс на паре камер. что то типа этого, но сразу в цифре (девайс не только для квадра, например гнать поток по USB в дальнейшем), тоже на ПЛИСе, т.к. хочется паралельной обработки получаемых кадров сразу с двух камер.
Насколько это гемморойно, и что бы посоветовал?
На ПЛИСе опыта нет, жутко пугают всякие верилоги в плане потери времени на изучение.
Посмотрел немного на Microblaze, правильно понимаю, это что то типа виртуалки и под нее можно писать на С?
Здравствуйте, koandrew, Вы писали:
K>Когда плата в первый раз замигала, я так заорал, что соседка прибежала узнать, что тут происходит Хорошо, что она русский мат не понимает Вот ради этих эмоций я всё это и делаю!
Самое сложное теперь придумать какую реальную пользу можно получить с помощью этих навыков.
Железки уже есть на любой вкус и цвет, что-то новое придумать архисложно. Людей, которые могут развести плату -- хватает. Навык не сложный, гением быть не нужно, главное внимательность.
Если знаете как заработать на железках -- то навык изготовления плат не нужен, можно арендовать труд других людей, которые этим годами занимаются.
Здравствуйте, Alf, Вы писали:
Alf>Молодез, возьми вакуум пикером пирожок с полки =))) записал сам пикер в список на покупку.
Если у тебя ещё нет стереомикроскопа, посмотри вот на эти две модели: SE400 или SE410. Они отличаются фокусным расстоянием главных объективов, то есть с практической точки зрения — насколько высоко объектив будет расположен над платой. Какая из них будет тебе удобнее, зависит от твоего роста и того, как ты работаешь. SE400 имеет расстояние около 22 см, SE410 — около 15 см. Мне удобнее оказался второй (сначала я купил SE400, но потом вернул его и поменял на 410). Обе стоят вполне разумных денег.
Alf>Но что касается микроблейзов и прочей требухи... После того как мне показали как правильно готовить SoC (на примере Cyclone V). За уши ж не оттащишь.
Ну про это я в курсе. Просто для многих задач Zynq — это аццкий оверкилл, да ещё и дорогущий. Alf>Бут линуха, загрузка FPGA и старт совместной работы... меньше 2 секунд.
Вот скажи мне — нафига там нужен линукс? Ну помимо because I can
Alf>Zynq 7020 (parallella) у меня тоже есть, но софт зайлинкса мне нравится еще меньше альтеро-интеловского...
Мы вернёмся к этому разговору после того, как АльтерИнтел начнут бесплатно предоставлять хотя бы половину IP, которые бесплатно предоставляет Зайлинкс. Сейчас они даже за DDR3 контроллер денег хотят! А пока для любителей типа меня — только Зайлинкс.
Alf>Еще один урок полученный от мудрых людей — делать прототипы проектов надо... на evaluation board! Когда заработало — тогда можно думать о слоях, шарах BGA и прочем. Иначе можно встрять на совершенно ровном месте — типа косяков с EMI на шине памяти и придется с ней работать на частотах в разы меньше необходимых.
Для того, чтобы их не словить, нужно внимательно читать appnotes от производителей, а не сначала делать, а потом думать.
Alf>Но сам драйв от разработки схемотехники, PCB и потом пайки-налаживания — он, конечно, никуда не девается. Только с точки зрения достижения результата — нерационально.
В хобби процесс часто важнее результата.
Alf>Пока пришлось SoC тему чуть притормозить, оказалось что под виндой нет нормальных тулов для формирования загрузочных SD карт для embedded linux. Только тупые записывальщики имиджей фиксированного размера с потерей остаточной емкости карты (или танцы с бубном по ресайзу). В качестве payback за науку сижу лабаю тулзу. Здравствуй MBR и прямая запись на физическое устройство в винде, немного WMI и прочий адок, которого не существует в linux =)
Моё мнение — за очень редкими исключениями линукс на ПЛИС нафиг не нужен (за пределами "чисто поиграться"), т.к. только напрасно жрёт ресурсы системы и увеличивает латентность. RTOS вполне достаточно для большинства типовых задач, а для того, чтобы выжать максимум производительности и энергоэффективности, нужно писать под голое железо.
Здравствуйте, DTB, Вы писали:
DTB>А можно в более ближней перспективе про систему стереоскопического CV? =)
DTB>Есть такая же идея замутить недорогой девайс на паре камер. что то типа этого, но сразу в цифре (девайс не только для квадра, например гнать поток по USB в дальнейшем), тоже на ПЛИСе, т.к. хочется паралельной обработки получаемых кадров сразу с двух камер.
Это не имеет к CV никакого отношения. CV — это не просто "видение", а ещё и "осознание" того, что видит — то есть когда компьютер может распознать, на что именно он смотрит.
DTB>Насколько это гемморойно, и что бы посоветовал?
В твоём случае это концептуально довольно простая задача. Основная сложность в том, как "пропихнуть" большой поток (3D Full HD — это 1920x1080(разрешение)x 4(глубина цвета)x 2(стерео)x 60(частота кадров) = 995328000 Байт/с ~ 1 Гбайт/с в несжатом виде) в узкий канал (даже USB 3.0 имеет теоретический максимум в 5Гбит/с, более реально рассчитывать на 3-4 Гбит/с).
Потому нужен какой-нить кодировщик. Коммерческие IP с такой функциональностью стоят немалых денег, но зато они в большинстве своём "plug-and-play", то есть их интеграция обычно не представляет особой сложности. А вот с open source'ными ситуация неособо. В принципе, можно запилить какой-нить H.264 кодировщик самостоятельно (насколько я помню, там алгоритм не особенно сложный), но в любом случае это займёт массу времени.
DTB>На ПЛИСе опыта нет, жутко пугают всякие верилоги в плане потери времени на изучение.
Насчёт верилога я бы не особенно переживал — не такой уж он и сложный, главное — уяснить для себя основные концепции языка (параллельность операций, процессы и комбинаторные блоки).
В принципе в ряде случаев можно обойтись совсем без него — используя Vivado HLS (HLS = High Level Synthesis), можно написать свой алгоритм на обычном С/С++ с некоторыми ограничениями (самое существенное — нельзя в динамическое выделение памяти), и этот инструмент сам сгенерирует модуль IP, который потом можно будет встроить в систему. Вечером могу набросать линков на хорошие видеоуроки по этому делу, но они на английском.
DTB>Посмотрел немного на Microblaze, правильно понимаю, это что то типа виртуалки и под нее можно писать на С?
Нет, это такой же "железный" процессор — просто он "создаётся" поверх конфигурируемых базовых элементов. Вообще рекомендую сразу себе уяснить, что разрабатывая под ПЛИС, ты разрабатываешь железо, а не софт. Отсюда и "сила" ПЛИСов — в массивной параллельности, гибкости и универсальности — можно создать любое нужное железо для наиболее быстрого/эффективного выполнения какой-то задачи, и даже менять это самое железо прямо по ходу работы устройства. Вообще термин "программирование" в отношение ПЛИС неверен — более точен используемый производителями термин "конфигурирование".
Здравствуйте, Shmj, Вы писали:
S>Самое сложное теперь придумать какую реальную пользу можно получить с помощью этих навыков.
Ой, а ты здесь как оказался? Посмотри в словаре значение слова "хобби". Оно не про пользу — оно про удовольствие от процесса.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, DTB, Вы писали:
DTB>>А можно в более ближней перспективе про систему стереоскопического CV? =)
DTB>>Есть такая же идея замутить недорогой девайс на паре камер. что то типа этого, но сразу в цифре (девайс не только для квадра, например гнать поток по USB в дальнейшем), тоже на ПЛИСе, т.к. хочется паралельной обработки получаемых кадров сразу с двух камер. K>Это не имеет к CV никакого отношения. CV — это не просто "видение", а ещё и "осознание" того, что видит — то есть когда компьютер может распознать, на что именно он смотрит.
само собой CV будет заниматься более высокоуровневая железка, тут задача одномоментно получить изображение с двух камер с минимальной рассинхронизацией и обеспечить передачу кадров "выше"
DTB>>Насколько это гемморойно, и что бы посоветовал? K>В твоём случае это концептуально довольно простая задача. Основная сложность в том, как "пропихнуть" большой поток (3D Full HD — это 1920x1080(разрешение)x 4(глубина цвета)x 2(стерео)x 60(частота кадров) = 995328000 Байт/с ~ 1 Гбайт/с в несжатом виде) в узкий канал (даже USB 3.0 имеет теоретический максимум в 5Гбит/с, более реально рассчитывать на 3-4 Гбит/с). K>Потому нужен какой-нить кодировщик. Коммерческие IP с такой функциональностью стоят немалых денег, но зато они в большинстве своём "plug-and-play", то есть их интеграция обычно не представляет особой сложности. А вот с open source'ными ситуация неособо. В принципе, можно запилить какой-нить H.264 кодировщик самостоятельно (насколько я помню, там алгоритм не особенно сложный), но в любом случае это займёт массу времени.
про пропускную способность в курсе, тут без вариантов уменьшать изображение, а так же, некоторые сенсоры умеют в JPG, скорость тогда падает, но в принципе на ПЛИС тот же MJPG попроще сделать, чем H.26х
DTB>>На ПЛИСе опыта нет, жутко пугают всякие верилоги в плане потери времени на изучение. K>Насчёт верилога я бы не особенно переживал — не такой уж он и сложный, главное — уяснить для себя основные концепции языка (параллельность операций, процессы и комбинаторные блоки). K>В принципе в ряде случаев можно обойтись совсем без него — используя Vivado HLS (HLS = High Level Synthesis), можно написать свой алгоритм на обычном С/С++ с некоторыми ограничениями (самое существенное — нельзя в динамическое выделение памяти), и этот инструмент сам сгенерирует модуль IP, который потом можно будет встроить в систему. Вечером могу набросать линков на хорошие видеоуроки по этому делу, но они на английском.
присылай, VHLS на первый взгляд смотрится не так грустно.
DTB>>Посмотрел немного на Microblaze, правильно понимаю, это что то типа виртуалки и под нее можно писать на С? K>Нет, это такой же "железный" процессор — просто он "создаётся" поверх конфигурируемых базовых элементов. Вообще рекомендую сразу себе уяснить, что разрабатывая под ПЛИС, ты разрабатываешь железо, а не софт. Отсюда и "сила" ПЛИСов — в массивной параллельности, гибкости и универсальности — можно создать любое нужное железо для наиболее быстрого/эффективного выполнения какой-то задачи, и даже менять это самое железо прямо по ходу работы устройства. Вообще термин "программирование" в отношение ПЛИС неверен — более точен используемый производителями термин "конфигурирование".
я понимаю, что тут несколько другая парадигма, придется вникать.
если брать xilinx, то какой, не шибко дорогой devboard'ы, было бы достаточно для этой задачи? 2 dcmi, возможный mjpg, память (dram, fifo?), usb
Здравствуйте, DTB, Вы писали:
DTB>само собой CV будет заниматься более высокоуровневая железка, тут задача одномоментно получить изображение с двух камер с минимальной рассинхронизацией и обеспечить передачу кадров "выше"
Как раз наоборот — есть очень веская причина, чтобы этим занималась как раз ПЛИСка, сидящая рядом с камерами. Дело в том, что объём информации о распознанных объектах НАМНОГО меньше, чем "сырой" видеопоток.
DTB>про пропускную способность в курсе, тут без вариантов уменьшать изображение, а так же, некоторые сенсоры умеют в JPG, скорость тогда падает, но в принципе на ПЛИС тот же MJPG попроще сделать, чем H.26х
Обрабатывать сжатое с потерями видео — это не очень хорошая идея. Артефакты сжатия часто вылезают в виде ложных срабатываний многих алгоритмов CV.
DTB>присылай, VHLS на первый взгляд смотрится не так грустно.
Вечером скину, на работе у нас труба забанена.
DTB>я понимаю, что тут несколько другая парадигма, придется вникать.
Главное — запомни, что всё в мире ПЛИС выполняется параллельно и одновременно. И не забывай учитывать это при разработке кода. Это спасёт от очень многих багов и проблем.
DTB>если брать xilinx, то какой, не шибко дорогой devboard'ы, было бы достаточно для этой задачи? 2 dcmi, возможный mjpg, память (dram, fifo?), usb
Боюсь, что требования "не шибко дорогой" и "обработка двух FullHD-потоков в реальном времени с минимальной латентностью" не очень совместимы. Я бы тебе посоветовал для начала купить какую-нить дешёвую плату просто затем, чтобы "поиграться" с ней, попрактиковаться прошивать, отлаживать свои проекты на железе, в процессе освоить Vivado IDE. Что-нить типа Arty или Arty-Z7, если хочется поиграться с SoC (плюс на этой плате есть HDMI IN, так что можно немного поиграться с обработкой видео). И уж потом браться за свою задачу.
При разработке под ПЛИС обычно сначала разрабатывают систему, пишут код и проводят симуляции, и уже по итогам симуляции выбирают чип. В процессе синтеза ИДЕ выдаёт отчёт о том, сколько именно каких ресурсов было задействовано, по этому отчёту чип и выбирают (оставляя запас процентов в 15-20 на всякий случай).
Откровенно говоря, я не знаю такой девборды, чтобы на ней искаропки было бы два цифровых входа для камер. Так что скорее всего придётся городить свою плату расширения.
Здравствуйте, DTB, Вы писали:
DTB>присылай, VHLS на первый взгляд смотрится не так грустно.
Как и обещал, вот ссылки.
1) Плейлист туториалов по основам FPGA и Verilog для совсем новичков (разжёвывает всё до предела — остаётся только проглотить): https://www.youtube.com/playlist?list=PLo7bVbJhQ6qxesicBHQwSl4nYOMJO2CHw
2) Целый канал, посвящённый новичкам — в каждом ролике рассматривается отдельная составляющая часть ПЛИСа (LUT, Flip-flop, BRAM и т.п.), тут же на примере демонстрирует её функцию: https://www.youtube.com/channel/UCsdA-aNqtMA1_2T15aXePWw/videos Он там в основном говорит о своей борде, но все описываемые им элементы есть в любом современном FPGA.
3) Обещанный выше курс по HLS: https://www.youtube.com/playlist?list=PLo7bVbJhQ6qzK6ELKCm8H_WEzzcr5YXHC В последних нескольких видео цикла рассматривается реальный пример построения системы обработки изображений. Вообще лично я очень многое узнал из курса.
Ещё советую посмотреть прочие его видео — там очень много интересного по теме. Он в основном пользуется ZedBoard, на борту которой стоит Zynq SoC (это комбинированный чип, где на одном кристалле располагаются два обычных ядра ARM Cortex-A9 с частотой от 750 МГц до 1ГГц, а также фабрика FPGA, такая архитектура позволяет сделать "бесшовное" соединение процов с кастомными блоками, что даёт очень широкие возможности, обычно применяется для создания "акселераторов", когда "тяжёлую" часть алгоритма реализуют на FPGA, а остальное выполняют на обычном процессорном ядре), так что если вдруг захочешь повторить его опыты, купи Arty-Z7-20 — там стоит такой же чип, но сама борда стоит существенно дешевле ZedBoard.
4) Куча видео о Zynq, его устройстве и использовании в формате лекций: https://www.youtube.com/user/EMSUNIKL/videos и https://www.youtube.com/user/mamsadegh2/videos (там выступает один и тот же человек, просто часть роликов опубликовано от имени универа, в котором он работает, а часть лично от него)
5) Ну и как водится, RTFM (сорри, но если хочешь освоиться в мире ПЛИС, то придётся полюбить много читать, т.к. документация по ним имеет тенденцию состоять и десятков огромных документов на сотни страниц каждый) User Guide из комплекта документации к Vivado HLS: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug902-vivado-high-level-synthesis.pdf Там описано ВСЁ, но предупреждаю, что очень многа букав. Ещё один коротенький документ посвящён конкретно OpenCV: https://www.xilinx.com/support/documentation/application_notes/xapp1167.pdf Но он немного устарел, так что рекомендую обращаться к основному гайду.
Для начала думаю тебе хватит. Ну и само собой, если будут какие-то практические вопросы, то задавай тут — чем можем — поможем. Удачи на этом нелёгком пути!
///
K>Для начала думаю тебе хватит. Ну и само собой, если будут какие-то практические вопросы, то задавай тут — чем можем — поможем. Удачи на этом нелёгком пути!
Спасибо! все равно рано или поздно придется попробовать эту "дрянь"
Здравствуйте, koandrew, Вы писали:
K>В дальнейшем хочу сделать систему computer vision для pick-and-place машины, систему наложения данных телеметрии на видео в реальном времени для квадрокоптера, а также в более отдалённой перспектике — систему стереоскопического computer vision опять же для квадрокоптера, которая позволила бы ему самостоятельно летать избегая препятствий, а также держать "в фокусе" некоторый подвижный объект (если кто помнит "Терминатор 3" — там было что-то подобное — летающая штука сама поворачивалась за подвижной целью ). В планах есть ещё несколько проектов, но они не будут использовать ПЛИС. Короче, планов полно — где бы только взять столько времени и денег, чтобы всё это сделать
Кикстартер или делай свой стартап
Здравствуйте, koandrew, Вы писали:
K>Ага — дайте мне 100000$ — я хочу сделать себе мегасистему
Ты можешь попробовать получить деньги на разработку мегасистемы в обмен на публикацию схематики, кода и все элементной базы которую использовал, а также демонстрацию рабочего устройства и гайд для сборки всей системы чтобы каждый потом смог собрать такую же сам. Что-то вроде проекта ReRap.
Здравствуйте, koandrew, Вы писали:
K>Ага — дайте мне 100000$ — я хочу сделать себе мегасистему
не хватит тебе 100к =) Я до сих пор офигеваю с (не)выпуска snickerdoodle. Уже полтора года кота за хвост тянут, никак не могут спаять платы =)
Делать хобби работой — сомнительное удовольствие
Здравствуйте, Kernan, Вы писали:
K>Ты можешь попробовать получить деньги на разработку мегасистемы в обмен на публикацию схематики, кода и все элементной базы которую использовал, а также демонстрацию рабочего устройства и гайд для сборки всей системы чтобы каждый потом смог собрать такую же сам. Что-то вроде проекта ReRap.
Я это и так сделаю
Здравствуйте, Alf, Вы писали:
Alf>не хватит тебе 100к =) Я до сих пор офигеваю с (не)выпуска snickerdoodle. Уже полтора года кота за хвост тянут, никак не могут спаять платы =)
Ну почему же — если заниматься этим в режиме хобби — то можно легко уложиться в эту сумму.
Alf>Делать хобби работой — сомнительное удовольствие
Я уже делал так в прошлом — программирование сначала было моим хобби, а потом стало карьерой.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Kernan, Вы писали:
K>>Ты можешь попробовать получить деньги на разработку мегасистемы в обмен на публикацию схематики, кода и все элементной базы которую использовал, а также демонстрацию рабочего устройства и гайд для сборки всей системы чтобы каждый потом смог собрать такую же сам. Что-то вроде проекта ReRap. K>Я это и так сделаю
Это само собой, но в случае с краудфандингом ты ещё и частично окупишь затраты.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, koandrew, Вы писали:
K>>Ага — дайте мне 100000$ — я хочу сделать себе мегасистему K>Ты можешь попробовать получить деньги на разработку мегасистемы в обмен на публикацию схематики, кода и все элементной базы которую использовал, а также демонстрацию рабочего устройства и гайд для сборки всей системы чтобы каждый потом смог собрать такую же сам. Что-то вроде проекта ReRap.
Если это превратить в обучающий проект это одно. Правда это будет интересно далеко не всем. Иначе я не понимаю, что инновационного в работе ТС? Железяк для CV всего и вся вроде хватает.
K>Ну про это я в курсе. Просто для многих задач Zynq — это аццкий оверкилл, да ещё и дорогущий. K>Вот скажи мне — нафига там нужен линукс? Ну помимо because I can
Zynq хорошо подойдёт там, где вам нужно внешние управление FPGA. Или для больших задач, где на FPGA реализовать решение очень сложно и трудоёмко. Тогда основная программа пишется для ARM процессоров а на ПЛИСах реализовываются Со-процессоры для расспараллеливания задичи. Zynq тем хорош, что имеет скоростную шину между АРМ процессором и ФПГА. Между ними используется AXI4 (part of the ARM AMBA® 3.0 open standard).
K>Моё мнение — за очень редкими исключениями линукс на ПЛИС нафиг не нужен (за пределами "чисто поиграться"), т.к. только напрасно жрёт ресурсы системы и увеличивает латентность. RTOS вполне достаточно для большинства типовых задач, а для того, чтобы выжать максимум производительности и энергоэффективности, нужно писать под голое железо.
Zynq поддерживает не только Линух, есть и RTOS. Вот здесь список всех ОС.
Я пока это дело только изучаю. Я себе вот этот board приобрёл и читаю вот эту книжку. Очень интересно.
Здравствуйте, Iso12, Вы писали:
I>Zynq хорошо подойдёт там, где вам нужно внешние управление FPGA. Или для больших задач, где на FPGA реализовать решение очень сложно и трудоёмко. Тогда основная программа пишется для ARM процессоров а на ПЛИСах реализовываются Со-процессоры для расспараллеливания задичи.
В большинстве случаев Microblaze soft-core вполне достаточно для этих целей. "Железный" процессор нужен либо когда критична латентность, либо когда нужна большая вычислительная мощность под задачи, которые по той или иной причине не реализовали в "железе". Ибо процессорные ядра могут работать на частотах до 1 ГГц (в зависимости от speed grade'а чипа), в то время как Microblaze не разогнать выше 200 МГц (на Artix'ах, на более серьёзных чипах он работает быстрее). I>Zynq тем хорош, что имеет скоростную шину между АРМ процессором и ФПГА. Между ними используется AXI4 (part of the ARM AMBA® 3.0 open standard).
У него внутренняя шина AXI3, которая несколько отличается от AXI4. Кстати Microblaze тоже имеет такую шину, точнее даже две — одна для кода, вторая — для данных.
I>Zynq поддерживает не только Линух, есть и RTOS. Вот здесь список всех ОС.
Я в курсе. А вот ты наверное не в курсе, что и Microblaze поддерживает всё это
I>Я пока это дело только изучаю. Я себе вот этот board приобрёл и читаю вот эту книжку. Очень интересно.
Я бы на твоём месте взял Arty-Z7-20 — она стоит лишь немного больше, чем Зибо, но зато там более мощный чип. Хотя тут, конечно, есть ещё вопрос, какая периферия тебе нужна. Лично для меня не проблема разработать и сделать плату расширения с нужной мне периферией, но допускаю, что кому-то не захочется возиться с этим, и они предпочтут, чтобы всё было искаропки, ну или хотя бы на уже готовых платах расширения.
I>Успехов
Взаимно!
Я планирую как-нить заняться разводкой платы под Zynq, но пока останавливает две вещи — во-первых, недорогие модели поставляются только в корпусах с 0.8 мм шагом шаров (что потребует более тонкий == дорогой техпроцесс 0.125/0.125 мм треки/0.25 мм отверстия или лучше), во-вторых, для полной разводки нужна минимум шестислойная (а то и восьмислойная) плата, которая тоже стоит немалых денег.
Только что проверил работу своего доморощенного контроллера оперативной памяти типа HyperRAM на своей плате (на ней установлено два таких чипа, по 16x4Мбит=64Мбит каждый, оставшиеся две BGAшки на плате). Контроллер работает с обоими чипами одновременно, по сути получая общую шину в 16 бит. При этом чипы работают в режиме DDR на частоте в 166.667 МГц (то есть эффективная частота 333.334 МГц), суммарно обеспечивая полосу пропускания в ~667 Мбит/с, что примерно соответствует самым медленным чипам DDR3.
Контроллер написал примерно недели за две вечерами после работы. Он, конечно, ещё сыроват, однако тот факт, что он вообще завёлся на реальном железе, имеет для меня очень большое значение. Если честно, то мне очень нетерпелось запиндюрить его на железо и посмотреть, что из этого выйдет
Ну и для любителей задать вопрос "а нафига" — вот списочек достижений:
1. Научился работать со встроенными примитивами tristate ввода/вывода в режиме DDR, дифференциального вывода (для тактового сигнала), а также примитивом задержки ввода (нужно для обеспечения setup time для входных триггеров в режиме чтения шины).
2. Научился работать с MCMM/PLL. В принципе тут невелика заслуга — всего-то надо потыкать мышкой в менюшки. Но на нём я научился встраивать в свой код IP-компоненты, сгенерированные средой.
3. Научился работать с FIFO на базе имеющихся на чипе Block RAM, а также с их использованием "маршаллить" данные между разными тактовыми доменами — главный модуль работает на частоте в 100 МГц, в то время как сам контроллер работает на частоте памяти — 166 МГц.
4. Т.к. эти частоты не кратны друг другу, пришлось проявить некоторую креативность при борьбе с нарушениями таймингов. Оказалось, что если с выхода триггера напрямую управлять сигналом CE (Clock Enable) сразу 10 буферов ввода/вывода (да ещё и расположенных в разных "байт-регионах" FPGA), то роутер оказывается не в состоянии расположить триггер так, чтобы обеспечить нужные тайминги сразу для всех буферов. Покупать же более быструю версию чипа (для которой роутер нормально разводил) не хотелось. После некоторого чесания репы придумал решение — дополнительно пробуферизировать сигнал к каждому буферу отдельным триггером. На этот раз роутер сумел раскидать эти буферные триггеры так, что все сигналы доходили вовремя — хотя и выплюнул мне ворнинг, что типа так делать не рекомендуется, и лучше использовать сигнал CE
5. Освоил эффективную работу с симулятором, а также разработал testbench, в котором использовал распространяемые производителем чипов памяти модели. Правда, оказалось, что железо работает немного не так, как их симулятор — но это уже история для другого раза
6. Научился работать с ILA (Integrated Logic Analyzer) в процессе дебага прошивки на реальном железе. Думается мне, что из его названия понятно, зачем он нужен
7. Подтвердил, что развёл эти чипы правильно, верно рассчитал ширину дорожек для нужного импеданса (и производитель плат не подкачал, хоть я и не заказывал controlled impedance дабы съэкономить бабло), выдержал требования по выравниванию длины дорожек, а также корректно развёл дифференциальные линии тактового сигнала. Ну и само собой подтвердил, что все BGAшки на плате пропаялись без проблем и "непропаев". Лично для меня это самое главное достижение, т.к. в этом было больше всех сомнений
Вообще если честно, эти чипы мне очень сильно понравились — они сравнительно дешёвые ($3.3 за чип при покупке "поштучно"), весьма неприхотливы в плане разводки, требуют всего 12 пинов, что позволяет легко развести даже несколько чипов на 4-слойной плате(для сравнения — DDR3 требует 50+ пинов, и развести его на 4-слойке весьма непросто), используют очень простой протокол — его описание умещается на всего нескольких страницах даташита — что делает контроллер очень простым и компактным в плане использования ресурсов FPGA (мой двухчиповый контроллер использует 348 триггеров и 299 LUT-ячеек, в то время как контроллер DDR3 занимает 10000+ ячеек), также — что для меня очень важно — поставляются в корпусах с шагом шаров в 1 мм, что позволяет использовать очень дешёвый 0.15/0.15/0.3 техпроцесс для платы (DDR2/3/3L бывают только в корпусах с шагом в 0.8 мм, что требует существенно более дорогой 0.125/0.125/0.25 процесс). Из недостатков можно отметить относительно невысокую скорость работы — отчасти это можно компенсировать размещением нескольких чипов "в параллель", а также сравнительно небольшой объём памяти (пока реально доступны на рынке только 8-мегабайтные чипы, хотя производитель и обещает выпускать более ёмкие чипы). Последний недостаток более серьёзный, т.к. разводить целые вязанки чипов может оказаться не так уж и просто — для получения 1 Гигабита придётся разводить аж 16 чипов. Но пока мне не требуется большой объём памяти, а как потребуется — ну придётся возиться с DDR3
Теперь осталось только проверить чип моста в USB — но с ним должно быть всё просто
Здравствуйте, koandrew, Вы писали:
K>Только что проверил работу своего доморощенного контроллера оперативной памяти типа HyperRAM на своей плате
Можно вопрос по HyperRAM? Как у нее с произвольным доступом? Когда тестили SDRAM vs DDR3, оказалось что на произвольном доступе DDR3 бессовесно сливает старой доброй EDO SDRAM, работающей на частотах >120МГц. На burst пакетах конечно скорость огого. Кэширующие контроллеры есть только за очен ь большие деньги в качестве IP.
Вопрос, можно ли HyperRAM использовать в сценариях где нужно иметь предсказуемую и разумную задержку при доступе к произвольному адресу памяти? Или эти сценарии не для нее? По даташитам 40ns latency, но для какого случая, при беглом прочтении не понял.
Здравствуйте, Alf, Вы писали:
Alf>Можно вопрос по HyperRAM? Как у нее с произвольным доступом? Когда тестили SDRAM vs DDR3, оказалось что на произвольном доступе DDR3 бессовесно сливает старой доброй EDO SDRAM, работающей на частотах >120МГц. На burst пакетах конечно скорость огого.
Как и в любом протоколе, где команды и данные передаются по одной и той же линии, предпочтительнее использовать burst'ы, т.к. они позволяют амортизировать оверхед от передачи командной последовательности в начале транзакции.
Alf>Кэширующие контроллеры есть только за очен ь большие деньги в качестве IP.
Посмотри вот на это. Оно бесплатно. Я в детали не вникал, но на первый взгляд вроде то, что тебе нужно.
Alf>Вопрос, можно ли HyperRAM использовать в сценариях где нужно иметь предсказуемую и разумную задержку при доступе к произвольному адресу памяти? Или эти сценарии не для нее? По даташитам 40ns latency, но для какого случая, при беглом прочтении не понял.
Предсказуемую — да, а разумность зависит от задачи. По сути эти чипы представляют из себя псевдо-SRAM, то есть матрицы DRAM объединены на одном кристалле с контроллером, которые отвечает за "обслуживание" массива типа рефреша. Имеются два варианта поведения — максимальная производительность (тогда во время C&C фазы чип сообщает, нужна ли дополнительная задержка из-за происходящего в данный момент рефреша), либо фиксированная латентность (чип всегда использует двойную задержку). В первом случае латентность получается 2 * Tclk + Tacc или 2 * Tclk + 2 * Tacc (то есть при частоте в 166 МГц получается 48 и 84 нс соответственно), во втором — фиксированные 2 * Tclk + 2 * Tacc (84 нс). Они отсчитывают Tacc от третьего такта, потому что первый байт командного слова определяют, идёт ли запрос к собственно памяти, или регистровому пространству (в нём находятся конфигурационные регистры, а также служебная информация о чипе, таймингах и т.д.), к которому доступ идёт без латентности.
То есть, как видишь, концептуально чип похож на первый DDR с его 2n prefetch, разве что наличие бортового контроллера существенно упрощает работу с памятью.
Да, и ещё — эти чипы существуют для двух рабочих напряжений — 3..3.3 В и 1.8 В, причём трёхвольтовые используют обычную (не дифферециальную) линию тактового сигнала, и работают только на 100 МГц, в то время как 1.8-вольтовые требуют дифференциальный клок, но бывают в трёх модификациях — под частоты 100, 133 и 166 МГц. У меня на плате стоят 1.8-вольтовые чипы на 166 МГц, потому само собой соответствующий банк FPGA питается 1.8 В, для работы использую стандарты HSTL_II_18 и DIFF_HSTL_II_18 для обычных DDR пинов и клока соответственно, для остальных сигналов (CS, сброс, строб) использую обычный LVCMOS18.
Круто.
K>4. Т.к. эти частоты не кратны друг другу, пришлось проявить некоторую креативность при борьбе с нарушениями таймингов. Оказалось, что если с выхода триггера напрямую управлять сигналом CE (Clock Enable) сразу 10 буферов ввода/вывода (да ещё и расположенных в разных "байт-регионах" FPGA), то роутер оказывается не в состоянии расположить триггер так, чтобы обеспечить нужные тайминги сразу для всех буферов. Покупать же более быструю версию чипа (для которой роутер нормально разводил) не хотелось. После некоторого чесания репы придумал решение — дополнительно пробуферизировать сигнал к каждому буферу отдельным триггером. На этот раз роутер сумел раскидать эти буферные триггеры так, что все сигналы доходили вовремя — хотя и выплюнул мне ворнинг, что типа так делать не рекомендуется, и лучше использовать сигнал CE
Когда брал митовский 6.004х на лабах по дизайну процессора строго на строго рекомендовали не буферизировать clk.
I>>Zynq тем хорош, что имеет скоростную шину между АРМ процессором и ФПГА. Между ними используется AXI4 (part of the ARM AMBA® 3.0 open standard). K>У него внутренняя шина AXI3, которая несколько отличается от AXI4. Кстати Microblaze тоже имеет такую шину, точнее даже две — одна для кода, вторая — для данных.
Да действительно, посмотрел Technical Reference Manual на Zynq, там пишут что AXI3, а в книге мне почему-то рассказывают про AXI4.
Если я правильно понял, у Zynq-a 9 интерфейсов AXI:
AMBA AXI interfaces for primary data communication
• Two 32-bit AXI master interfaces
• Two 32-bit AXI slave interfaces
• Four 64-bit/32-bit configurable, buffered AXI slave interfaces with direct access to DDR memory and OCM, referred
to as high-performance AXI ports
• One 64-bit AXI slave interface (ACP port) for coherent access to CPU memory
I>>Я пока это дело только изучаю. Я себе вот этот board приобрёл и читаю вот эту книжку. Очень интересно. K>Я бы на твоём месте взял Arty-Z7-20 — она стоит лишь немного больше, чем Зибо, но зато там более мощный чип. Хотя тут, конечно, есть ещё вопрос, какая периферия тебе нужна. Лично для меня не проблема разработать и сделать плату расширения с нужной мне периферией, но допускаю, что кому-то не захочется возиться с этим, и они предпочтут, чтобы всё было искаропки, ну или хотя бы на уже готовых платах расширения.
Сравнил эти две модели, вроде по перефирии не отличичаются, FPGA там помощней, это да.
K>Я планирую как-нить заняться разводкой платы под Zynq, но пока останавливает две вещи — во-первых, недорогие модели поставляются только в корпусах с 0.8 мм шагом шаров (что потребует более тонкий == дорогой техпроцесс 0.125/0.125 мм треки/0.25 мм отверстия или лучше), во-вторых, для полной разводки нужна минимум шестислойная (а то и восьмислойная) плата, которая тоже стоит немалых денег.
В домашних условиях это конечно будет высший пилотаж. Тогда можешь делать evaluation board или клиенские платы для FPGA под заказ.
I>Да действительно, посмотрел Technical Reference Manual на Zynq, там пишут что AXI3, а в книге мне почему-то рассказывают про AXI4. I>Если я правильно понял, у Zynq-a 9 интерфейсов AXI:
Я вообще советую вам прочитать этот мануал — возможно, пропустив некоторые некасающиеся вас секции. Лично я полгода назад его читал, и должен сказать, что написан он очень хорошо! Все бы мануалы такими были!
I>Сравнил эти две модели, вроде по перефирии не отличичаются, FPGA там помощней, это да.
Под периферией я подразумеваю всякие чипы/разъёмы, стоящие на плате. Они отличаются.
I>В домашних условиях это конечно будет высший пилотаж. Тогда можешь делать evaluation board или клиенские платы для FPGA под заказ.
Для этого надо будет освоить Lead-free процесс, ибо продавать не-LF девайсы у нас запрещено.
K>Я вообще советую вам прочитать этот мануал — возможно, пропустив некоторые некасающиеся вас секции. Лично я полгода назад его читал, и должен сказать, что написан он очень хорошо! Все бы мануалы такими были!
Спасибо за советы. Пишите о ваших проектах здесь дельше. Интересно будет почитать.
Здравствуйте, koandrew, Вы писали:
I>>В домашних условиях это конечно будет высший пилотаж. Тогда можешь делать evaluation board или клиенские платы для FPGA под заказ. K>Для этого надо будет освоить Lead-free процесс, ибо продавать не-LF девайсы у нас запрещено.
Ну лично я изначально только такой процесс и использую, в том числе и дома. Потому как нет желания лишний раз дышать парами свинца. И никаких проблем при такой пайке не чувствуется.
P.S. Поздравляю с достижением — не у всех такая серьёзная платка работает с первого раза. )
Здравствуйте, alex_public, Вы писали:
_>Ну лично я изначально только такой процесс и использую, в том числе и дома. Потому как нет желания лишний раз дышать парами свинца. И никаких проблем при такой пайке не чувствуется.
Так бессвинцовая пайка в целом опаснее (впрочем, для хобби один хрен -- объёмы не те).
Здравствуйте, alex_public, Вы писали:
_>Ну лично я изначально только такой процесс и использую, в том числе и дома.
Я пробовал паять схему с QFN'ом пастой LF, но получилить мосты. А со свинцовой пастой всё прошло без проблем.
_>Потому как нет желания лишний раз дышать парами свинца. И никаких проблем при такой пайке не чувствуется.
Ну в этот раз мне пришлось дышать дымом от расплавившегося коннектора А вообще у меня рядом с рабочим местом стоит очиститель воздуха с HEPA-фильтром — он очень хорошо устраняет все запахи.
_>P.S. Поздравляю с достижением — не у всех такая серьёзная платка работает с первого раза. )
Строго говоря, это второй "подход к снаряду". Просто в первой ревизии я ещё до сборки нашёл кучу косяков, потому собирать не было смысла.
Здравствуйте, koandrew, Вы писали:
_>>Ну лично я изначально только такой процесс и использую, в том числе и дома. K>Я пробовал паять схему с QFN'ом пастой LF, но получилить мосты. А со свинцовой пастой всё прошло без проблем.
А, ну я писал про обычную пайку — там разницы нет вообще, только температуру ставишь градусов на 20 выше и всё. А в случае пасты и печки всё чуть сложнее — там и паста обязательно нужна правильная (должна обеспечивать нужную вязкость и поверхностное натяжение) и термопрофиль нужен совсем другой, специально под эту пасту. В целом тоже никаких проблем не должно быть, просто надо подобрать нужные материалы и профили. )
_>>Потому как нет желания лишний раз дышать парами свинца. И никаких проблем при такой пайке не чувствуется. K>Ну в этот раз мне пришлось дышать дымом от расплавившегося коннектора А вообще у меня рядом с рабочим местом стоит очиститель воздуха с HEPA-фильтром — он очень хорошо устраняет все запахи.
Ага, у меня тоже что-то подобное. Но всё равно, если носом уткнуться, то не получится не дышать продуктами пайки. Кстати, в этом смысле ещё надо не забывать про подходящий флюс — не токсичный (я как раз такой использую). )
Здравствуйте, koandrew, Вы писали:
K>А вообще у меня рядом с рабочим местом стоит очиститель воздуха с HEPA-фильтром — он очень хорошо устраняет все запахи.
Здравствуйте, alex_public, Вы писали:
_>С чего бы это? Там припой из чистого олова и капли меди или серебра.
Основная опасность при пайке -- пары флюса, свинец при температурах пайки испаряется слабо и до дыхательных путей не долетает. При бессвинцовой пайке флюс в целом более активный и температура выше (а значит, больше продуктов сгорания флюса).
Вот такой. Вообще-то я его купил для другой цели (борьба с пылью, потому он такой здоровый), но он оказался ещё и прекрасным дымоуловителем. Но вообще есть недорогие настольные варианты типа такого:
Здравствуйте, alex_public, Вы писали:
_>А, ну я писал про обычную пайку — там разницы нет вообще, только температуру ставишь градусов на 20 выше и всё. А в случае пасты и печки всё чуть сложнее — там и паста обязательно нужна правильная (должна обеспечивать нужную вязкость и поверхностное натяжение) и термопрофиль нужен совсем другой, специально под эту пасту.
Я использовал пасту SAC305 и рекомендуемый для неё профиль. _>В целом тоже никаких проблем не должно быть, просто надо подобрать нужные материалы и профили. )
Ну и нафига весь этот цирк? Если ты пасту не собираешься жрать ложкой, то нифига тебе не будет. Иначе я бы уже давно копи двинул от того, сколько свинцовых батарей я в детстве переплавил, да и паяльником я в детстве немало орудовал
Всё равно, если уж дело дойдёт до коммерческого производства, то буду заказывать сборку где-то на фабе. Ибо одно дело собрать вручную одну-две платы, и совсем другие — сотни.
_>Ага, у меня тоже что-то подобное. Но всё равно, если носом уткнуться, то не получится не дышать продуктами пайки. Кстати, в этом смысле ещё надо не забывать про подходящий флюс — не токсичный (я как раз такой использую). )
Да мне как-то пофигу на всё это. Жаль что здесь не смог найти старой доброй канифоли — мне так нравился её запах в детстве
Здравствуйте, Иван Дубров, Вы писали:
ИД>Так бессвинцовая пайка в целом опаснее (впрочем, для хобби один хрен -- объёмы не те).
Ну в моём случае в общем-то всё равно, ибо руками я паяю сравнительно немного (в основном только коннекторы и очень изредка какие-нить "черездырочные" компоненты — я ими оооочень редко пользуюсь, предпочитая SMD), а в основном пользуюсь печкой, рядом с которой стоит фильтр. Так что дышать продуктами пайки мне почти не приходится.
Здравствуйте, koandrew, Вы писали: K>SystemVerilog всё равно рулит, ибо вобрал в себя всё лучшее из обоих языков. Даже Xilinx новые свои IP нынче пишет на SV.
То, кто на чём пишет ядра, не показатель ничего.
VHDL со своей строгой типизацией дисциплинирует. Ты сразу приучаешься писать как надо. Тут очень мало шансов выстрелить себе в ногу. В отличие от Верилога, большинство ошибок отлавливает компилятор. Поэтому для начинающих VHDL.
Ну и чисто эстетически Верилог (и его наследник СистемВерилог) ужасен. Когда мне приходится читать код на Верилоге, я плачу кровавыми слезами. Придумать такой уродский синтаксис, находясь в трезмом уме, невозможно. Только по обкурке, не иначе. Бегинендить не надоедает?
Здравствуйте, Alf, Вы писали:
_>>>И чего такого есть в SV, чего не хватает в VHDL? I>>Мне бы тоже интерeсно было бы узнать ответ на этот вопрос.
Alf>видимо того же, чего не хватало Фортрану или Аде и что было в Си. Не?
Не совсем понял ответ. По мне так у Фортрана своя ниша (числодробилка), а у Си своя (системное программирование).
Но это совсем другая тема. Меня интересует VHDL vs. Verilog.
Verilog я не изучал, поэтому и интересно услышать развёрнутый ответ.
Здравствуйте, Alf, Вы писали: _>>>И чего такого есть в SV, чего не хватает в VHDL? I>>Мне бы тоже интерeсно было бы узнать ответ на этот вопрос. Alf>видимо того же, чего не хватало Фортрану или Аде и что было в Си. Не?
И чего же?
Здравствуйте, rising_edge, Вы писали:
_>То, кто на чём пишет ядра, не показатель ничего.
Вообще-то показатель.
_>VHDL со своей строгой типизацией дисциплинирует. Ты сразу приучаешься писать как надо. Тут очень мало шансов выстрелить себе в ногу. В отличие от Верилога, большинство ошибок отлавливает компилятор. Поэтому для начинающих VHDL. Ты на работе на паскале пишешь?
_>Ну и чисто эстетически Верилог (и его наследник СистемВерилог) ужасен. Когда мне приходится читать код на Верилоге, я плачу кровавыми слезами. Придумать такой уродский синтаксис, находясь в трезмом уме, невозможно. Только по обкурке, не иначе. Бегинендить не надоедает?
Я не ослышался — вэхадеэльник жалуется на многабукав? Это просто Как там архитектуры с портмапами поживают? Не надоело одно и то же по сто раз писать? И потом искать ошибки от копипасты?
_>И чего такого есть в SV, чего не хватает в VHDL?
Классы, ООП, интерфейсы, свойства, более ясная семантика для процессов/комбинаторных блоков (always_ff/always_comb/always_latch, а также квантификаторы unique/priority для if/case, clocking blocks, автоматическое подключение портов по имени, упрощённое явное указание подключения, если имя порта совпадает с проводом в подключаемым scope'е (.pin_name вместо .pin_name(pin_name)).
Это то, что пришло в голову за пару минут. Так что оставьте уже это г-но мамонта VHDL на помойке истории и не тыкайте больше палочкой — а то пахнет сильно.
Здравствуйте, Iso12, Вы писали:
I>Verilog я не изучал, поэтому и интересно услышать развёрнутый ответ.
Я в универе изучал оба — сначала VHDL, потом Verilog. Я там выше по теме описал основные преимущества SV. Сейчас сам пишу весь код исключительно на нём. I>Но это совсем другая тема. Меня интересует VHDL vs. Verilog.
SV проще, удобнее, понятее, современнее, поддерживает основные концепции ООП, есть очень много полезных фишек (типа квантификатора priority case, которые позволяют сказать синтезатору, что некоторые варианты ветвей "равнее" других, и потому для них нужно синтезировать наиболее короткий datapath, или unique, заставляющий синтезатор убедиться, что подветки действительно mutually exclusive), и т.д. Так что если у вас есть право выбора языка (то есть он не навязан вам, к примеру, боссом на работе, или профессором универа), то выбор как бы очевиден ИМХО.
Здравствуйте, koandrew, Вы писали:
K> Ты на работе на паскале пишешь?
Мы с вами на брудершафт не пили.
_>>Ну и чисто эстетически Верилог (и его наследник СистемВерилог) ужасен. Когда мне приходится читать код на Верилоге, я плачу кровавыми слезами. Придумать такой уродский синтаксис, находясь в трезмом уме, невозможно. Только по обкурке, не иначе. Бегинендить не надоедает? K>Я не ослышался — вэхадеэльник жалуется на многабукав? Это просто Как там архитектуры с портмапами поживают? Не надоело одно и то же по сто раз писать? И потом искать ошибки от копипасты?
Ась? Копипастить что?
_>>И чего такого есть в SV, чего не хватает в VHDL? K>Классы, ООП, интерфейсы, свойства,
ООП-фетишизм? Я даже представить не могу, зачем мне это нужно для дизайна железа.
> более ясная семантика для процессов/комбинаторных блоков (always_ff/always_comb/always_latch, а также квантификаторы unique/priority для if/case, clocking blocks,
Больше, больше костылей и подпорок. Verilog и так убог, сделаем его ещё больше убогим.
Здравствуйте, rising_edge, Вы писали:
_>Мы с вами на брудершафт не пили.
В интернете принято обращаться на "ты", не нравится — кнопка "закрыть" находится наверху окна.
_>Ась? Копипастить что?
Ещё скажи, что ты все эти портмапы со 100500 портами каждый раз с нуля руками набиваешь
_>ООП-фетишизм? Я даже представить не могу, зачем мне это нужно для дизайна железа.
Почитай про AXI Verification IP — узнаешь.
_>Больше, больше костылей и подпорок. Verilog и так убог, сделаем его ещё больше убогим.
Очень веский аргумент
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, rising_edge, Вы писали:
_>>Мы с вами на брудершафт не пили. K>В интернете принято обращаться на "ты", не нравится — кнопка "закрыть" находится наверху окна.
Молодой человек, может, у вас там в канадских интернетах и принято тыкать всем подряд, но к незнакомым людям обращаются на "вы" независимо от среды.
_>>Ась? Копипастить что? K>Ещё скажи, что ты все эти портмапы со 100500 портами каждый раз с нуля руками набиваешь
Я чего-то не знаю про Верилог? Там разве нет портмапов? Как же там 100500 не руками набивать?
_>>ООП-фетишизм? Я даже представить не могу, зачем мне это нужно для дизайна железа. K>Почитай про AXI Verification IP — узнаешь.
Ненене, мне про верификацию не надо. Мне про разработку с применением ООП расскажите. Особенно про наследование.
_>>Больше, больше костылей и подпорок. Verilog и так убог, сделаем его ещё больше убогим. K>Очень веский аргумент
Смотрите, не разбейте лицо.
Здравствуйте, rising_edge, Вы писали:
_>Молодой человек, может, у вас там в канадских интернетах и принято тыкать всем подряд, но к незнакомым людям обращаются на "вы" независимо от среды.
Мне всё с тобой понятно — агрументов у тебя нет. Так что свободен! Только не забудь песочек за собой прибрать
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, rising_edge, Вы писали:
_>>Молодой человек, может, у вас там в канадских интернетах и принято тыкать всем подряд, но к незнакомым людям обращаются на "вы" независимо от среды. K>Мне всё с тобой понятно — агрументов у тебя нет. Так что свободен! Только не забудь песочек за собой прибрать
Конкретно в этом месте я с Вашим оппонентом согласен.
Хотелось бы услышать аргументированный разговор двух специалистов на тему "Verilog vs. VHDL" а не школьников типа "сам дурак".
Мне, как начинаюшиму, очень хотелось бы услышать плюсы и минусы того и другого языка. Почему VHDL очень популярен в Европе а Verilog в Америке? Перспективы этих языков. Буду рад услышать обоснованные аргументы от обоих оппонентов. Заранее спасибо.
Здравствуйте, rising_edge, Вы писали:
K>>В интернете принято обращаться на "ты", не нравится — кнопка "закрыть" находится наверху окна. _>Молодой человек, может, у вас там в канадских интернетах и принято тыкать всем подряд, но к незнакомым людям обращаются на "вы" независимо от среды.
P.S. В принципе было бы интересно послушать мнение специалиста по VHDL на тему его преимуществ над Verilog'ом. Только не в стиле общения нервных школьников, а по серьёзному...
Здравствуйте, Iso12, Вы писали:
I>Хотелось бы услышать аргументированный разговор двух специалистов на тему "Verilog vs. VHDL" а не школьников типа "сам дурак". I>Мне, как начинаюшиму, очень хотелось бы услышать плюсы и минусы того и другого языка.
Ответ находится в гугле за пять секунд (я засекал). Если одним предложением: VHDL — это Паскаль для железа (строгая типизация, многобукав в коде), а Верилог — это Си (менее строгая типизация, меньше словесного шума в коде). SystemVerilog — это С++ (Верилог с некоторыми изменениями и массой новых фич, не имеющих аналогов в VHDL, в основном эти фичи направлены на облегчение разработки тестбенчей).
I>Почему VHDL очень популярен в Европе а Verilog в Америке?
В основном по историческим причинам. Плюс популярность зависит от выбранной сферы применения. В штатах в оборонке VHDL более популярен, а Верилог рулит в коммерческой сфере.
I>Перспективы этих языков. Буду рад услышать обоснованные аргументы от обоих оппонентов. Заранее спасибо.
Сейчас это не имеет ровным счётом никакого значения, ибо ИДЕ от всех производителей чипов умеют в mixed-language projects, то есть в одном проекте можно "бесшовно" собирать компоненты, написанные на разных языках. Плюс эти языки не настолько сильно различаются, чтобы знающий один из них не смог как минимум прочитать и понять код на другом.
SystemVerilog стоит особняком, ибо в нём есть фичи, не имеющие аналогов ни в VHDL, ни в Verilog.
Здравствуйте, Iso12, Вы писали:
I>Уважаемые коллеги !
I>Хотелось бы услышать аргументированный разговор двух специалистов на тему "Verilog vs. VHDL" а не школьников типа "сам дурак".
начинающим — бесплатный дельный совет — попробовать и то и другое =) занимает минимум времени, доставляет максимально.
Здравствуйте, Alf, Вы писали:
Alf>начинающим — бесплатный дельный совет — попробовать и то и другое =) занимает минимум времени, доставляет максимально.
Я не знаю ни одного человека, который, попробовав оба языка, сознательно выбрал бы VHDL. У нас в универе даже специально курс по VHDL ставили на семестр раньше, чем курс по верилогу, ибо после его на VHDL уже никто добровольно не переходил После языковых курсов у нас был курс дизайна, где студенты были вольны выбирать любой язык, и все до единого с моего потока выбрали верилог
Здравствуйте, alex_public, Вы писали: _>P.S. В принципе было бы интересно послушать мнение специалиста по VHDL на тему его преимуществ над Verilog'ом. Только не в стиле общения нервных школьников, а по серьёзному...
Я попробую изложить то, чем мне плох Верилог.
Начнём с первого взгляда.
Те, кто говорят, что Верилог похож на Си, пусть внимательнее посмотрят на begin/end, case (без switch) и фигурные скобки. Если это "как в Си", то я Эйнштейн. Причём всякие endmodule, endfuncion, endcase есть, а endif почему-то нет. И почему-то просто end было недостаточно, а обязательно надо endmodule и endcase.
Что меня особенно фраппирует в Верилоге. Вот в ВХДЛ есть просто сигнал. Неважно, кем он драйвится: триггером или асинхронной логикой. Неважно, как он формируется: в процессе или вне. Я просто ввожу сигнал и ни о чём не думаю -- сигнал и есть сигнал. Но в Верилоге сигналы зачем-то разделили на reg и wire. Если вы формируете сигнал в блоке always, то это должен быть reg, причём не важно, описываете ли вы в always триггер или комбинационную логику. А если вы ходите описать комбинационную логику вне блока always, то вы должны определить сигнал как wire. Но, внезапно, этого недостаточно. Нельзя просто взять и написать
wire z;
z <= x + y;
как хотелось бы в нормально спроектированном языке, а надо обязательно использовать слово assign (которое используется только для этого и ни для чего больше) и только блокирующее присваивание.
wire z;
assign z = x + y;
О разрядности сигналов. Верилог запросто позволяет соединить шины разных разрядностей как непосредственно двух сигналов, так и при маппинге портов, бросая тут лишь варнинг. ВХДЛ такого не позволяет в принципе. А если у вас варнингов много (тем более если вы не можете их исправить, а такое часто бывает при использовании вендоровских или сторонних IP-ядер), в этом потоке можно проглядеть варнинг и про несовпадении разрядностей и долго искать, а чё же оно не работает.
Как ни странно, Верилог позволяет забыть о декларации сигнала. Вы можете использовать сигнал, предварительно не описав его. Будет всего-лишь варнинг. Причём, по моему, сигнал этот будет одноразрядным. Стреляй себе в ногу, не хочу.
Ещё про разрядность. Целые числа в Верилоге 32-битные. Это приводит к тому, что приходится у целых чисел разрядность задавать вручную. Если я в ВХДЛ просто пишу
a <= a + 1;
и ни о чём не думаю, потому что функция "+" сама заботится о минимальном двоичном представлении десятичного числа, то в Верилоге такая запись снова даст варнинг о несовпадающей разрядности. Поэтому приходится счётчики писать в виде
a <= a + 1'b1;
Перечислимый тип. В ВХДЛ перечислимый тип используется, например, для описания конечных автоматов. Я просто описываю перечислимый тип
type state_t is (st0, st1, st2, st3);
signal state : state_t;
а кодирование этого типа отдаю синтезатору. Он на основе числа состояний и графа перехода выбирает оптимальное кодирование: sequental, one hot, gray, etc. Если я с ним не согласен, я могу ипользовать соответсвующий атрибут, который жёстко укажет, как закодировать КА. На худой конец я могу действовать в Верилог-стиле. А сдить Верилога -- это ручное кодирование и использованием корявенького препроцессора:
А корявенький он потому, что нельзя "как в Си" взять и написать
case (state)
st0: a <= a0 + b0;
st1: a <= a1 + b1;
st2: a <= a2 + b2;
st3: a <= a3 + b3;
endcase
потому что компилятор просто не найдёт все эти st0..st3. Надо ему глаза открыть:
case (state)
`st0: a <= a0 + b0;
`st1: a <= a1 + b1;
`st2: a <= a2 + b2;
`st3: a <= a3 + b3;
endcase
В ВХДЛ на самом деле мало что вшито в язык. Мощь языку придают сторонние бибилиотеки. Благодаря им мы имеем знаковую математику, беззнаковую математику и даже математику с плавающей точкой. И это всё во внешних модулях, которые написаны только с использованием синтезируемого подмножества. Для симуляции даже написали бибилиотеку форматированного вывода в стиле Си (printf & Co). А Верилоге всё прибито гвоздями в самом языке.
По-крупному, пожалуй, достаточно. В целом у меня стойкое убеждение, что там, где в ВХДЛ ошибка и "Ты не пройдёшь", а в Верилоге всего лишь предупреждение, позволяет, а местами и провоцирует написание говнокода, который на ВХДЛ в принципе невозможен.
Здравствуйте, rising_edge, Вы писали:
_>Начнём с первого взгляда. _>Те, кто говорят, что Верилог похож на Си, пусть внимательнее посмотрят на begin/end, case (без switch) и фигурные скобки. Если это "как в Си", то я Эйнштейн. Причём всякие endmodule, endfuncion, endcase есть, а endif почему-то нет. И почему-то просто end было недостаточно, а обязательно надо endmodule и endcase.
мнэээ, возможно это только лишь мое субьективное мнение, но пописав продакшн кода на двух десятках самых разнообразных языков, мне абсолютно пофиг у кого где скобки или begin/end, сколько пробелов или табов нужно ставить чтобы PIP ошибки не лезли и прочая другая инфраструктурная муть.
Мне нужно решить задачу, пофиг на каком ЯП. Я беру ее и решаю. Возможно не самым красноглазым и гипер-оптимизированным методом, но беру и решаю.
Для того чтобы сделать что-то на верилоге мне нужно сделать X действий, при этом опыт в других си-подобных языках мне скорее помогает, чем мешает.
Для того же самого на VHDL мне требуется X*n действий, плюс вообще никакой корреляции с любым другим опытом, который есть у меня. Потому что язык ADA из которого вырос VHDL я видел в википедии "у бэлых тапках", соответствующего опыта у меня нет и не будет.
Вопрос знатокам — какой ЯП я выберу для решеиния задачи?
Дв, меня откровенно бесит несовершенство и косяки при трансформации разрядостей переменных и ширины шин в Верилоге, но я уже один раз отматерился по этому поводу, создал несколько сниппетов для себя и больше к этому вопросу не возвращаюсь.
Точно так же я поступаю со Свифтом и многими другими ЯП.
Если будет задача — написать логику только на VHDL и никакой другой язык применять нельзя — ну ок, вздохну и напишу. Будет долго и неприятно, но напишу.
Так к чему весь этот сыр-бор-холливор? =) "Пишите много, пишите вкусно"(tm)
А новичкам нужно не выбирать идеальный ЯП для всех случаев, а просто научиться решать задачи и выбирать для этого подходящие инструменты.
Не пробуя, не экспериментируя, не набивая шишки, не учась распознавать причинно-следственные связи это сделать невозможно.
Здравствуйте, rising_edge, Вы писали:
_>Я попробую изложить то, чем мне плох Верилог. _>...
Из всего указанного полностью однозначным (но при этом совсем не важным для меня лично) является тот факт, что VHDL будет генерировать ошибку в тех случаях, где у Verilog будет предупреждение. По всем остальным вопросам однозначного впечатления нет — надо смотреть конкретные случаи. )
Хочу сразу уточнить, что я совсем не специалист в области ПЛИС и только начинаю с этим разбираться (правда при этом в случае положительного решения использоваться эта технология будет совсем не в рамках хобби, а в серьёзных проектах). В данный момент все задачи в данной области мы успешно решаем с помощью микроконтроллеров (а вот в работе с ними у меня вполне экспертные знания), но в силу ряда обстоятельств я обдумываю освоение новых подходов. Однако на данный момент вся моя возня с ПЛИС — это даже не хобби, а просто знакомство.
Для одного из первых заходов на такое знакомство я накидал простенькое решение решение на Verilog'е одной из наших реальных задач, естественно в максимально упрощённом виде:
module MC(input clk, input[15:0] period, output reg w1=0, output reg w2=0);
reg[15:0] r_period=0;
reg[15:0] r_counter=0;
always @(posedge clk) begin
if(r_period!=period) begin
r_period=period;
if(r_counter>period*4) r_counter=period*4;
end
case(r_counter)
0: begin w1=1; w2=0; end
r_period: begin w1=1; w2=1; end
r_period*2: begin w1=0; w2=1; end
r_period*3: begin w1=0; w2=0; end
r_period*4: r_counter<=0;
endcase
r_counter=r_counter+1;
end
endmodule
Возможно этот код чем-то не оптимальный, т.к. я тут ещё новичок, но во всяком случае он компилируется и моделируется правильно. Так вот вопрос: как будет выглядеть его аналог на VHDL и в чём возможны его преимущества в таком простом случае?
И далее, если мы захотим усложить задачу, подключив скажем какую-то реализацию i2c (естественно готовую, т.к. писать самим такое странно) для установки значения period, то с помощью какого инструмента это будет проще сделать?
_>Для одного из первых заходов на такое знакомство я накидал простенькое решение решение на Verilog'е одной из наших реальных задач, естественно в максимально упрощённом виде: _>
_>module MC(input clk, input[15:0] period, output reg w1=0, output reg w2=0);
_>reg[15:0] r_period=0;
_>reg[15:0] r_counter=0;
_> always @(posedge clk) begin
_> if(r_period!=period) begin
_> r_period=period;
_> if(r_counter>period*4) r_counter=period*4;
_> end
_> case(r_counter)
_> 0: begin w1=1; w2=0; end
_> r_period: begin w1=1; w2=1; end
_> r_period*2: begin w1=0; w2=1; end
_> r_period*3: begin w1=0; w2=0; end
_> r_period*4: r_counter<=0;
_> endcase
_> r_counter=r_counter+1;
_> end
_>endmodule
_>
Обладая только знаниями языка C, мне кажется, что ваш код неправильно отработает, если period будет больше чем 16383. Или я ошибаюсь?
Здравствуйте, alex_public, Вы писали:
_>Для одного из первых заходов на такое знакомство я накидал простенькое решение решение на Verilog'е одной из наших реальных задач, естественно в максимально упрощённом виде:
Видно, что код писал программист, а не железячник.
_>Возможно этот код чем-то не оптимальный, т.к. я тут ещё новичок, но во всяком случае он компилируется и моделируется правильно.
Этого недостаточно. Основной критерий -- это реализация в железе. Прерасно работающий в симуляторе код в ПЛИС может быть очень медленным и пожирающим кучу ресурсов.
_> Так вот вопрос: как будет выглядеть его аналог на VHDL и в чём возможны его преимущества в таком простом случае?
Если вы уже выбрали для себя Верилог, не все ли равно, как подобный код будет выглядеть на другом языке?
_>И далее, если мы захотим усложить задачу, подключив скажем какую-то реализацию i2c (естественно готовую, т.к. писать самим такое странно) для установки значения period, то с помощью какого инструмента это будет проще сделать?
Здравствуйте, alex_public, Вы писали:
_>Возможно этот код чем-то не оптимальный, т.к. я тут ещё новичок, но во всяком случае он компилируется и моделируется правильно. Так вот вопрос: как будет выглядеть его аналог на VHDL и в чём возможны его преимущества в таком простом случае?
Меня в твоём коде сразу напрягло умножение (в общем случае это ОЧЕНЬ дорогая операция в железе), но всем известно, что умножение на 4 можно заменить на сдвиг влево на 2 позиции. И мне стало интересно, известно ли это синтезатору. Потому я скормил твой код ИДЕ Vivado 2017.2. Изучив схему, которую он сгенерил, убедился, что он в курсе
Но в целом я согласен с другим комментатором, что код написан чисто софтовый, и несколько gotchas верилога ты таки словил Я просто заменил блокирующие присваивания на неблокирующие, и на этом съэкономил около 50 LUTов
_>И далее, если мы захотим усложить задачу, подключив скажем какую-то реализацию i2c (естественно готовую, т.к. писать самим такое странно) для установки значения period, то с помощью какого инструмента это будет проще сделать? http://www.xilinx.com/support/documentation/ip_documentation/axi_iic/v2_0/pg090-axi-iic.pdf Он уже memory-mapped.
Хотя контроллер i2c стоит руками написать хотя бы однажды в качестве тренировки/обучения, т.к. он достаточно прост для того, чтобы новички его смогли осилить, но при этом включает в себя много важных концепций, которые применяются при работе с ПЛИС — работа с разными clock domain'ами, tri-state буферы, являющиеся и входом, и выходом, генерация тактовой частоты для внешнего устройства, работа с памятью/FIFO. На всяких обучалках часто его пишут после UART'а, который вообще является классикой ПЛИС-дизайна. Так что крайне рекомендую попробовать написать самому!
Здравствуйте, Iso12, Вы писали:
I>Обладая только знаниями языка C, мне кажется, что ваш код неправильно отработает, если period будет больше чем 16383. Или я ошибаюсь?
Всё верно, но это укладывается в условие задачи. Разве что тут это можно было технически показать (например задав для периода 14 бит), а я этого не сделал вследствие своих привычек из МК (где все подобные разрядности кратны 8). С другой стороны, если продолжить эту задачу (как я писал выше), то при передаче периода из i2c модуля всё равно скорее всего придётся использоваться стандартные 16 бит...
Ещё можно выйти за пределы задачки, увеличив точность выше требуемой — задав для counter разрядность 18 и тогда или считать через 4 или увеличить частоту в 4 раза. В общем есть множество вариантов развития и приведённый код — это всего лишь тестовый пример, а не что-то из рабочего проекта.
Здравствуйте, rising_edge, Вы писали:
_>>Для одного из первых заходов на такое знакомство я накидал простенькое решение решение на Verilog'е одной из наших реальных задач, естественно в максимально упрощённом виде: _>Видно, что код писал программист, а не железячник.
Ну железки то мы тоже делаем (включая разводку своих плат и т.п.), только пока без всяких ПЛИС. Хотя я действительно больше специализируюсь на коде (но в силу положения приходится на определённом уровне разбираться во всём). Кстати, а в чём именно видны особенности программиста? Любопытно просто... )))
_>>Возможно этот код чем-то не оптимальный, т.к. я тут ещё новичок, но во всяком случае он компилируется и моделируется правильно. _>Этого недостаточно. Основной критерий -- это реализация в железе. Прерасно работающий в симуляторе код в ПЛИС может быть очень медленным и пожирающим кучу ресурсов.
Естественно. Уже планирую тесты на некоторых ПЛИС (для начала скорее всего iCE40 Ultra от Lattice).
_>> Так вот вопрос: как будет выглядеть его аналог на VHDL и в чём возможны его преимущества в таком простом случае? _>Если вы уже выбрали для себя Верилог, не все ли равно, как подобный код будет выглядеть на другом языке?
Вообще то мы пока что ещё ничего не выбрали, даже собственно вообще применение ПЛИС в своих проектах. ))) А это всё не более чем один из шагов по ознакомление с данными технологиями.
И увидеть аналог на VHDL этого тестового кода было бы очень любопытно. Особенно если на его примере будет возможно показать хоть одно из преимуществ VHDL.
_>>И далее, если мы захотим усложить задачу, подключив скажем какую-то реализацию i2c (естественно готовую, т.к. писать самим такое странно) для установки значения period, то с помощью какого инструмента это будет проще сделать? _>Я не понял вопроса. Проще сделать что?
Ну в приведённом примере модуль получает извне некое 16-и битное значение period. Хочется изменить задачу, чтобы на входе была просто i2c шина, по которой будут передавать этот же самый period для установки в тот же самый регистр. Естественно писать самому поддержку i2c желания нет никакого — подразумевается скачивание некой готовой реализации и подключения её к нашему модулю. Так вот вопрос, этот процесс будет проще (удобнее искать и интегрировать в свой проект готовые стандартные реализации) на Verilog или с помощью VHDL? Или же в данной области особой разницы между этими инструментами нет?
Здравствуйте, koandrew, Вы писали:
_>>Возможно этот код чем-то не оптимальный, т.к. я тут ещё новичок, но во всяком случае он компилируется и моделируется правильно. Так вот вопрос: как будет выглядеть его аналог на VHDL и в чём возможны его преимущества в таком простом случае? K>Меня в твоём коде сразу напрягло умножение (в общем случае это ОЧЕНЬ дорогая операция в железе), но всем известно, что умножение на 4 можно заменить на сдвиг влево на 2 позиции. И мне стало интересно, известно ли это синтезатору. Потому я скормил твой код ИДЕ Vivado 2017.2. Изучив схему, которую он сгенерил, убедился, что он в курсе
Ну вообще то там есть и умножение на 3, так что если уж заниматься тут какими-то оптимизациями, то скорее через замену на сложение. ) Или тогда уж вообще переделать весь алгоритм, создав "вложенный цикл" или же конечный автомат. )
K>Но в целом я согласен с другим комментатором, что код написан чисто софтовый, и несколько gotchas верилога ты таки словил Я просто заменил блокирующие присваивания на неблокирующие, и на этом съэкономил около 50 LUTов
Возможно. ) Просто прежде чем научиться писать оптимальный код, надо в начале научиться писать просто работающий. )))
_>>И далее, если мы захотим усложить задачу, подключив скажем какую-то реализацию i2c (естественно готовую, т.к. писать самим такое странно) для установки значения period, то с помощью какого инструмента это будет проще сделать? K>http://www.xilinx.com/support/documentation/ip_documentation/axi_iic/v2_0/pg090-axi-iic.pdf Он уже memory-mapped.
Угу, похоже на то что надо. И кстати там у них все файлы и примеры заданы в VHDL... )
K>Хотя контроллер i2c стоит руками написать хотя бы однажды в качестве тренировки/обучения, т.к. он достаточно прост для того, чтобы новички его смогли осилить, но при этом включает в себя много важных концепций, которые применяются при работе с ПЛИС — работа с разными clock domain'ами, tri-state буферы, являющиеся и входом, и выходом, генерация тактовой частоты для внешнего устройства, работа с памятью/FIFO. На всяких обучалках часто его пишут после UART'а, который вообще является классикой ПЛИС-дизайна. Так что крайне рекомендую попробовать написать самому!
Возможно это имеет смысл со временем. ) Если серьёзно пойдём в данном направление...
Здравствуйте, alex_public, Вы писали:
_>Ну вообще то там есть и умножение на 3, так что если уж заниматься тут какими-то оптимизациями, то скорее через замену на сложение. ) Или тогда уж вообще переделать весь алгоритм, создав "вложенный цикл" или же конечный автомат. )
Синтезатор и сделал что-то подобное КА.
_>Угу, похоже на то что надо. И кстати там у них все файлы и примеры заданы в VHDL... )
Это как раз к тому, что я сказал выше — внутри проектов можно без проблем сочетать компоненты, написанные на разных языках. Так что вопрос языка в настоящее время по большому счёту дело личного вкуса и предпочтений.
_>Возможно это имеет смысл со временем. ) Если серьёзно пойдём в данном направление...
Нет, такие вещи стоит начинать делать как можно раньше, ибо они на очень простых примерах учат многим концепциям, которые применяются во всех проектах. Со временем такие вещи будешь писать с закрытыми глазами во время обеденного перерыва
_>Ну железки то мы тоже делаем (включая разводку своих плат и т.п.), только пока без всяких ПЛИС. Хотя я действительно больше специализируюсь на коде (но в силу положения приходится на определённом уровне разбираться во всём). Кстати, а в чём именно видны особенности программиста? Любопытно просто... )))
Для тех кто приходит в ПЛИС из программиривания (и для меня в том числе), основной ошибкой является что мы воспринимаем VHDL или верилог как язык программирования. На самом деле это язык описания логики, которая синтетизируется из написанного кода. То есть при написании любого выражения, надо иметь хоть какое-то представление как это будет выглядеть в железе (в логике). Железячники, как они мне рассказывали, так и делают.
Для меня, например, сразу бросилось в глаза period*4 в трёх местах. я бы для этого взял отдельный сигнал (VHDL).
Здравствуйте, VladCore, Вы писали:
VC>Темную энергию или хотя бы темную мaтерию нормально ловит? Не вижу ни одной антенны
Для этого есть разъёмы расширения
VC>И где езернет?
А нафиг он нужен-то? Я честно говоря ещё ни в одном своём проекте проводную сетку не использовал. Если нужно было подключение к инету, то ставил WiFi-модуль WINC1500. Проводная сетка — это каменный век, учитывая, что мне не нужна бешеная скорость передачи данных. Да и потом 1/10 G MAC IP денег стоит, нашару Xilinx даёт тока 10/100 Mbit сетку. Если потребуется высокоскоростной канал к "большому" компу, то проще заюзать чип FT600/601/602 и подключиться через USB 3. На текущей плате я развёл только USB 2.0 из-за уменьшения риска фейла, т.к. чипы FT60X дорогие, в то время как протокол обмена данных у них концептуально аналогичен — просто больше параллельных линий (16/32 против восьми у FT221X), и намного выше тактовая частота (100 МГц против 12). Так что текущая плата послужит нормальным полигонов для экспериментов Я вот подумываю собрать второй экземпляр платы с более "просторным" ПЛИСом XC7A35T-1FTG256C, а также распаять всю плату, в т.ч. и блок питания — а то с текущей платой как-то геморно с двумя раздельными платами. И ещё я по-прежнему вынашиваю план сделать версию платы с полноценным DDR3 вместо HyperRAM Пока жаба душит выкладывать ~$200 за шестислойку, а на четырёхслойке что-то я пока ниасилил развести DDR3 с соблюдением всех его требований Если асилю сделать на четырёхслойке (ну или уговорю свою жабу на шестислойку ), то попробую сделать.
Здравствуйте, Iso12, Вы писали:
I>Для тех кто приходит в ПЛИС из программиривания (и для меня в том числе), основной ошибкой является что мы воспринимаем VHDL или верилог как язык программирования. На самом деле это язык описания логики, которая синтетизируется из написанного кода. То есть при написании любого выражения, надо иметь хоть какое-то представление как это будет выглядеть в железе (в логике). Железячники, как они мне рассказывали, так и делают.
+1, хоть и с одной БОЛЬШОЙ оговоркой, имя которой HLS Там надо тупо зазубрить "правила хорошего тона" при написании кода, описанные в мануале к софтине (я как раз в отпуске читал его, когда появлялась свободная минутка), и неукоснительно им следовать. Ибо хотел бы я посмотреть на человека, который смог бы "представить" в логике схему, скажем, hls::Dilate()
I>Для меня, например, сразу бросилось в глаза period*4 в трёх местах. я бы для этого взял отдельный сигнал (VHDL).
Это на самом деле не так важно, т.к. синтезаторы нынче весьма умные, и сами догадываются провести подобные оптимизации — Vivado 2017.2 уложил этот код в чуть больше сотни LUT и с полсотни регистров (а после замены блокирующих присваиваний на неблокирующие стало где-то на треть LUT'ов меньше). Даже в самом слабом Артиксе (который я как раз и поставил на плату) 2600 слайсов (== 10400 LUT и 20800 регистров, причём LUT'ы у него шестивходные), так что это всё экономия на спичках по большому счёту. Другое дело, что к правильным приёмам кодирования стоит привыкать сразу, ибо позже будет сложнее "ломать" уже оформившиеся привычки.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, VladCore, Вы писали:
VC>>Темную энергию или хотя бы темную мaтерию нормально ловит? Не вижу ни одной антенны K>Для этого есть разъёмы расширения
VC>>И где езернет? K>А нафиг он нужен-то? Я честно говоря ещё ни в одном своём проекте проводную сетку не использовал. Если нужно было подключение к инету, то ставил WiFi-модуль WINC1500. Проводная сетка — это каменный век, учитывая, что мне не нужна бешеная скорость передачи данных. Да и потом 1/10 G MAC IP денег стоит, нашару Xilinx даёт тока 10/100 Mbit сетку. Если потребуется высокоскоростной канал к "большому" компу, то проще заюзать чип FT600/601/602 и подключиться через USB 3. На текущей плате я развёл только USB 2.0 из-за уменьшения риска фейла, т.к. чипы FT60X дорогие, в то время как протокол обмена данных у них концептуально аналогичен — просто больше параллельных линий (16/32 против восьми у FT221X), и намного выше тактовая частота (100 МГц против 12). Так что текущая плата послужит нормальным полигонов для экспериментов Я вот подумываю собрать второй экземпляр платы с более "просторным" ПЛИСом XC7A35T-1FTG256C, а также распаять всю плату, в т.ч. и блок питания — а то с текущей платой как-то геморно с двумя раздельными платами. И ещё я по-прежнему вынашиваю план сделать версию платы с полноценным DDR3 вместо HyperRAM Пока жаба душит выкладывать ~$200 за шестислойку, а на четырёхслойке что-то я пока ниасилил развести DDR3 с соблюдением всех его требований Если асилю сделать на четырёхслойке (ну или уговорю свою жабу на шестислойку ), то попробую сделать.
Я пока не все прочитал, но ты хочешь в новый ПЛИС с аж 32-мя тысячами транзисторов и 200 килобайтами памяти/кеша за 34 доллара и частотой всего 100 мегагрец воткнуть DDR3?
как говорят школьники: два чая этому господину/месье
Здравствуйте, VladCore, Вы писали:
VC>Я пока не все прочитал, но ты хочешь в новый ПЛИС с аж 32-мя тысячами транзисторов и 200 килобайтами памяти/кеша за 34 доллара и частотой всего 100 мегагрец воткнуть DDR3?
В XC7A35T 5200 слайсов (каждый слайс содержит 4 6-входовых LUT и 8 регистров, итого выходит 20800 LUT и 42600 регистров), и памяти там 1.8 Kb (в виде BlockRAM, ещё можно добавить на регистрах). Что же касается частоты, то в зависимости от спидгрейда он может работать с DDR3 на частоте до 1066 МГц (с помощью 4:1 IO FIFO, сам контроллер работает на частоте в четверть частоты памяти). Меня в настоящий момент устроит даже минимальная частота (667 МГц). Хотя в принципе все чипы в этом корпусе пин-совместимы (вплоть до XC7A100T, в которой 15850 слайсов == 63400 LUT/126800 регистров), так что можно будет в дальнейшем поставить и более "толстую" ПЛИСку.
Собственно, у меня есть вот эта платка с чипом XC7A35T, и DDR3L там прекрасно работает
Здравствуйте, alex_public, Вы писали:
_>Возможно этот код чем-то не оптимальный, т.к. я тут ещё новичок, но во всяком случае он компилируется и моделируется правильно. Так вот вопрос: как будет выглядеть его аналог на VHDL и в чём возможны его преимущества в таком простом случае?
Набросал на досуге ваш пример на VHDL. Так как я тут тоже новичок за идеальность кода не ручаюсь. Код не тестировал.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity mc_module is
Port(
CLK_IN : in STD_LOGIC;
PERIOD_IN : in STD_LOGIC_VECTOR (15 downto 0);
W1_OUT : out STD_LOGIC;
W2_OUT : out STD_LOGIC
);
end mc_module;
architecture Behavioral of mc_module is
signal Counter : integer range 0 to 2**16-1 := 0;
signal Period : integer range 0 to 2**16-1 := 0;
signal Period2 : integer range 0 to 2**16-1 := 0;
signal Period3 : integer range 0 to 2**16-1 := 0;
signal Period4 : integer range 0 to 2**16-1 := 0;
begin
PROC_BEH: process (CLK_IN)
begin
if (rising_edge(CLK_IN) )
then
Period <= to_integer(unsigned(PERIOD_IN));
Period2 <= to_integer(unsigned(PERIOD_IN))*2;
Period3 <= to_integer(unsigned(PERIOD_IN))*3;
Period4 <= to_integer(unsigned(PERIOD_IN))*4;
if(Counter<Period4)
then
if(Counter = 0)
then
W1_OUT <= '1'; W2_OUT <= '0';
elsif(Counter = Period )
then
W1_OUT <= '1'; W2_OUT <= '1';
elsif(Counter = Period2)
then
W1_OUT <= '0'; W2_OUT <= '1';
elsif(Counter = Period3)
then
W1_OUT <= '0'; W2_OUT <= '0';
end if;
else
Counter <=0;
end if;
end if;
end process PROC_BEH;
end Behavioral;
Здравствуйте, koandrew, Вы писали:
_>>Ну вообще то там есть и умножение на 3, так что если уж заниматься тут какими-то оптимизациями, то скорее через замену на сложение. ) Или тогда уж вообще переделать весь алгоритм, создав "вложенный цикл" или же конечный автомат. ) K>Синтезатор и сделал что-то подобное КА.
Кстати, тот код, что я привёл, был написал как раз когда мы с тобой это обсуждали в последний раз и я начал пробовать самые первые шаги в этой области. И с тех пор я его не трогал. А сейчас взглянул ещё раз и свежим взглядом сразу переписал его вот так (внутренний регистр убрал в пользу размещения его в i2c модуле):
module MC(input clk, input[15:0] period, output reg w1=0, output reg w2=0);
reg[15:0] r_counter=0;
reg[1:0] r_state=0;
always @(posedge clk) begin
case(r_state)
0: begin w1<=1; w2<=0; end
1: begin w1<=1; w2<=1; end
2: begin w1<=0; w2<=1; end
3: begin w1<=0; w2<=0; end
endcase
r_counter=r_counter+1;
if(r_counter>=period) begin
r_counter<=0;
r_state<=r_state+1;
end
end
endmodule
По идее это должно быть логичнее и оптимальнее (результат моделирования такой же как и у предыдущего кода). Хотя, как ты сам показывал, с учётом мощности современных оптимизаторов это всё не принципиальные развлечения. )
_>>Угу, похоже на то что надо. И кстати там у них все файлы и примеры заданы в VHDL... ) K>Это как раз к тому, что я сказал выше — внутри проектов можно без проблем сочетать компоненты, написанные на разных языках. Так что вопрос языка в настоящее время по большому счёту дело личного вкуса и предпочтений.
Так я бы хотел взять готовый модуль и потом возможно что-то поменять в нём под себя. На незнакомом языке это будет не так комфортно...
Здравствуйте, Iso12, Вы писали:
I>Для тех кто приходит в ПЛИС из программиривания (и для меня в том числе), основной ошибкой является что мы воспринимаем VHDL или верилог как язык программирования. На самом деле это язык описания логики, которая синтетизируется из написанного кода. То есть при написании любого выражения, надо иметь хоть какое-то представление как это будет выглядеть в железе (в логике). Железячники, как они мне рассказывали, так и делают.
Ну собственно все инструменты для синтеза позволяют вывести графическое отображение результата синтеза — по сути принципиальную схему. Только вот для всех случаев сложнее пары битовых операций это выглядит бесполезным ввиду огромности и не структурированности результата. Потому как при нормальной работе с принципиальными схемами человек обычно оперирует более высокими абстракциями (даже если они в итоге задаются не отдельными микросхемами): всяческими там сумматорами, дешифраторами и т.п. А синтезатор для ПЛИС очевидно оперирует только базовыми вентилям и соответственно делает схему исключительно из них — разглядывать такое обычно бесполезно. )
Здравствуйте, Iso12, Вы писали: I>Набросал на досуге ваш пример на VHDL. Так как я тут тоже новичок за идеальность кода не ручаюсь. Код не тестировал.
код
I>
I>library IEEE;
I>use IEEE.STD_LOGIC_1164.ALL;
I>use IEEE.NUMERIC_STD.ALL;
I>entity mc_module is
I> Port(
I> CLK_IN : in STD_LOGIC;
I> PERIOD_IN : in STD_LOGIC_VECTOR (15 downto 0);
I> W1_OUT : out STD_LOGIC;
I> W2_OUT : out STD_LOGIC
I> );
I>end mc_module;
I>architecture Behavioral of mc_module is
I> signal Counter : integer range 0 to 2**16-1 := 0;
I> signal Period : integer range 0 to 2**16-1 := 0;
I> signal Period2 : integer range 0 to 2**16-1 := 0;
I> signal Period3 : integer range 0 to 2**16-1 := 0;
I> signal Period4 : integer range 0 to 2**16-1 := 0;
I>begin
I>PROC_BEH: process (CLK_IN)
I> begin
I> if (rising_edge(CLK_IN) )
I> then
I> Period <= to_integer(unsigned(PERIOD_IN));
I> Period2 <= to_integer(unsigned(PERIOD_IN))*2;
I> Period3 <= to_integer(unsigned(PERIOD_IN))*3;
I> Period4 <= to_integer(unsigned(PERIOD_IN))*4;
I> if(Counter<Period4)
I> then
I> if(Counter = 0)
I> then
I> W1_OUT <= '1'; W2_OUT <= '0';
I> elsif(Counter = Period )
I> then
I> W1_OUT <= '1'; W2_OUT <= '1';
I> elsif(Counter = Period2)
I> then
I> W1_OUT <= '0'; W2_OUT <= '1';
I> elsif(Counter = Period3)
I> then
I> W1_OUT <= '0'; W2_OUT <= '0';
I> end if;
I> else
I> Counter <=0;
I> end if;
I> end if;
I> end process PROC_BEH;
I>end Behavioral;
I>
Ну в принципе по синтаксису не вижу каких существенных отличий в одну или другую сторону. Да, записывается немного другими словами, но в принципе та же информация и в том же объёме. Видимо на таком простом примере понять разницу трудно. Единственное, что кажется сомнительным: зачем задавать значения сигналов литералами (я про '0' и '1')?
_>Ну в принципе по синтаксису не вижу каких существенных отличий в одну или другую сторону. Да, записывается немного другими словами, но в принципе та же информация и в том же объёме. Видимо на таком простом примере понять разницу трудно. Единственное, что кажется сомнительным: зачем задавать значения сигналов литералами (я про '0' и '1')?
Сигнал std_logic в VHDL имеет не только значения 0 и 1 , а также:
'U', -- Uninitialized
'X', -- Forcing Unknown
'0', -- Forcing 0
'1', -- Forcing 1
'Z', -- High Impedance
'W', -- Weak Unknown
'L', -- Weak 0
'H', -- Weak 1
'-' -- Don't care
Здравствуйте, Iso12, Вы писали:
_>>Ну в принципе по синтаксису не вижу каких существенных отличий в одну или другую сторону. Да, записывается немного другими словами, но в принципе та же информация и в том же объёме. Видимо на таком простом примере понять разницу трудно. Единственное, что кажется сомнительным: зачем задавать значения сигналов литералами (я про '0' и '1')?
I>Сигнал std_logic в VHDL имеет не только значения 0 и 1 , а также: I>'U', -- Uninitialized I>'X', -- Forcing Unknown I>'0', -- Forcing 0 I>'1', -- Forcing 1 I>'Z', -- High Impedance I>'W', -- Weak Unknown I>'L', -- Weak 0 I>'H', -- Weak 1 I>'-' -- Don't care
Ну как бы в verilog'е тоже не только 0 и 1, но при этом использование литералов не требуется. Вообще для какого-нибудь чисто vhdl программиста это наверное и не проблема, но для меня значения вида 'Z' обычно на автомате ассоциируется с определённым байтом данных... )
Кстати, а если вдруг писать под ПЛИС какую-то работу со строками (хотя это конечно совсем не подходящее направление, но всё же), то это разве не будет путать?
Здравствуйте, alex_public, Вы писали: _>Ну как бы в verilog'е тоже не только 0 и 1, но при этом использование литералов не требуется.
Да в Верилоге много чего не требуется, отсюда и куча ошибок, которые не ловятся компилятором.
_> Вообще для какого-нибудь чисто vhdl программиста
vhdl-программистов не существует. Как и Верилог-программистов.
_>Кстати, а если вдруг писать под ПЛИС какую-то работу со строками (хотя это конечно совсем не подходящее направление, но всё же),
В ПЛИС никаких строк нет. Вам явно придётся ковертировать character (впрочем, как и любой другой перечислимый тип) в какой-то вектор (std_logic_vector или bit_vector).
> то это разве не будет путать?
character такой же перечислимый тип, как и std_logic. Никакой путаницы не будет, поскольку существует перегрузка функций и нужная функция будет выбрана по типам аргументов и возвращаемого значения. Если подходящей функции не найдётся, надо будет явно сделать приведение типа.
Здравствуйте, rising_edge, Вы писали:
_>Здравствуйте, alex_public, Вы писали: _>>Ну как бы в verilog'е тоже не только 0 и 1, но при этом использование литералов не требуется. _>Да в Верилоге много чего не требуется, отсюда и куча ошибок, которые не ловятся компилятором.
И в чём тут видится потенциальная ошибка? )
_>>Кстати, а если вдруг писать под ПЛИС какую-то работу со строками (хотя это конечно совсем не подходящее направление, но всё же), _>В ПЛИС никаких строк нет. Вам явно придётся ковертировать character (впрочем, как и любой другой перечислимый тип) в какой-то вектор (std_logic_vector или bit_vector).
Я говорю не про хранилище данных, а про задание констант в языке. В том же VHDL имеется и тип Character и тип String: https://www.csee.umbc.edu/portal/help/VHDL/types.html.
>> то это разве не будет путать? _>character такой же перечислимый тип, как и std_logic. Никакой путаницы не будет, поскольку существует перегрузка функций и нужная функция будет выбрана по типам аргументов и возвращаемого значения. Если подходящей функции не найдётся, надо будет явно сделать приведение типа.
Речь не про путаницу компилятором, а про путаницу человеком.
Здравствуйте, koandrew, Вы писали:
K>Потому нужен какой-нить кодировщик. Коммерческие IP с такой функциональностью стоят немалых денег, но зато они в большинстве своём "plug-and-play", то есть их интеграция обычно не представляет особой сложности. А вот с open source'ными ситуация неособо. В принципе, можно запилить какой-нить H.264 кодировщик самостоятельно (насколько я помню, там алгоритм не особенно сложный), но в любом случае это займёт массу времени.
Комповая USB 2.0 камера с H.264 не подойдёт? Она правда (у меня логитек) 50/50 вешает мне комп в начале загрузки. 2 камеры, линух, GPGPU. Один комп может управлять твоим станком. Но вообще непонятно, зачем тебе высокое разрешение, почему 20x20 пикселов не хватит. И ещё непонятно, зачем тебе это надо- какая конечная цель.
Здравствуйте, Тёмчик, Вы писали:
Тё>Комповая USB 2.0 камера с H.264 не подойдёт? Она правда (у меня логитек) 50/50 вешает мне комп в начале загрузки. 2 камеры, линух, GPGPU. Один комп может управлять твоим станком. Но вообще непонятно, зачем тебе высокое разрешение, почему 20x20 пикселов не хватит. И ещё непонятно, зачем тебе это надо- какая конечная цель.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Тёмчик, Вы писали:
Тё>>Комповая USB 2.0 камера с H.264 не подойдёт? Она правда (у меня логитек) 50/50 вешает мне комп в начале загрузки. 2 камеры, линух, GPGPU. Один комп может управлять твоим станком. Но вообще непонятно, зачем тебе высокое разрешение, почему 20x20 пикселов не хватит. И ещё непонятно, зачем тебе это надо- какая конечная цель. K>
Ты не лицо хлопай, а подумай, что сделать что-то разумное с изображением- нужно понимать алгоритмы. Без разницы, как ты получил это изображение. Когда будет работать с пользой, будешь думать как это дёшево тиражировать.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ты не лицо хлопай, а подумай, что сделать что-то разумное с изображением- нужно понимать алгоритмы.
Вот я и вижу, что ты их нифига не понимаешь. Потому и Тё>Без разницы, как ты получил это изображение. Когда будет работать с пользой, будешь думать как это дёшево тиражировать.
Если нет изображения, то и обрабатывать нечего
), но я отрезал лишнее, и программатор всё равно нормально подключается. Урок на будущее — читать внимательнее раздел пайки в даташите 
Разъём для такого подключения я предусмотрел во второй ревизии платы, также исправил целую кучу косяков первой ревизии — кривой футпринт чипов памяти и флеша, выбрал неправильный пин ПЛИСа для входного тактового сигнала 
, неправильное подключение кнопок 
Вот ради этих эмоций я всё это и делаю! 
И где езернет? 
Если асилю сделать на четырёхслойке (ну или уговорю свою жабу на шестислойку 
