Flood

MAXDELAY задает ограничение по задержке в цепи. Если время фронта - это крутизна фронта, то изменить ее можно, изменяя ток выходного драйвера (констрейн DRIVE для выходов типа LVTLL / LVCMOS). Конечное время фронта будет зависеть от характеристик внешней линии и нагрузки. Бездумно влеплять максимальный DRIVE может быть очень вредно.

В ПЛИС загружается битовая последовательность, имеющая документированный размер. hex (mcs) - промежуточный формат (ASCII), его нельзя загрузить в ПЛИС без преобразования в бинарный, поэтому вопрос не имеет смысла. При загрузке ПЛИС из процессора используется чистая битовая последовательность (bin). Если ножек хватает, лучше грузить через SelectMAP, выдавай байт или более за 1 такт. Slave Serial из процессора - очень спорное решение.

Увидев тему о "сколке" плат не мог не спросить о возможности снятия нетлиста. То, что все можно сделать вручную, а часть цепей прозвонить JTAG-ом - это и так понятно. Но такая работа - нудная и кропотливая, да и в конечном счете не слишком нужная. Не всякое радиолюбительство обязано ходить самыми сложными путями.

Жуть какая-то на схеме. Видимо, решение перекочевало с ранних виртексов, т.к. у Virtex-6 program_b уже не active-low. Эта особенность обсуждалась в соседней вашей теме. В целом, в рабочем режиме притягивать program-b к земле как-то противоестественно.

"Банальная Нокия" какого-нибудь лохматого года - сложнейшая HDI плата даже по сегодняшним меркам. Плюс, экономия целого резистора в миллионных масштабах :) Я не топикстартер, просто задал смежный вопрос в той же теме. Не понимаю, зачем снимать маску с переходных, если нужен нетлист. Встроенных конденсаторов, скорее всего, там нет :) Еще раз - мне нужно использовать имеющуюся плату, а не делать на ее основе новую. Поэтому топология не нужна. Подразумевается, что она правильная. Ключевое слово - радиолюбительство. На проф. форуме звучит как ругательство, знаю. Но тем не менее, вопрос о практической пользе почти не стоит. Есть готовая плата, почему не использовать? Тем более что BOM там на несколько килобаксов. Китов на FPGA много, но цены на них весьма серьезные, для радиолюбительства выйдет накладно.

Согласен, если речь идет о профессиональной деятельности и проф. применении. Однако, мой вопрос отличается от вопроса ОПа. Здесь чистое радиолюбительство - есть интересная плата с компонентами, позволяющими сделать на ее основе кит для любительской деятельности на FPGA. Но полноценному использованию не по назначению мешает отсутствие схемы/нетлиста. Вот и все. Т.к. таких одинаковых плат есть несколько штук, возникла идея снять с нее все компоненты и каким-либо способом восстановить нетлист. Вопрос - как сделать это дешевле и проще. Электротестом или шлифовкой? Первое мне видится более адекватным задаче, но порядка цен все равно не представляю.

Задача именно получить нетлист, и как можно дешевле. Для последующего использования платы в качестве отладочного / девлоперского кита. Это сложный, но никому не нужный (устаревший) прибор на FPGA. Повторение платы не требуется.

Ну, тогда продам ML605 + деньги за KC705 :)

Начиная с ISE 12 direct SPI и другие не-JTAG методы программирования более не поддерживаются. Нужно брать iMPACT 11 или еще более ранний. Вообще говоря, если ПЛИС нормально конфигурируется с этой флешки, то и indirect программирование, в конечном счете, должно работать. Хотя бы читать ID - совершенно точно. Проверьте схему и плату. Может быть, плата битая, или флеш подключен неправильно? Это как-то ненормально. А откуда вы узнаете, что ПЛИС находится в режиме Master SPI? Есть указания на плате? ПЛИС в это время не загружена?

