Raven

И что, в Vivado 2018.3 не поддерживается эта DDR память? Что-то не верится.

У Терраэлектроники на складе - необходимый буферный запас, так что продают с небольшим лагом свежее, то, что в тренде от Segger'а. Я еще в августе-сентябре у них заказывал, пришел v11.

Ничего не меняет. Но я и не утверждал обратное. Я лишь указал, что их наполнение (этих процедур, файлы, их содержащие) все равно надо будет прописывать в проекте, а именно этого ТС пытается избежать, пытаясь заинклудить ассемблерный файл в общую сборку.

Терраэлектроника

Смотря что считать костылями. Изменять естественный интерфейс модуля только для того, чтобы вытащить из него сигналы для использования в тест-бенче - по мне, так именно это и есть костыль.

Все эти void NMI_Handler() __attribute__ ((weak, alias ("Default_Handler"))); void HardFault_Handler() __attribute__ ((weak, alias ("Default_Handler"))); void SVC_Handler() __attribute__ ((weak, alias ("Default_Handler"))); вполне могут быть ссылками на ассемблерные процедуры.

Путь суровый, не для новичка. И ведь все равно где-то в проекте нужно будет прописывать файл, содержащий все эти ассемблерные процедуры.

Это называется кросс-иерархический доступ к объектам в других модулях. Применяется как раз в симуляции (в поведенческом коде), именно для того, о чем вы спрашиваете. Смотрите учебник или стандарт.

Если вы про то сообщение об ошибке, которое в стартовом сообщении,- то похоже, в вашем бит-файле просто нет ILA составляющей (несмотря на наличие ltx-файла в результатах компиляции). А вот почему - внимательно посмотрите сообщения при сборке.

Вот уважаемый товарищ Столяров (ПРОГРАММИРОВАНИЕ: ВВЕДЕНИЕ В ПРОФЕССИЮ) со знанием дела предлагает следующий маршрут: 1. Начинаем с Паскаля - основы алгоритмизации, начала программирования, знание языка не всеобъемлющее, а лишь доводится до областей, позволяющих перебросить впоследствии мостик к указателям в Си. 2. Далее - ассемблер (опять же, в нужном объеме, без фанатизма). Это подходящее время (основы пройдены, надо всерьез двигаться дальше) окунуться в то, как на самом деле выполняются программы процессором и во всю низкоуровневую кухню. Дальше - уже будет поздно возвращаться к этому. И наоборот, обучаемый лучше будет понимать дальнейший материал, понимая, как оно на самом деле устроено. 3. Далее - Си со всем его джазом (указатели теперь проходятся и понимаются совершенно естественно). 4. Далее - все прочие парадигмы программирования (и у Столярова есть что почитать на эти темы). В принципе, я с ним согласен. Возможно, п.1 в современной действительности можно было бы поменять на Питон, но это еще выверять надо (как там будет организована смысловая связка с последующим изучением ассемблера и Си). А Паскаль в описываемом объеме (не до самых до окраин, а лишь как начальный материал для изучения алгоритмизации) - самое то. Ведь это, на минуточку, и была одна из целей создания этого языка (обучение программированию).

А что мешает взять и скомпилировать тестовый проект перед тем, как бросаться проектировать плату? И удостовериться, что не только нужное вам ядро, но и нужная вам _периферия_ влезет туда? Как дети, ей-же-ей!

Т.е., после перехода под руку Microchip, PIC'овские адаптеры тоже поддерживаются для общения с AVR'ми? И какие PICkit'ы можно для этого использовать? PICkit-2 и -3 поддерживаются в ATMEL Studio 7 для работы с AVR?

Лучше немного по-другому идею использования выстроить. Надо иметь 2 аккум. порта (возможно, полностью равнозначных), но в ходе регулярной эксплуатации аккумулятор подключен только к одному из них. Если приходит время замены, вначале подключается второй аккум. ко второму порту, производится ввод его в работу, а затем снимается с работы и выключается первый. И только что поставленный может оставаться на порту B до прихода его времени замены. Потом все повторяется с поправкой на имя порта.

