клонировать 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 фиг вам.