Поиск

Город Москва Оплата 250000 за проект Работа по договору с физлицом. Срок на изготовление три месяца. Дальнейшая платная поддержка при необходимости. ТЗ прилагается. Решается задача кодирования и декодирования цифровой информации по заданному алгоритму. Необходимо разработать прошивки для кодера (Digilent Cmod A7-35T) и декодера (Zynq 7020 + Digilent Pmod DA3 + Analog Devices EVAL-AD9467), а также тестовое ПО для Linux, совместимое с Raspberry Pi 2, или же API для доступа к устройствам из-под Linux. Техническое_задание_на_программный_комплекс_кодирования_и_декодирования_цифровой_информации.pdf

Есть готовые устройства на Xilinx Zinq 7010, надо как-то защитить прошивку от реверс инжиниринга, копируют пока ладно, пусть. без модификации плат. Желательно чтоб можно было стандартными имеющимися средствами обновить прошивку (уже есть это, линукс стоит, можно и u-boot обновить). Идеи - так как устройства IoT, на связи с нашими серверами, можно через защищенный канал что-то делать, например после обновления подгружать сгенерированную прошивку именно для этого чипа по защищенному каналу. Есть под них прошивка с U-BOOT, исходники. Прошивка должна будет загружаться как и сейчас для обновления по HTTP, а также иметь механизм возврата на старую (незащищенную) стандартную версию. Мы в Москве, возможна удалённая работа, образцы железяк дадим или организуем удалённый доступ. Сроки и бюджет обсуждаемы. может поможет https://www.xilinx.com/support/documentation/application_notes/xapp1226-protecting-info.pdf

Приветствую! Для конфигурации ИМС используем набор регистров, доступных по интерфейсу SPI. Регистры бывают разной длины (как правило, не больше 14 бит), отдельные поля внутри регистров так же могут быть разной длины. Для первичного тестирования поведения чипа в статическом режиме я сделал форму, в которой содержимое отдельных полей каждого регистра может меняться на лету. Пример такой формы с картой регистров представлен на картинке ниже. Регистры расположены по вертикали, содержимое регистров (отдельных битовых полей) - по горизонтали. Внутри каждой ячейки отображено имя поля и его текущее значение. Принцип работы прост: оператор нажимает на ячейку, меняет значение, форма отсылает команду по SPI, оператор наблюдает, что происходит с ИМС и т.д. Для каждого проекта своя карта регистров, которая "подцепляется" к форме из JSON файла. Форма создавалась по-быстрому и, как это обычно бывает, так и осталась в первозданном виде. Хотелось бы сделать что-то более удобное или компактное, даже не знаю, что конкретно в этой не устраивает, но хочется, чтобы содержимое отображалось покомпактнее. Наверняка многие сталкивались с задачами удобного отображения конфигурации регистров. Буду рад, если кто-нибудь поделится своими или чужими визуальным решениями.

Отладочная плата BTU9P клон известной платы Xilinx VCU1525 FPGA Xilinx Ultrascale+ VU9P 12 штук., наличие в Москве 4000 долл. Платы оборудованы водоблоком, память DDR4 не установлена производителем.

Всем привет! Столкнулся со следующей проблемой: Vivado выдаёт предупреждения о том, что не может найти pins, cells, nets, прописанные в констрейнах, хотя оные объекты вроде на месте - это легко проверяется хоть через просмотр нетлиста, хоть через схематик, хоть через Tcl консоль, выдавая туда команды get_pins/get_cells/get_nets - ровно те, которые прописаны в констрейнах. Всё находится, всё на месте. Но при запуске, например, Synthesis, в окне Messages вижу: Интриги добавляет ещё то обстоятельство, что аналогичный констрейн на другой объект не вызывает такого поведения - там всё хорошо. Вот оба констрейна: create_generated_clock -name pcie_user_clk [get_pins pcie_port/pipe_clock_i/mmcm_i/CLKOUT2] create_generated_clock -name dpc_clk [get_pins dpc_clk_gen/inst/plle2_adv_inst/CLKOUT0] Это два простых констрейна для переименования клоков. Разница между ними в том, что первый относится к MMCM, находящейся внутри корки, а второй - к инстансу в проекте. Сам объект на месте (как уже выше указал), более того, по результату вижу, что клок-то таки переименовался (имеет указанное в констрейне имя). Вот оно на схеме (пин помечен маркером): В общем, заподозревал, что что-то тут, возможно, с порядком обработки данных - такое впечатление, что констрейн прикладывается в момент, когда ещё нетлист не готов и поэтому не находит объект (а в случае первого констрейна находит потому, что там в проект подтаскивается корка, синтезированная OOC, т.е. уже с нетлистом). Но если так, то как это разрулить? Никаких средств не нашёл, гугление тоже не помогло. Из-за этой же фигни не удаётся использовать waiver'ы - подобная ругань, что нет объектов (а они есть в результирующем нетлисте). В общем, обращаюсь к коллективному разуму и опыту.