Как уже и сказали, такое кол-во земель нужно для обеспечения хорошего качества сигналов, что особенно важно на высоких скоростях передачи данных. Эти разъемы предназначены для подключения через плоский кабель, и в нем сигнальные линии при соответствующем pin-out'е будут чередоваться с линиями общего провода. Это улучшает качество сигналов в нескольких смыслах: делает линии передачи однородными (уменьшается головная боль в связи с отражениями фронтов сигналов - хотя бы канал передачи теперь не вносит их, остается только рассогласование в источнике/приемнике, но тут уж извольте согласовывать, хотя бы последовательно в источнике) кратно снижает взаимные емкостные наводки между сигнальными линиями. Последний фактор очень важен, т.к. сильно снижает взаимное влияние TCK и TMS в JTAG, например. Напомню, что в JTAG переключение машины состояний происходит как раз в зависимости от значения TMS по фронтам TCK. Если фронт TCK из-за наводки исказит значение TMS, машина состояний пойдет совсем не туда, куда хотелось бы, со всеми вытекающими последствиями в виде дальнейшего необъяснимого поведения подключенной debug-подсистемы (которое быстро заканчивается такой же непонятной ошибкой, как правило). Кстати говоря, поскольку тут речь идет о фронтах сигналов, то эти наводки будут приводить к подобным сбоям и на совсем низких скоростях передачи (50-100 kHz, например - и это наблюдалось на практике). Просто их проявления придется ждать дольше (меньше действий/событий в единицу времени). Частота тактового сигнала в этом диапазоне частот (0 - 5 MHz) не важна, значение имеет степень емкостной наводки. Потому важно контролировать скорость нарастания фронтов, с одной стороны, и как-то экранировать сигнальные линии друг от друга - с другой. А при дальнейшем росте частоты тактового сигнала начнет помогать и первый фактор - однородность линий. Все это касается, конечно, и остальных сигналов, хотя и в значительно меньшей степени (не так критично, хотя бы для 0-5MHz диапазона). Обратите внимание на приведенную вами распиновку. Тот, кто ее создавал, явно был в курсе вышеописанной проблемы - TCK и TMS разделены аж 2-мя землями! Какие можно дать рекомендации? Варианты такие: 1) Ваша распиновка годится, если перевести ее на мЕньший разъем (с шагом 0.05" вместо 0.1" - это как раз тот, на который приводили ссылку - шаг 1.27 mm). 2) Сделать разъем CoreSight 10 pin с комбинацией SWD/JTAG сигналов (это все тот же разъем с 1.27мм шагом, только распиновка другая). Изоляция TCK/TMS (или SWCLK/SWDIO) похуже (но подтверждено - рабочая), зато разъем стандартный. 3) Сделать свой разъем с меньшим кол-вом контактов, уделив при этом особое внимание экранировке линии TCK (SWCLK) и созданию для нее наилучших условий распространения сигнала (лучше всего применить витую пару с отдельным проводом земли). Т.е., земель надо оставить хотя бы 2: одна для TCK twisted pair, и вторая - общая для всех остальных. P.S. И все же рекомендую вывести на разъем все JTAG сигналы (можно без nTRST - он опциональный). SWD - получите автоматически (использует подмножество пинов JTAG). Не исключено, что еще придется воспользоваться и Boundary Scan'ом - если будут проблемы с неконтактами на плате и т.п. Многоядерность в этих чипах не играет рояля в данном случае - доступ ко всем ядрам внутри чипа обеспечивается через общий входной SWJ-DP (в том числе - и через SWD), и далее через систему дебаг-шин (см. референс-мануал, секция 64, DBG block diagram). Вот если бы у вас на плате было несколько чипов с JTAG, да еще с неоходимостью оркестрировать их отладку из одного программного средства - тогда другое дело.

Да, тут я оказался невнимателен. Моя ошибка. Что ж, тогда вопрос переходит в плоскость формата SOF/POF файлов и алгоритма работы Quartus assembler. Вы их знаете, чтобы так удивляться множественным отличиям?