Интересно, где можно сделать послойный скан МПП (слоев 16 - 20)? Сканирование, как я понимаю, возможно только разрушающим способом? Сколько плат обычно требуется, хватит ли одной? Каков порядок цены на данную услугу? Смежный вопрос - возможно ли электрическое восстановление нетлиста платы неразрушающим способом (электротестом)? Дешевле ли это послойного сканирования?

Virtex-6 и все 7-series. Сначала данные появились в errata (http://www.xilinx.com/support/answers/38134.htm), затем эту особенность узаконили в соответствующих ug360, ug470. Если кто делал раньше отложенную загрузку удержанием program_b, то теперь этот фокус не пройдет, нужно использовать init_b.

Сам квартус запускать под рутом не надо, только jtagd: killall jtagd sudo ./jtagd Как временное решение проблемы должно сгодиться. Вариант с патчем jtagd выглядит более разумно, хотя он тоже кривоват.

Угу, знатная вышла подстава. Ее вроде как объявили не багом, а фичей, и исправлять не стали. А насчет одновременной загрузки из флеша и JTAG - у автора темы в любом случае была не эта проблема.

Довольно интересное решение имеется здесь: http://www.alteraforum.com/forum/showpost....mp;postcount=15 Но сам я его не пробовал. Кстати, самым простым вариантом может быть запуск jtagd от рута. Конечно, это идеологически неправильно, но если нужно что-то срочно прошить, то почему бы и нет.

Да нет там 66МГц, просто макс. частота показана (что значит, что в цепочке JTAG-а только виртекс сидит). При работе с этими ядрами импакт сбрасывает частоту до 6 МГц, даже если было выставлено больше. А раз нет сообщения о снижении частоты - значит, и так 6 стоит. Я все-таки думаю, что производители платы не зря на флешку отдельный разъем для импакта поставили. Скорее всего, предполагается прямое программирование по SPI. Другая возможность - SPI флешка может быть вообще не к виртексу подключена. Но это надо плату смотреть.

Это что, 3D видеокарту заново изобрели? По крайней мере, чипы они уже изготовили, да видно, никто не берет :) Интересное наблюдение: у них там есть видео, где они показывают работу Ubuntu на "прототипной плате". Но прототипная-то плата - это ж ZedBoard на Xilinx Zync (ПЛИС с 2-я ядрами АРМа), а их чипы установлены на FMC-мезонине. Ну и чего б на этой плате Ubuntu не погонять? :) Можно даже мезонин отстегнуть, вряд-ли убунте поплохеет.

Назначение режимов расписано в ug360 табл 2-1. С обычной SPI флешкой ПЛИС напрямую работает только в режиме SPI Master. Для программирования SPI флешки через JTAG плисины установки режима загрузки скорее всего не важны. Они важны собственно для самой загрузки, а программирование происходит путем загрузки в плис специальной прошивки, входящей в комплект Impact.

ISE вроде умеет напрямую шить SPI, может для этого и сделали разъем? Посмотрите схему, все ли правильно заводится для конфигурации. Если схем нет, можно хотя бы считать регистр статуса ПЛИС по JTAG - там отражается состояние ножек INIT, Mx. По крайней мере, можно будет разобраться, в нужной ли моде стоит ПЛИС. Как правило, задача шить чужие платы возникает не часто, а если и возникает, то предполагает наличие какой-нибудь инструкции. Может с ее поисков и стоит начать, чтобы не ломать зря голову.

Ну, не видит флешку и все. Там уже есть какая-нибудь программа, плисина с нее загружается? Если плата своя - смотреть схему. Если плата неизвестного происхождения, то вызывает вопросы вот это: "для его конфигурирования установлена флэшка ST M25P64-VME6TG, причем один JTAG-разъем подведен отдельно к плисине, а другой подведен к флэшке". Что за JTAG разъем у SPI флешки? Да, и еще. Если используется ISE 14.2, полезно накатить вот этот патч: http://www.xilinx.com/support/answers/51145.htm Хотя у вас явно не этот случай, т.к. ядро прошивалки загрузилось нормально.

