Jump to content

    

StewartLittle

Свой
  • Content Count

    2499
  • Joined

  • Last visited

Community Reputation

0 Обычный

About StewartLittle

  • Rank
    Лентяй
  • Birthday 03/05/1971

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

10988 profile views
  1. Процедура защиты состоит из двух частей - зашифровывания конфигурационного файла и прошивку в ПЛИС ключа для дешифровки. Получение супостатом зашифрованного конфигурационного файла не позволит ему клонировать устройство, т.к. у него не будет ключа для дешифровки.
  2. Я так полагаю, что в окошке из Вашего первого поста :)
  3. Смотрите ппраграф 2.2.2.1 : Вот нашел в закромах какой-то пример, посмотрите на досуге: Файлы прилагаю. Ссылка на AN556: https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an556.pdf MAX10_JTAG_Secure_Unlock_UG.pdf top.qar
  4. Если хотите все закрыть совсем наглухо, то используйте Tamper Protection - при этом еще и возможность загрузки по JTAG будет заблокирована :) Этот документ, я полагаю, Вы изучали: Intel MAX 10 FPGA Configuration User Guide
  5. Имхо, стоит. Тут все зависит от задачи - одну удобнее решать на Lattice, другую - на Gowin. Тем более что архитектуры у этих ПЛИС похожи, и нет никаких проблем перевести проект с одной на другую. И там, и сям можно найти свои минусы и плюсы. К примеру, по перечисленным Lattice : MachXO2 дорогие, MachXO3 - только в BGA (с шагом 0.8мм в лучшем случае), в iCE40 нет флэша (их нужно или конфигурировать по SPI, или прошивать OTP раз и навсегда). У Gowin можно найти не меньше минусов. Да. После Альтеры / Лэттиса первый результат достигается за пару часов, с минимальным заглядыванием в даташит или мануал на САПР.
  6. Свои. И бесплатные. Но исходники зашифрованы. А что 8Мбайт DDR322 ОЗУ, 48 умножителей и 15000 триггеров в корпусе QFN88 (GW2AR-LV18QN88PC8/I7) не способны сжать видео и плюнуть в LAN? А это смотря что под ресурсами понимать - ресурсы ПЛИС или web-ресурсы фирмы Gowin :)
  7. Никакой совместимости. Никакого копипаста. Архитектура своя (немного похожа на Lattice). Среды разработки свои (для FPGA и для MCU) и весьма удобны. Англоязычная документация есть и на ПЛИСы, и на САПРы. Микросхемы и отладочные платы очень бюджетные :)
  8. Хммм... Смотрю в v18.1, (в проекте в качестве целевого чипа выбран MAX 10) : IP Catalog - Library - Basic Functions - I/O - Soft LVDS Intel FPGA IP
  9. А почему бы здесь HyperRAM не использовать???
  10. Осталось только угадать, какие из восьми I/O пинов входы, какие выходы, а какие двунаправленные :)
  11. epcq_controller2 и jic - это гвозди от разных стенок. epcq_controller2 нужен в разных случаях: Например, если сегмент исполняемого кода расположен во внешнем ОЗУ, и это ОЗУ нужно проинициализировать при включении питания. Или, если хочется исполнять код непосредственно их конфигурационного ПЗУ. Ну или если хочется использовать конфигуратор как энергонезависимую память для храниния каких-либо данных приложения. Использование в проекте epcq_controller2 не имеет никакого отношения к jic'у. А использование jic'а в данном контексте позволяет забить на nios_flash_programmer (со всеми его глюками). P.S. Вот здесь я докладывал про проблему работы с ниосом под wsl: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=157679&tab=comments#comment-1703505 Проверьте настройки hal.linker в bsp (allow_code_at_reset, enable_alt_load и т.п.). Вот моя переписка по поводу старта из ниоса из коефигуратора: nios_epcq_start.txt
  12. Нынче пользоваться ниосовским флэшпрограммером не кошерно :) Теперь нужно делать так: использовать в qsys'е (или как он там сейчас называется - Platform Designer'е) модуль epcq_controller2, в настройках процессора вектор сброса указывать на этот контроллер, причем обязательно со смещением, большим чем размер битстрима для ПЛИС, в NiosII SBT правильно настроить bsp, скомпилировать код и выполнить mem_init_generate (в соответствующей папке повится файл epcq_conteoller2.hex), в квартусе запустить Convert Programming File и сделать jic из sof'а и полученного в предыдущем пункте hex'а (правлитное смещение hex'а подставиться автоматически - это моно рссматривать, как своеобразную проверку), прошить конфигуратор полученным jic'ом при помощи квартусовского программера. Я здесь, ЕМНИП, про это уже докладывал. Вот-вот, оно самое. Не работают эти exe-шники под WSL. Про это я тоже здесь уже писал, не так давно. Причем Intel'у об этой проблеме известно, в KDB он рекомендует запускать exe-шники вручную из-под шелла. Только при этом они все равно не работают. Потому-то я переполз под Linux сo Standard v19.x/v20.x - под Linux в этих версиях все работает, как положено. P.S. Ну или под виндами - забить на v19.x/v20.x и откатиться на v18.1 (там cygwin, и все работает, как и раньше). Тем более, что в v19.x/v20.x относительно v18.1 никаких улучшений нет. Скорее даже наоборот - в новых версиях Standard убрали несколько полезных опций (DSP Builder, HLS, OpenCL).
  13. Хм... А у меня и с родным Makefile все собирается... Проблема под виндами в другом - создаются ли у Вас hex-файлы при выполнении mem_init_generate? Мне это побелить не удалось. Под виндами откатился на v18.1.1, а v20.x использую под линуксом.
  14. Да, согласен - тут я кривовато свою мысль выразил. Хотел сказать, что в iCE40 ресурсы разводки бедноваты. И из-за этого не всегда получается PLB на полную использовать.