Отправил Вам в личку кое-какую статистику.

Потихоньку сочиняю архитектуру. Пока конфига.
Причаливаю к такой - конфиг. слово при загрузке продвигается в сдвиговом регистре и по команде ConfigReload перегружается в защелки на каждый программируемый вход CLB и коммутационных матриц.
Вопросы:
1. Можно сделать загрузку в два (или даже 3) сдвиговых регистра, для двух (или трёх) различных конфигов. И одномоментно, "на лету" переконфигурировать всю или часть логики. Насколько это интересно и нужно ли делать?
2. Можно выделить спец. линию ConfigError, на которую открытыми стоками сообщать о несовпадении конфига в сдвиговом регистре и защелках входов CLB. В некоторых случаях (помимо сигнализации) можно найти дефектный бит или биты (алгоритм довольно сложный будет, но реальный) и переконфигурироваться с учётом этой ошибки. Нужно это?
3. Шина питания конфиг-регистра отдельна от питания ядра и выведена на ногу корпуса, к которой подключена батарея или конденсатор большой емкости. При пропадании питания периферии или ядра конфиг в регистре сохранится продолжительное время. Нужно?
4. Можно озвереть и сделать тройное резервирование конфиг-регистра с мажоритаром 2 из 3 по выходу для выживания какое-то время при агрессивной бомбёжке ТЗЧ. Дикое усложнение, но всё-таки, насколько это привлекательно?
Возможно даже не мажоритар, а исправление ошибки.

Становится очевидным, что основную площадь CLB занимают схемы конфига и матриц свичей. Поэтому, экономить на собственной логике CLB нет никакого смысла. Возможно, CLB должен быть таким, чтобы на нём можно было сконфигурировать самую сложную ячейку старшего разряда самого развесистого счетчика, регистра или сумматора-умножителя-делителя со схемой параллельного переноса.
Вопросы:
5. Какого разряда? 8-го, 16-го или всё же 32-го?
6. Можете подкинуть самый сложный (схемотехнически) разряд, который вам встречался на практике?

Спасибо.

IMHO, достаточно вот такого - http://www.altera.com/literature/an/an357.pdf
А лучше доработать до ECC с исправлением ошибки.


Да нет наверное. Не так и долго перегрузить конфигурацию после пропадания. Главное, собственно, хранилище конфигурации!


Ну выше дал ссылку на док альтеры.



У меня, пока, самый жирный реальный счетчик имеет 48 бит (просто таймер). Однако сейчас уже 62-битный намечается (инкремент адреса в дма контроллере для PCIe).
Самый схемотехнически сложный, пожалуй, был 32-битный счетчик, имевший одновременно синхронную и асинхронные загрузки данных, асинхронный сброс (сделанный логикой через асинхронную), ну и счет с разрешением счета. Правда, это, скорее исключение, чем правило, но такой счетчик не вышло реализовать на CLB как оно есть, пришлось нагородить хитрую конструкцию с защелками и мультиплексорами (защелка, два триггера и мультиплексор на каждый разряд) для обеспечения асинхронной загрузки.
32...48-битная арифметика, это вообще, повсеместно в решении DSP-задач.
Кстати, вообще, не очень виден смысл ускоренного переноса. Так как быстрый последовательный перенос, предразведенный заранее, получится быстрее ускоренного, но через общую разводку. По крайней мере, все современные ячейки строятся именно так. Кстати, самый лучший перенос сделала альтера (деля 4-входовый лут на два трехвходовых для суммы и переноса), на ней, например, реализуется счетчик в коде грея напрямую, а на xilinx/lattice фиг вам.

У Atmel в ATF280 троирован весь автомат конфигурирования. А конфигурационная память - дублирована (DICE). Есть пара слайдов про это, но без особых подробностей , могу заслать.

CRC на основе RAM не убедительно. Ибо само болеет тем же, что и большее контролируемое RAM.
Перфектционизм не одобряет.

Как насчёт такого философского подхода:
а. Эталонные данные хранятся вне ПЛИС. По определению, ибо - для их хранения нужны специальные конструкции, механическая защита, которую применять для ПЛИС не целесообразно. Хотя, надо сказать, корпус ПЛИС имеет специальное исполнение для ослабления излучений.
б. При начале работы ПЛИС получает команду залить от эталона в сдвиговый регистр (далее СР) конфигурации. По окончании всей последовательности следует команда перегрузить данные СР в защелки конфигурации CLB. После защелкивания весь СР далее выдвигается на выход ПЛИС для внешнего анализа целостности и соответствия эталонным данным.
в. Периодически поступает команда перегрузить данные с выходов защелок CLB в тот же СР и выдвижение СР на выход ПЛИС, к устройству, сравнивающее эти данные с эталоном.

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