Что-то не редактируется первое сообщение... Пункт 1 (JTAG HW-USB-G Xilinx Platform cable USB DLC9G, новый, без картонной коробки) - 5400 р. Пункт 2 продан.

Сразу после снятия Reset процессор должен начать выполнять какую-либо программу, а значит, эта программа уже должна находиться в адресуемой памяти. Из-за сложности современных процессоров в них часто используется начальный загрузчик, т.н. Bootloader. Часто в системе может быть более одного загрузчика - загрузчик первой фазы (First Boot, First Stage Loader, совсем маленький), затем загрузчик второй фазы (Second Stage Loader, большой и сложный, почти ОС), который уже загружает основную ОС. Например, в Microblaze с DDR-ом задача First Boot - убедиться в работоспособности DDR и загрузить туда код Second Loader'а или сразу ОС из какого-нибудь внешнего устройства. В xapp482 это конфигурационное ПЗУ. Подходов к размещению загрузчика может быть много. По-умолчанию и в простейшем для Microblaze случае для загрузчика выделяется внутрикристальная память небольшого объема на BRAM, с адреса 0. Размер памяти зависит от сложности загрузчика и наличия свободных ресурсов. Из-за того, что при загрузке ПЛИС происходит инициализация BRAM, на момент окончания конфигурации программа в BRAM оказывается загружена "сама собой". Это близко к наличию масочной ПЗУ в обычном процессоре, с тем значительным отличием, что в BRAM память можно писать, а значит в ней может не только храниться сама программа, но и находиться стек, секции с изменяемыми переменными и т.п. Добавление загрузчика в битстрим ПЛИС делается программой data2mem, с использованием .bit-файла(битстрима) и .bmm-файла (описания реального маппинга BRAM-ов). Эти два файла меняются каждый раз после синтеза битстрима. xps (или ise) автоматически передает в SDK информацию об аппаратной начинке системы, поэтому в SDK достаточно написать нужную программу, скомпилировать ее в .elf, после чего сгенерировать битстрим с внедренным туда .elf-ом. Все это делается автоматически. Загвоздка при создании загрузчика в том, что в проекте, имеющем внешнюю память, настройки компоновщика (ldscript) будут таковы, что заставят расположить большинство секций elf-а во внешней памяти. Настройки нужно или поменять вручную, или дать сделать это автомату, убрав на время всю внешнюю память в проекте xps. В экспортированном в SDK проекте без внешней памяти нужно сохранить ldscript или запомнить его содержимое, и использовать его далее в основном проекте (с памятью). Убедиться в том, что запуск программы после начальной загрузки происходит нормально, можно загнав туда Hello World или memtest из готовых заготовок в SDK. Сразу же после окончания загрузки ПЛИС битстримом download.bit (по-умолчанию) или же напрямую из SDK, программа должна запуститься и сообщить об этом в UART. В качестве реального First Stage Loader можно использовать готовый от petalinux (если есть, где его найти), или вручную обрезать u-boot до безобразия. Хотя лучше всего (с точки зрения экономии BRAM) написать свой. По-минимуму в FSL должны быть функции загрузки следующей программы из некоего внешнего устройства (ПЗУ), а также из UART-а (для первоначального программирования ПЗУ!) в DDR. Также очень желательно иметь в FSL базовые средства проверки работоспособности внешней памяти (анализ phy_init_done) и короткий тест памяти, сопровождающиеся соответствующей индикацией или печатью.

Пристыженно приступил к чтению :) Думаю, ветка себя оправдала - ответы получены даже быстрее, чем предполагалось. Впрочем, я пока не понял, можно ли увидеть результаты по времянке без Time Quest, и правда ли что последний затрачивает на анализ значительное время (дополнительно к времени фиттера).

