dxp

UltraScale+ тоже начинался со старших. Но потом появился Artix, а за ним и Spartan. Правда, с большим перерывом, но может с этими Xilinx не будет тянуть резину.

Какие оптимисты!

Не понял сути возражения. Я отвечал в контексте вопроса о том, как считать активность логики. Потребление в эстиматорах вендоров считается от количества задействованных ресурсов с учётом тактовых частот и коэффициента использования логики, которой принимают в среднем 0.125.

При статистическом подходе используют коэффициент 1/8 -- т.е. считается, что в среднем одновременно переключается порядка 12.5% вентилей. Конечно, это зависит от микросхемы, но такую величину коэффициента выдавали Altera и Xilinx для FPGA (статистику наводили). Для первичной оценки годится. В их Power Estimator'ах он и фигурировал, хотя можно было менять, если надо.

Так речь шла о параметрах (исходный вопрос), посадочное - не параметр. Но таких "не параметров" там раз-два и обчёлся. Проблема с поиском как раз возникает на пользовательских параметрах, которых может быть сколько угодно и которые могут иметь какие угодно имена.

Параметры всех компонентов можно посмотреть в Parameter Manager (меню Tools, при вызове отфильтровать только компоненты -- установить галку только у Parts). Программа выведет Таблицу, в которой наглядно видно, какие параметры есть у компонентов схемы. И там же их можно редактировать по одиночки или группой.

Похоже, что вы не знаете, что такое Questa. 🙂 Modelsim -- это подмножество Questa, в котором отсутствуют верификационные возможности тула. Questa вполне легко добывается отдельно от квартусов, причём не Lite, а полноценная. Хоть на том же рутракере.

Т.е. у вас тайминги не настроены? Посмотрите, какие требования предъявляет ваш PHY. И посмотрите осциллографом, что там реально. У меня PHY KSZ9031, он хочет согласно спеке на RGMII 2 нс задержки. Я это ему обеспечил вот таким образом: gtx_clk90 -- это сдвинутый на четверть периода клок, как раз 2 нс. Подозреваю, что и вашему PHY так будет нормально.

Приёма нет, т.к. протокол велит битые пакеты дропать. Но сетёвка их принимает, и шарк, повторяю, в "неразборчивом" режиме видит. Тоже, когда возился впервые с этим, формирование FCS было неверным, на что шарк указывал, но пакеты, тем не менее, показывал. У вас одна такая плата? Или это эффект, повторяемый между разными платами? Я к тому, не ли аппаратного косяка на передающей линии.

Заказной, возможно.

Можно было бы предположить, что пакет почему-то битый (FCS и т.п.). Но шарк обычно подключается к сетёвке в т.н. неразборчивом (promiscuous) режиме, т.е. показывает даже пакеты с битыми FCS. Если только там вообще формат пакета сломан -- например, нет стартового символа (0xd5) или заголовок изернет фрейма корявый. Поднимите ILA на дивайсе и посмотрите, что он на PHY отправляет? Линк, насколько понимаю, поднят, иначе бы хост ничего не отправлял.

Где вы про таймаут увидели хоть слово? Или если транзакцию нужно запихнуть в очередь, а она полная, и операция не может быть выполнена, поэтому транзакция, например, дропается, а в ответ летит Slave Error. А чтобы процессор не висел в ожидании вечность, контроллер интерконнекта генерирует исключение. Но это всё зависит от реализации, спека AXI, насколько помню, не оговаривает протокол выхода из ошибочных ситуаций. UPD. Скорее всего там где-то есть что-то типа блока QoS, который следит за порядком на интерконнекте, и когда возникает подобное, генерит исключение. Наверняка, если покопаться, можно найти и какой-нить код, из которого можно понять, что конкретно является источником исключения.

А разве он не должен обрабатывать транзакцию? Вот проц метнул со своей стороны транзакцию записи, она долетела до моста, от него пришло подтверждение (BRESP), но транзакция болтается в очереди моста и ждёт, когда её PL сторона обработает -- прочитает. А там никто не шевелится. А проц всё мечет и мечет. Когда эта небольшая очередь заполняется, проц при очередной попытке получает отлуп и аппаратное исключение. Я не ведаю деталей, как сделано в MPSoC, но, например, про 7000 сказано про его AXI GP мост: Т.е. там есть небольшая аппаратная очередь, чтобы можно было слать транзакции, не дожидаясь обработки текущей. Но чтобы эта очередь не встала колом, приёмная сторона должна своевременно отрабатывать свою роль. Подозреваю, что у MPSoC тоже сделано похожим образом, отличия количественные. А может и тоже такие же. А 12 получается вместо 8 потому, что там на интерконнектах тоже есть буферизация -- путь длинный, с переходами через несколько тактовых доменов, без локальных буферов не обойтись. Вот и получается 8 в мосте и 4 по дороге до него. Сделайте чтение из моста на стороне PL, если этого там нет.

А аппаратный блок что-то с этими регистрами делает? Ну, читает их? Как AXI транзакция происходит? Такое впечатление, что как будто очередь переполняется и отлуп прилетает.

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

Не уверен, но предполагаю, что на Zynq MPSoC так же, как и на Zynq-7000. А для него атрибуты задаются на уровне региона (суперсекции), который имеет размер 16МБ. Посмотрите, какой размер секции, на которую распространяются атрибуты в вашем дивайсе. UPD. Хотя нет, атрибуты задаются на уровне секции 1МБ, просто по умолчанию инициализация сделана так, что для 16МБ секций атрибуты задаются одинаковыми. Посмотрите значения атрибутов в таблице трансляции для вашего адреса, изменились они после задания атрибутов?

Альтий поддерживает т.н. режимы -- Mode -- для схемных компонентов. В редакторе Tools->Mode, там можно надобавлять этих режимов, сколько угодно, в каждом из них изобразить компонент так, как хочется. Ну, и остаётся вариант с локальной библиотекой проекта -- слепить компонент в ней, нарисовав его так, как хочется именно для этого проекта.

Ну, так она пытается тайминги вытянуть. Если сигнал идёт на входы тактирования флопов, то какие у неё варианты? Она вынуждена использовать пути распространения клоков, т.е. тянуть через буферы. А вот какие буферы при этом используются, на это уже можно влиять. Для обсуждаемой ситуации как раз комбинация BUFIO + BUFR самое оно. Мне только только однажды руками приходилось рулить размещением -- PCIe лажалась по таймингам, там оказалось, что пару LUT тул утащил в другой регион зачем-то, вот пути до них и давали неприемлемую задержку. Решил тупо в лоб: создал PBlock, и указал, чтобы все потроха моего модуля (там инстанс корки PCIe и моя логика) складывать в этот PBlock. После этого проблема ушла, редицивов не было. Ну, может оно как-то внутри CLB развелось -- "вынырнуло" из слоя клоков, прошло через LUT и снова "занынрнуло" в слой клоков. Quartus, помнится, на такие финты выдавал предупреждения, что, де, используются non-dedicated пути для клока, хотя тоже работало. Использовать логические ресурсы (LUT) для регулирования задержек -- плохая практика. Там на PVT всё это будет "плавать" плохопредсказуемым образом.

Там проблема возникает из-за достаточно больших задержек от пина до регистров. Особенно от пина с клоком до татковых входов регистров данных. Попробуйте просто с пина завести на тактовые входы IDDR, посмотрите, как там всё перекосится. Особенно обратить внимание на разницу доставке клока между разными регистрами. Если, конечно, тул сам не догадается затащить клок на BUFIO. А он скорее всего догадается, если клок заведён на СС пин банка. Попробуйте завести клок не на СС пин и напрямую от него тактировать IDDR. Я вообще слабо себе представляю, какие там будут пути разводки для клока в этом случае. Всё же производителем микросхемы предусмотрены специальные средства для решения таких задач, именно их и нужно использовать. Всё остальное -- лотерея верхом на геморрое.

Размеры PBlock вы же сами задаёте. Или имеете в виду регион? Если регион, то странно, он достаточно большой, FIFO там со свистом помещается Тут не в нагрузке (fanout) дело, а в том, что буфера эти -- точки входа на физический домент тактирования. Если хотите, чтобы ваши флопы тактировались клоком с малым, предсказуемым перекосом, нужно использовать эти ресурсы, и буфера -- неотъемлемая часть этого. Без BUFIO обойтись можно: традиционный поход -- завести клок на PLL (MMCM), которую настроить в режиме компенсации задержки (чтобы клок на IO флопах был синхронизирован с данными, которые приходят снаружи), но этот способ дороже: блок PLL + опять же буфер (BUFG/BUFH -- эти тоже дороже, чем BUFR), т.ч. такое вам скорее всего ещё больше не понравится. BUFIO -- как раз и сделан для того, чтобы избежать возни с PLL, он позволяет честно (т.е. с малым и предсказуемым перекосом) тактировать IO флопы в пределах банка. Поэтому это преимущество этого семейства, реализация подобного на Altera Cyclone IV требовала как раз использовать PLL. А насчёт быстрее -- в смысле, ниже задержки на элементе? Ну, так тут это вообще во вторую очередь важно, тут главное не быстрее, а правильно -- чтобы синхронизация внешних сигналов не нарушилась при передачи их внутрь. Для этого и предпринимаются все эти меры: IDELAY->IDDR + BUFIO + BUFR. Не испытал никаких проблем, всё работает. Правда, у меня Artix7 (Zynq-7000), но тут отличия скорее количественные (настройки задержки могут быть другими).

Что за потребители? Там же только приёмная часть MAC от этого клока питается, не так много. У меня сперва делается RGMII->GMII, который уже летит в MAC, клок rx_clk, понятно, у них общий, в MAC там почти сразу данные перегоняются в основной тактовый домен (100 МГц, 16-бит слово), самое жручее по ресурсам там -- это вычисление FCS. У меня PHY KSZ9031, для него настроено так: За основу взяты из вендорской корки, подправлены задержки (-1.5, -2.8 -- это для указанного PHY подобрано). Без входной задержки (IDELAY) тайминги не сходились, пришлось это тоже добавить. Задержки там задаются: set_property IDELAY_VALUE "15" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxd*} ] set_property IDELAY_VALUE "15" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxctl*} ] set_property IODELAY_GROUP "gpr1" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxd*} ] set_property IODELAY_GROUP "gpr1" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxctl*} ] set_property IODELAY_GROUP "gpr1" [get_cells -hier -filter {name =~ *rgmii/*idelayctrl*} ] Код:

Это в руках разработчика. У меня такая реализация: Т.е. IDDR тактируется через BUFIO, а штатные флопы через BUFR. Код: //------------------------------------------------------------------------------ // // Reveiver // BUFIO rxc_bufio ( .I(rgmii_rxc), .O(ioclk) ); BUFR #( .BUFR_DIVIDE ( "BYPASS" ), // Values: "BYPASS, 1, 2, 3, 4, 5, 6, 7, 8" .SIM_DEVICE ( "7SERIES" ) // Must be set to "7SERIES" ) rxc_bufr ( .I ( rgmii_rxc ), .O ( rx_clk ), .CE ( 1 ), .CLR ( 0 ) ); Основная сложность там -- это подогнать тайминги: настроить задержки в IDELAY. И констрейны там тож нетривиальные.

Действительно похоже на проблемы с памятью. memtest, как уже посоветовали. А другие программы и система стабильно себя ведут? Есть ещё жадные до памяти программы?

Если памяти не хватает, оно в своп уходит, тормозить начинает, но не падает. Бывало такое с вивадой у меня несколько раз. Да. И ещё попробовать собирать на другой (других) машине, чтобы локализовать: в виваде дело или в компе.