Т.е. надо смотреть на 64-ый разряд.

Буду рад любой полезняшке.

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

а лучше даже каждому CLB свой ECC. Тогда это даст огромное преимущество режиму работы в качестве блока распределенной памяти, она будет защищена ECC, как и конфигурация в целом

Это тоже самое на основе RAM и, естественно, подвержено ошибкам (хоть и с меньшей вероятностью за счет избыточности).
По моему, без философии, описанной в предыдущем моем послании, не обойтись в ответственных девайсах.
Да, речь можно вести о "кратковременной выживаемости" памяти CLB между периодическими проверками и исправлениями. Однако, это период может быть очень коротким, порядка 100 мкс. Целесообразность тает на глазах.

Можно сделать в рамках внутренности каждого CLB коррекцию ошибок в параллельном исполнении, которая мгновенно исправляет, как только. Использовав какой нибудь простой код, типа Хэмминга, и асинхронную логику для вычисления наличия и места ошибки.

Кстати, длинный регистр сдвига, это тоже память (лишняя!), в которой тоже может произойти ошибка, причем даже обратная той, которая произошла в RAM. И останется она совершенно незамеченной. Или инициирует лишнюю перезагрузку. Так что вопрос тут очень даже относительный

Я уже не говорю про скорость сравнения всей ОЗУ через регистр сдвига с эталоном. 100 мкс отдыхают.

Вы меня немного не поняли. Возможно, я не совсем точно описал.
Ни о каком RAM как именно RAM я не говорю.
Только о конфигурационном сдвиговом регистре. RAM только в этом смысле. И даже не Random A, а последовательный, SAM, FIFO с параллельной выгрузкой\загрузкой.
Сорри за неточность.
Лучше перечитать мои каракули через призму этого уточнения.

А почему все же не хочется пойти по пути клонирования аналогов? Это же существенно дешевле в плане софта и быстрее отдача. Или это не коммерческий проект?

Есть проблема в получении соответствия битстрима и эл. схемы. Реверс-инженеринг может оказаться сложнее написания своего софта.
Китайцы, скорее всего, тупо украли схематику. Хотя, обидеть их не хочу, молодчики. Может, и сами содрали.

Коммерции пока никакой. Но всё это, конечно, делается для вероятности получения денег в перспективе.
И не только денег, но и чипов для юзеров, естественно.

Моё мнение - в России это будет нежизнеспособно, если только за последние несколько лет в ВПК ничего кардинально не изменилось.

Ведь FPGA делают зачем вообще (и для космоса в частности)? Затем, что в мелких сериях они получаются дешевле заказных кристаллов. В российском же ВПК вопрос стоимости просто не стоит. Им будет проще код на Verilog, прошедший прототипирование на FPGA (импортной, так как против применения импорта для прототипирования никто не возражает) просто выпустить в кристалле, и всё. Будет занято больше людей, будет сгенерирован больший оборот средств. Посмотрите например, что делает НПЦ "Элвис". Как думаете, какой спрос на их продукцию? Окупает этот спрос изготовление масок хотя бы? Тем не менее, чипы успешно выпускаются, в том числе и RadHard исполнении.

+100500
тема radhard вообще отдельная тема (по космосу)
поскольку норму которую дают приводит к накопленной дозе 100 мегарад - и кроме металла защиты нет
а тзч тут вообще отдельная песня- вероятность пролета частицы с энергией выше 50 МЭВ(пик Брегга- защита 3 граммами материала- вполне нормально над кристаллом) равна гдето более 300 лет через 1 см квадратный
и вообщем то если от тзч при зашелкивании нет РАЗРУЩАЮЩЕГО действия то проще конструктивно разнести задачу троирования в пространстве- чем гарантировать отсутсвие реального сбоя - для закрытия по бумажкам да действительно будет достаточно рад стойкости по отсутствию тиристорного эффекта при испытаниях- а вот для жизни когда там летают 100ГЭВ и метеориты чебаркульские аппаратная стойкость несколько призрачна
для атомной промышленности тут тоже отдельная статьяс этой стойкостью

Это не так. Запуск в кристалле это очень долго и хорошо при наличии отлаженной схемы. А она появляется зачастую только к концу ОКР. Прототипировать можно макет стоящий на столе. А если нужно пройти разные климатические и летные испытания поставить туда импорт невозможно. Так что в военке спрос на плис точно будет. И ВПК в большинстве случаев это всегда мелкая серия.

Это зависит от площади. Сделать размещение в кристалле готового кода, который может поместиться в обсуждаемые FPGA - это совсем не долго, производство занимает ещё меньше времени.

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

А ещё вернее в условиях России найти человека со связами в ВПК, и тупо выбить финансирование на проект вперёд. Тема ведь модная, а в условиях тотальной разжопицы с США будет ещё моднее.