Поправьте, если я неправ: в этом году уже действует ограничение в 200 EUR стоимости посылки, которые не облагаются пошлиной. Все, что свыше - облагается неприятной по своему размеру пошлиной, да еще надо будет озаботиться тем, как ее этой таможне заплатить. Если для осциллоскопа ценой этак до 500$ еще можно, наверное, ввозить по такой схеме (и это даже будет, возможно, выгодно в сравнении с ценами в российских магазинах), то для прибора в 3500$ экономика процесса выглядит запретительной. Или я что-то не понимаю? Пока COViD не позакрывал границы, такой девайс можно было бы, наверное, заказать на адрес в ближнем зарубежье, а потом самому за ним съездить. Но теперь... большой вопрос.

А кто вам сказал, что в 2 разных прогонах результаты синтеза/P&R во всех "нетронутых" частях должны быть одинаковы? Здесь нет полного детерминизма. Алгоритмы эти таковы, что малое изменение в одном углу в общем случае может приводить к другим веткам принятия решений в алгоритме, и как результат - другие результаты в, казалось бы, несвязанных частях дизайна. Особенно, если включено что-то типа принудительной ротации seed'а в вызовах генерации random(), и прочие методы "растряски" процедур синтеза/роутинга.

Т.к. SVF-файл - это, по сути, скрипт из самых низкоуровневых JTAG-примитивов, то он сравнительно легко реализуется и поддерживается многими программами, работающими с JTAG. Quartus, OpenOCD, UrJTAG, да, наверное, и Xilinx с Lattice'ом не остались в стороне. Размер SVF-файлов (а это текстовые скрипты) - будет соответствующим. Но это другая сторона медали.

Если речь идет о конфигурировании через JTAG с использованием SVF-файлов, то их нужно будет слегка модифицировать - добавить действия с TAP-контроллерами, предшествующими и/или следующими за нашим интересантом в JTAG-цепочке. Делается это через использование команд HIR/HDR и TIR/TDR (H, T - header and trailer, голова и хвост, соответственно). Для пояснения такая картинка из SVF spec'а: Сами же действия просты: в IR загоняется команда BYPASS в DR всегда подставляется 1'b0 (это и будет содержимым 1-битного BYPASS DR)

Это лищь пример общения с пользовательской логикой через JTAG Alter'ы. Но иллюстрация неплохая. Но вам-то надо загружать SOF-файл через JTAG, а не общаться с с уже загруженной логикой в FPGA. Это перекается по функционалу с этим примером, но не совсем то. Поскольку в задаче присутствуют FPGA от нескольких вендоров, то для каждого надо будет найти/написать/приспособить свою библиотечку примитивов для загрузки (т.к. принципы загрузки у всех, скорее всего, разнятся). Да, там будет общий нижний слой JTAG примитивов, но над ним для каждой FPGA технологии будет свой подставляемый слой со спецификой конфигурирования FPGA от Altera или Xilinx, например. Отсюда вопрос - действительно ли это именно то, чего вам хочется? Я имею в виду грузить именно через JTAG. Если не ошибаюсь, каждый из FPGA вендоров предусмотрел более простой метод конфигурирования (Altera and Xilinx - точно) - тот, который используется при конфигурировании с помощью конфигурационных FLASH. Эти методы у них по-разному называются, но принцип близкий. И часто приводятся C-шные исходники для реализации такой загрузки через микроконтроллер, например. У Altera точно видел такую Application Note. JTAG - да, более универсальный подход, но он и сложнее.

Готовых софтин такого рода, да еще с GUI, я не знаю. Если подобная задача появляется в контексте автоматизации серийного производства, то не грех самостоятельно разработать поддержку такого решения, пусть хотя бы даже и на скриптах.

Вот, попалось в сети по теме топика (как ориентир): Гибридные лабораторные источники питания E-Core Технический обзор лабораторного БП PS-3005P «Тихоня»

Так какая цена все-таки?

Может, вы все-таки озвучите, что конкретно и в какой конкретной схеме вам непонятно? Тогда и ответы/помощь будут более определенными.

Статья на Хабре по теме: Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx)