клонировать XC4006, есть ли смысл? Опции

[zzzzzzzz]

Появилось предложение инициативно клонировать XC4006, как RadHard. 16х16 СLBs.
С выхлопом года через 2, для милитари.

Возникли у меня сомнения на счёт востребованности и перспективы.
Вопрос к гуру FPGA - есть ли в этом смысл?
И если смысл есть, то с какого именно размера он есть и будет ещё хотя бы лет 5-7?

Спасибо.

[zzzzzzzz]

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

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

Спасибо.

[SM]

2. Можно выделить спец. линию ConfigError, на которую открытыми стоками сообщать о несовпадении конфига в сдвиговом регистре и защелках входов CLB. В некоторых случаях (помимо сигнализации) можно найти дефектный бит или биты (алгоритм довольно сложный будет, но реальный) и переконфигурироваться с учётом этой ошибки. Нужно это?

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

3. Шина питания конфиг-регистра отдельна от питания ядра и выведена на ногу корпуса, к которой подключена батарея или конденсатор большой емкости. При пропадании питания периферии или ядра конфиг в регистре сохранится продолжительное время. Нужно?

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

4. Можно озвереть и сделать тройное резервирование конфиг-регистра с мажоритаром 2 из 3 по выходу для выживания какое-то время при агрессивной бомбёжке ТЗЧ. Дикое усложнение, но всё-таки, насколько это привлекательно?
Возможно даже не мажоритар, а исправление ошибки.

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

4. Какого разряда? 8-го, 16-го или всё же 32-го?
5. Можете подкинуть самый сложный (схемотехнически) разряд, который вам встречался на практике?

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

[zzzzzzzz]

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

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

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

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

...
У меня, пока, самый жирный реальный счетчик имеет 48 бит (просто таймер). Однако сейчас уже 62-битный намечается (инкремент адреса в дма контроллере для PCIe)...

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

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

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

[SM]

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

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

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

[zzzzzzzz]

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

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