Собственно, "посмотреть, что будет" :) Задавал частоту на 5% больше необходимой. Но это не главное. Главное, что меня смутило - отсутствие явных указаний на нарушение констрейнов после этапа Fitter и длительный анализ Time Quest. Действительно, возможно, что весь синтез перезапускался после запуска анализа, хотя в закладках действий прогресс пошел именно напротив Time Quest. В итоге, можно ли без анализа в Time Quest увидеть результат по констрейнам после фиттера? Т.к. кроме success я больше ничего не нашел, да и сообщения в логе были достаточно скупы (после сотен и сотен строк в ISE это как-то непривычно).

Как и во многих сферах человеческой деятельности и бездействия, в работе со средами разработки ПЛИС есть свои устоявшиеся основы, упоминающиеся в простом разговоре как нечто само собой разумеющееся, а оттого на форумах обычно не разжеванные. Конечно, все есть в официальной документации, но на форуме-то быстрее спросить :) Вопрос простой (на каком этапе в Альтере происходит проверка констрейнов по частоте, и зачем там нужен Time Quest), но спрашивать буду нудно, чтобы не возникло неясностей, что же именно спрашивается. Собственно, вопрос вот в чем. Возникли непонятки при первом знакомстве с Альтерой, а именно с синтезом в Квартусе. При работе в Xilinx ISE процесс создания битстрима из высокоуровневого описания (HDL) выглядит примерно так (в терминах ISE): - логический синтез из высокоуровневого описания в библиотечные элементы целевой ПЛИС (XST, или сторонний синтезатор); - физический синтез, включающий в себя: -- трансляцию (Translate) -- маппинг (Map) -- трассировку (Place and route, PAR) -- подготовку битстрима (Bitgen). Собственно, на физический синтез в Xilinx накладываются различные ограничения (констрейны). В общем случае это привязка портов к физическим ножкам микросхемы и задание характеристик (частот) внешних тактовых сигналов. Физический синтез в Xilinx на этапе PAR считается выполненным с ошибками (!), если не удалось выполнить констрейны по заданным частотам (т.н. "проект не развелся на N МГц"). Т.е. к окончанию процесса PAR и до формирования битстрима я уже знаю, вытянул ли синтезатор внутреннюю схему для работы на нужной частоте. По завершении процесса PAR указывается, какие частоты не удалось вытянуть, выводятся наиболее проблемные цепи, какие времена получились взамен требуемых и так далее. Сегодня впервые прикоснулся к Квартусу 12.0 (кристалл Stratix III). Процесс выглядит там примерно как: - логический синтез и маппинг (quartus_map); - физический синтез, Fitter (quartus_fit); - создание битстрима (quartus_asm). Задал SDC констрейны на частоту (задал число несколько выше требуемого, дабы оценить возможности Альтеры). После довольно долгих процессов маппинга и фита (1,5 часа), я получил сообщение, что все готово и прошло Successfully. Однако, я нигде не смог найти информации о том, какая получилась частота. После чего храбро запустил Analyze в закладке Time Quest, и Квартус ушел в астрал еще на 2 часа (!), после чего радостно сообщил мне, что констрейны не выполнены и дал список проблемных внутренних цепей для нескольких моделей (Slow, Fast, с разной температурой и Vint). Внимание вопрос: неужели выполнение констрейнов по частотам не анализируется на этапе Fitter? Мне казалось, что в это время как раз происходит магия, связанная с попыткой достичь требуемые частоты, и к завершению процесса о полученных характеристиках уже все известно. Зачем нужно запускать еще некий процесс, сравнимый по времени со всем остальным синтезом, чтобы узнать о проблемах с времянкой? Что вообще дает анализ Time Quest? Зачем дается информация по нескольким временным(?) моделям?

Интересно, практикует ли Xilinx или кто-то из его дистрибьюторов апгрейд отладок, например из ML605 в KC705 (например, с доплатой)? А то и SP605 -> KC705 :laugh: Или проще продать 605 и взять 705?