Всем привет! Вот есть такой инструмент в Vivado как Block Diagram Editor, что делает в целом понятно - позволяет организовывать межсоединения между блоками/модулями/ядрами в наглядной графической форме. Мне как-то до сих пор подобные инструменты не очень пригождались - помнится, ещё на Active-HDL пробовал топ делать с помощью такой вот схемы (блок диаграммы), поначалу понравилось, но потом энтузиазм поугас - как-то многовато телодвижений лишних (чуть что поправить - эн мелких правок в разных местах), а главное, когда диаграмма становится большой, то уже линии соединений скорее мешают, чем помогают, и проще их (соединения) не таскать шинами/проводниками, а оформлять метками, что уже в значительной степени нивелирует красоту и эффективность схемного представления... А потом я просто научился инстансы модулей оформлять так, что читабельность практически не уступает вот такому схемному с метками. Но вот вижу, что Xilinx в своих примерах и design flow активно использует именно BD. Более того, обнаружил, что некоторые корки просто недоступны в виде отдельного ядра - например, AXI Interconnect инстанцируется только в BD, и отдельным ядром OOC его сделать нельзя, хотя его составные компоненты - Crossbar, Clock Converter, Data Width Converter и прочие, - вполне можно получить виде отдельных ядер и подключить их к проекту как обычно. Кроме того, насколько знаю, тяжёлые ядра типа Microblaze или Zynq подключаются к проекту тоже только через BD. И вот возникает вопрос: насколько это нужный и полезный инструмент в повседневной работе? Попытаюсь изложить в меру своего понимания темы плюсы и минусы BD'шного подхода. Плюсы: Наглядность межсоединений. Хотя при росте схемы она резко падает. Может немного спасти ведение иерархии - чтобы на каждом уровне было вменяемое количество "кубиков" и их связей, но и тут есть засада - при большом проекте возрастает количество уровней иерархии, что затрудняет навигацию и вообще мысленный охват проекта. Возможность лёгкого манипулирования большим количеством портов, группируя их в шины - как, например, сигналы AXI шины. Средства автоматизации - редактор BD автоматически отслеживает неподключенные порты и устанавливает на них значения по умолчанию. Минусы: Некоторое усложнение проекта - ещё один уровень выше HDL. Не все типы файлов поддерживаются - например, .sv исходники не поддерживаются, только .v, .vhd, т.е. если у меня код на SystemVerilog, то для того, чтобы из модуля родить "кубик" для BD, мне нужно сделать специальный файл-обёртку вокруг исходного модуля. Хуже переносимость. Если HDL сорцы можно напрямую передавать в другой проект на синтез и симуляцию, то с файлом диаграммы уже не так просто - сам этот файл вне среды САПР Vivado никому не нужен, а если сгенерить по нему исходник, то он получается в не очень читабельном и сопровождабельном руками виде. Для меня в первую очередь значимым является способность легко и просто работать с портами. И вот если бы редактор BD умел извлекать из SV интерфейсов сигналы (а лучше бы просто использовал их как есть), то это было бы очень круто! Но идея с файлом-обёрткой на Verilog как-то не очень греет. Для сугубо вериложных файлов BD, наверное, и даёт заметный профит - автоматом подхватывает все сигналы модуля и всё хорошо, но в SV есть замечательная штука - интерфейсы, которые позволяют свести количество портов модуля к минимуму, сделать использование сигналов портов простым и безопасным, а кроме этого ещё и местами нетривиальную логику завернуть внутри интерфейса. И вот тут-то пожалуй главный профит BD нивелируется и превращается балласт (необходимость городить врапперы вокруг модуля и руками мапить сигналы интерфейсов на порты модуля-обёртки). Вопросы внешнего вида (наглядности, лёгкости восприятия и удобства модификации) на HDL вполне решаются стилем форматирования экземпляров модулей, а поддержка интерфейсов позволяет легко получить компактные описания. В общем, пока не понял хорошенько, в чём профит BD, какие у него есть киллер-фичи. Но ведь широко используют, и это, наверное, неспроста. Прошу высказываться по теме - что сказано верно, а что нет, что-то упущено, а что-то наоборот "в точку". Кто пользуется BD, для каких проектов (всегда, никогда, только для больших и т.д.), на каких уровнях иерархии (только топ или какие-то внутренние куски иерархии) и вообще интересны мнения и оценки имеющих реальный опыт работы с этим.

