Inanity

Если есть осциллограф, то можно сделать дизайн, в котором каждая нога ПЛИС выдаёт ШИМ со своим уникальным значением скважности, далее тыкаться по всем пятакам и контактам и по скважности определять распиновку. Да, упорото. А кому сейчас легко?) Правда у платы ТС память BGA с двух сторон, там возможно microVia и этот фокус не пройдёт.

Да, конечно, это возможно.

Насколько я помню, в режиме FPP флешка будет шиться через MAX. Суть в том, что конфигурация MAX одновременно умеет шить стратикс после подачи питания, а так же умеет общаться с Quartus-овским программатором через JTAG для перепрошивки флешки. Пример этого дизайна альтера предоставляет. У переходного отверстия есть контактная площадка (поясок). Используйте в качестве щупа мультиметра очень острую иголку. Если иголкой тыкнуть в край контактной площаки, то вы никак не повредите переходное отверстие. Даже если, поясок закрыт маской (как в вашем случае), ничего не нужно скрести, тыкайте иголкой и проиграйтесь ею из стороны в сторону, острие само пробъёт маску и доберётся до меди. На всякий случай не тыкайте в само отверстие, только в поясок вокруг него. Если делать с умом, то ничего не оторвёте и не сломаете.

Да, конечно, для начинающего это очень круто. Вам бы DE0-nano на Cyclone IV или DE0-nano-SoC на Cyclone V. По существу: 1. Сомневаюсь, что вы что-то спалите, если будете наобум перебирать комбинации TDI, TDO, TMS. В крайнем случае, чтобы не перегрузить буферы, можно поставить последовательно резисторы, например в 22 ома. Но можно копнуть глубже... 2. Плата при работе с PCIe должна успевать загружать свою конфигурацию за 100ms. Единственный способ успеть это сделать, это параллельная конфигурация через FPP (Fast Passive Parallel) Т.е. Stratix не сам тянет свою конфигурацию из флешки, а в данном случае MAXII читает флешки и льёт эти данные в Stratix по параллельной шине. Уверен в этом на 99%. С JTAG разработчики могли поступить по-всякому. Если они не наркоманы, то скорее всего MAXII c Stratix V сидят последовательно на JTAG цепочке. Но меня смущает большое количество пинов в FPC коннекторе. Может ли быть так, что оба JTAG независимо заведены на разъём, а внешняя плата позволяет либо объединить обе микросхемы в цепочку, либо работать с ними по отдельности? 3. JTAG от MAXII скорее всего выходит через сквозные переходные отверстия. Зная расположение выводов JTAG на MAXII, можно попробовать угадать к какому переходному отверстию подходит вывод и прозвонить его с выводами FPC коннектора. Тоже самое можно проделать для Stratix V. TCK и TMS идут параллельно на обе ПЛИСы, а TDO с TDI сложнее, либо цепочка, либо как я выше писал.

Такая задача имеет решение. Но для её решения не нужно 1000 узлов. Ядро 10Gb ethernet выдаёт обычно 64 бита на частоте ~156Мгц. Далее XOR с константой, запись в промежуточный регистр и вывод на ядро передатчика в том же виде (64 бит ~156Мгц). Глубина конвейера - 1 такт, частота работы ~156Мгц. Просто немного смешно. Это такая пушка по воробьям))

1. Отлично, уже что-то. В любом случае будем считать, что можно написать такой алгоритм обработки, чтобы он мог обслужить любое из устройств, в любом из их внутренних состояний. Итого мы получили некоторый обработчик (будем называть его так). Этот обработчик по своей сути - некоторая логическая схема, включающая в себя конечный автомат, буфер памяти, умножители и прочие функции, которые необходимы для обработки. 2. Итого, что мы имеем. Поток 10Gb разбирается (десериализируется) и раскидывается на N-ное количество обработчиков, далее, на выходе от обработчиков результат собирается обратно (сериализируется) в 10Gb. Теперь нам нужно понять сколько нужно таких обработчиков, чтобы канал не захлебнулся (когда новые данные поступают, а обработка старых не закончилась). В идеальном варианте обработчик должен представлять из себя конвейер, который на каждом такте будет принимать новые данные, D - тактов обрабатывать и в конце выдавать на каждом такте результат. Другими словами у вас получится задержка на обработке в количестве D-тактов. 3. Теперь, чтобы эта мясорубка завелась, нужно прикинуть из чего состоит один обработчик, какие ему нужны ресурсы, сколько тактов уйдёт на обработку одного блока данных от одного устройства. Основные ресурсы для ОДНОГО обработчика: -> количество памяти -> количество FF и LUT (в терминалогии ПЛИС это регистры и логические функции) -> количество DSP блоков, они нужны для математики, если она у вас есть (умножение/деление/корень и тд). Математику лучше делать на DSP иначе потратите много FF и LUT. Ресурсы любой ПЛИС ограничены, как вы понимаете. Чем "легче" будет один обработчик, тем больше их можно будет впихнуть в параллельную обработку, чтобы справиться с 10Gb данных. Если предположить, один обработчик работает с производительностью 100Мбит, то таких нужно будет 100 штук. Чтобы уместить 100 обработчиков + логику для разборки/сборки этого потока, нужно понимать сколько весит один обработчик, т.е. возвращаемся к пункту 3. Я понимаю, что у вас не было опыта работы с ПЛИС, но если вы скажете, что обработчик должен, например: 1. иметь буфер памяти на 1КБ 2. Сделать 10-20 проверок (логических сравнений). 3. пару раз умножить числа разрядностью N x M с аккумуляцией результата где-то... 4. Взять квадратный корень из результата... 5. сложить результат с какой-нибудь фигнёй и таким образом сформировать итоговый результат. То тут хотя бы можно будет прикинуть ресурсы, число тактов и даже может конкретную ПЛИС порекомендовать с запасом по объёму. Иначе - это всё разговоры ни о чём. Если ваш алгоритм требует 100.000 тактов сложной математики, то это ни в какую ПЛИС не влезет с такой пропускной способностью...

Алгоритм обработки для каждого из 1000 узлов одинаковый?

Студент заборстроительного... 1. Что значит 10Gb? Если это просто скорость линка, то можно на 10Gb 1 килобайт принять, 3 часа обрабатывать и снова на тех же 10Gb передать. Т.е. линк получается 10Gb, а эффективная пропускная способность 1килобайт в 3 часа. Чувствуете разницу? Если нет, то проконсультируйтесь с человеком из вашей команды, который понимает, что происходит. 2. Предположим, что вы определили, что на линке 10Gb к вам приходит поток данных в 500Мбайт/сек (для примера). Для решения задачи нужно понимать суть алгоритма обработки. А именно, каковы требования по памяти, какова глубина конвейера. Исходя из этих данных уже более-менее можно будет прикинуть по ресурсам можно ли это сделать на ПЛИС, какие потребуются ресурсы, чтобы обработка на ПЛИС не стала "горлышком от бутылки" в потоке данных. Уже третья страница пошла, а вы никак не можете толком сформулировать задачу.

Readback у альтеры называется - examine. Но если выставлен бит защиты, то считать не выйдет: https://www.altera.com/support/support-reso...192010_758.html

Даже если считаете, загрузить тот же битстрим в другую FPGA/CPLD просто так - невозможно, структура битстрима имеет зависимость от архитектурны конкретной FPGA/CPLD. Не скажу, что данная задача не решаема вообще, но она требует особых знаний и времени. Можно попробовать обратиться к разработчику, если это возможно. Или разработать новую прошивку, пытаясь максимально скопировать поведение устройства.

А если попробовать как-то производителю доказать, что имеется плата, а не просто схематик нужен? Фото послать или ID-шник платы. Вообще можно и рентгеном просветить, а там уже попробовать разобраться с дорожками)

FIFO на двухпортовой памяти решает проблему. Только 100МГц интерфейс должен следить за флагом FULL у FIFO, т.к. очевидно, что возможно переполнение.

Пробуйте, как говорит AVR. Таймаут при инициализации на PCIe 100ms. ПЛИС банально может не успевать подтянуть конфигурацию из флешки после подачи питания.

Думаю, что это очевидно. Экспортные ограничения. Тут АЦП 14-бит >100msps просто так не купить, а вы хотите 2Gsps + FPGA.

Действительно проблема, не подумал. UID, собственно, задумывался как защита всего дизайна от копирования, а не его частей. Скажем так, это способ защиты ip-core работает, но не масштабируется. Можно без UID. Есть способ защиты от копирования на основе внешней сrypto-memory. Если кратко, то в ip-ядре хранится ключ K и генератор случайных чисел (ГСЧ), во внешней сrypto-memory тоже хранится этот ключ К (который нельзя считать, только перезаписать). После включения питания ГСЧ выдаёт случайное число, которое отправляет во внешнюю сrypto-memory, она делает с этим числом некоторое преобразование, используя ключ К и отправляет результат обратно в ПЛИС, в ip-core. IP-core тоже выполняет аналогичное преобразование, но уже на своей стороне с тем же ключом и числом. Если результаты от сrypto-memory и ip-core совпадают, то аутентификация успешна. Подробнее есть документ xilinx: https://www.xilinx.com/support/documentatio...tes/xapp780.pdf От себя скажу, что в документе описывается сrypto-memory с SHA-1. Этот хэш на сегодняшний день не считается безопасным, необходимо применять сrypto-memory на основе SHA-2 или SHA-3. Данный подход тоже отнюдь не изящно масштабируется, т.к. под каждую ip-core нужна будет своя сrypto-memory (хотя их спокойно можно посадить на одну шину i2c или 1-wire в зависимости от сrypto-memory). Ещё есть риск накосячить с реализацией ГСЧ на ПЛИС.

Если заказчик на этапе интеграции корки и теоретически может что-то сломать/сжечь, то можно отдать корку с таймером или урезанным функционалом. Когда всё отлажено, оттестировано и зашито в релизные версии, то вышедшие из строя микросхемы это исключительно проблемы заказчика. Если это SRAM-based ПЛИС и конфигурация хранится во внешней флешке (90% случаев), то hmac(fpga_id) можно хранить на ней. В этом случае битстрим будет всегда один и тот же. Разработчик IP-корки запросто может нагенерировать ваши 100500 хэшей по 100500 id-шника. Заказчику остаётся только запрограммировать на флеш битстрим + рядом положить соответствующий fpga-ке hmac(fpga_id). Hmac привёл для примера. В любом случае хэш можно усложнить/упростить на усмотрение разработчика.

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

Будьте готовы к тому, что такие часы будут не так точны, как специализированная RTC микросхема.

Пожалуйста. Берём 3 FIFO. Каждую шину заводим в своё FIFO. Начинаем чтение из всех трёх FIFO только тогда, когда в каждом есть хотя бы по одному слову (конъюнкция стробов валидности). Глубина FIFO естественно должна быть больше максимального разброса между шинами. Но раз это максимум 1 период то вообще хорошо. Можно даже FIFO сделать на логике, чтобы блочную память впустую не тратить, т.к. тут единый клоковый домен, да и глубина FIFO малая. Причем данный способ удобен в том, что не нужно заранее знать какая шина от какой отстаёт. Должно получиться очень компактно и просто.

Мне очень не нравится этот код. Смеха ради посмотрел код приёмника и не увидел синхронизаторов там, где по моему мнению они обязаны быть. Модуль uart_rx. Асинхронные данные приходят по проводу rxd. В этом процессе они защёлкиваются в триггер last_rxd: reg last_rxd; always @(posedge clk) begin last_rxd <= rxd; end Триггер last_rxd может находиться в метастабильном состоянии, т.к. по rxd пакеты приходят асинхронно. Провод slew тоже метастабилен, т.к. комбинационно зависит от last_rxd: wire slew = rxd ^ last_rxd; Далее по коду и slew, и last_rxd используются в различных процессах, if-ах и в автомате состояний. WAITING : begin // wait for a start bit (0) if (!slew & sample_now && !last_rxd) begin // тут ещё нравится использование & и && одновременно. state <= READING; held_bits <= 0; end end Оно, может и работает, но по-моему это жесть. Да ещё и копирайт от альтеры)

А почему не сделать отдельную землю для конденсатора (via in pad) и отдельно саму ножку микросхемы подключить к земле другим via. Я надеюсь, что ТС не экономит на via? Но если выбирать из двух вариантов, то по-моему первый лучше, т.к. "шинное" подключение земли или питания не есть хорошо. Но это моё личное мнение.

Мы с вами как-то по-разному понимаем независимость каналов. Есть электрическая печка. У неё есть ручка регулировки температуры и кнопка включения. Если проводить параллели, то получается, что я не могу сначала выставить температуру, а потом включить печку. Я должен одновременно и ручку крутить и кнопку нажимать, чтобы печка меня поняла. Мне кажется это не нормально.

Эх...сколько людей на эти грабли наступило и ещё наступит) Причём, совершенно непонятно зачем так было сделано. Вроде разные стримы, а зависимость есть. Если не забуду завтра выложу свою версию AXI4-Lite Master с "человеческим" интерфейсом с другой стороны. UPD: axi4lite_master.v

Скорость можно регулировать скважностью питания змейки. Когда-то тоже задавался этим вопросом: https://electronix.ru/forum/index.php?showtopic=133350

Я бы поставил новую. Вам сейчас критически важно получить именно рабочую плату. Если окажется, что проблема решена, то первую ПЛИСину тоже можно будет задействовать, но уже будучи уверенным, что проблемы если и будут, то только с ней, а не с остальной платой.