Всем привет! С Xilinx ранее работать серьёзно не приходилось, всё больше была Altera, поэтому нахожусь в процессе набора опыта и познания особенностей FPGA Xilinx и её САПР Vivado. Текущий проект: Artix-7 xc7a200t, Vivado 2018.2. По результатам очередной сборки развалились времянки: тактовый домен 4 нс (250 МГц), слак по сетапу порядка 0.8 нс. Смотрю, на чём просело, вижу, задержку пути на логике 1.269 нс, на трассировке 3.229. Логики там реально немного, поэтому и странно, что не уложилось. Открываю Device, и вижу, что вивада утащила часть логики модуля в другой Clock Region, отсюда и такая конская задержка (плоховато, но видно беленьким показан путь). Никакими изменениями стратегий ситуацию исправить не удалось. Вообще, ситуация представляется достаточно простой - кристалл почти пустой, и места для логики в левом Clock Region и под ним полно. Зачем же плейсер рассовал логику так, что трассировщик потом уже ничего не может исправить? Ну, делать нечего, пришлось применить ручное назначение потрохов модуля в pblock. После этого всё получилось, времянки сошлись и на дивайсе всё выглядит компактно, логично и красиво. Собственно вопрос: это правильный подход и нормальная практика для Xilinx/Vivado или это костыльно и правильно всё же как-то вызвать интеллект САПР из сумрака, чтобы она сама соображала, как размещать, чтобы проект разводился без фейлов? Просто на Altera/Quartus не помню случая, чтобы приходилось фиксить работут фиттера - он всегда сам справлялся лучше (а попытки лезть к нему напрямую только мешали). P.S. Вдогонку штрих: без констрейна на pblock длительность сборки: синтез: 0:33 P&R: 2:19 и в итоге времянка не сходится. с pblock'ом: синтез: 0:33 P&R: 1:38 и времянка в норме.

Имеется плата - FPGA Spartan 6 LX9, к ней присобачена SDRAM IS42S81600F-7TL. Частота CLK 128 МГц, CL=3, BL=1. Режим работы такой - прилетают данные, их записываем в SDRAM, вместо них вычитываем из SDRAM другие данные. Пока пакетов данных нет - крутим AUTOREFRESH с периодом примерно 90 нс. Столкнулся с вот какой неприятной проблемой - первое чтение после авторефреша почему-то задерживается - шина DQ из третьего состояния переходит в активное с опозданием, в результате я читаю не то, что должно быть прочитано, а то, что осталось висеть на шине после предыдущей записи. Потом идут ещё 300 с лишним циклов записи-чтения, они пишутся и читаются идеально, без вопросов. Проблема только с первым чтением после простоя, заполненного авторефрешами. Сдвигаю фазу клока стробирования чтения - становится заметно лучше, но не насовсем. Если при нулевой задержке все первые чтения неверные (но последующие чтения правильные!), то при задержке 1.9 нс неверных чтений остаётся где-то четверть, при задержке 2.9 нс неверных чтений процентов 10, задержка 3.9 нс - это уже перебор. Кто сталкивался с чем-то подобным?

https://github.com/MadLittleMods/FP-V-GA-Text/blob/master/vgaText/vgaText_top.vhd (справочник по vhdl есть) помогите , растолкуйте что значит точка в drawElementArray(i).pixelOn что оно вообще такое , как работает (если это важно разрабатываю vga контролер для древней spartan3e kit , гитхаб не мой , пытаюсь разобраться с выводом текста) -- Text Draw Stack ----------------- for i in drawElementArray'range loop if drawElementArray(i).pixelOn then rgbDrawColor := drawElementArray(i).rgb; end if; end loop;