Выбор САПР для оценки Gate Equivalent Опции

[Terrarium]

У меня уже не первый год висит нерешенным вопрос следующего вида: необходимо сравнить вычислительную трудоемкость двух алгоритмов - ну, например, блочного шифрования, хеширования... И если для универсальных процессоров величина cycles per byte - цисло тактов процессора для обработки одного байта исходной информации фактически стала стандартом де-факто в кругу разработчиков подобных схем, то вот с FPGA и ASIC разброд и шатания.

Я прекрасно понимаю разработчиков Xilinx и Altera (да и остальных наверное), которые в определенный момент перестали вычислять Gate Equivalent для дизайна. Более того, собственные изыскания на эту тему показали громадный разброс GE в зависимости от того, как именно записать алгоритм в VHDL, расставить промежуточные триггера, использовать ли DSP и т.д. И до сего момента мне, в общем-то, вполне хватало сравнений именно реализаций схем в старой доброй ISE9, в которой GE еще считаются, при некоторых равных предположениях для алгоритмов - либо полностью параллельная схема, либо каждый такт только одну итерацию считаем, все константы реализуем логикой или храним в BRAM, и т.д.

Но вот возникла задачка: на конференции CHES 2010 Axel Poschmann, San Ling, and Huaxiong Wang взяли да засунули наш ГОСТ 28147-89 в 650GE с помощью Synopsys DesignCompiler для библиотеки UMC L180 0.18μm, а в 2011 году китайские негодяи предложили ряд атак на него, пользуясь регулярностью ключевой развертки (http://eprint.iacr.org/2011/558). Ну и возникает вопрос, а если эту самую ключевую развертку неким образом модифицировать, насколько "потяжелеет" реализация? Здесь уже синтез FPGA не годится...

Вы уж извините, что столь нудно и подробно, но просто проблемка специфическая - моей задачей не ставится разработка реального чипа, а получение "сферической лошади в вакууме", но сравнимой с уже посчитанной для ASIC. Вот и возник вопрос: а есть что-нибудь достаточно доступное (особенно с торрентов, ибо мне нужна только итоговая циферка, хоть транзисторов, хоть GE - начальство явно Synopsys не оплатит, а в торрентах, его, увы, очень мало, даже китайских), в чем бы это можно было посчитать?

Вроде простая задача, тем более что в эти 650GE не входят триггеры для хранения ключа (и понятно, почему ), а вот найти что-то доступное для не сильно продвинутого в ASIC не удалось даже в китайском гугле...

[Terrarium]

Вопрос поставлен комплексно конечно....
1) Определить вычислительную трудоемкость алгоритмов, т.е. число тактов процессора для обработки одного байта....

Для определения "число тактов процессора для обработки одного байта" если алгоритм только в виде идеи и блок-схемы существует предложить ничего конкретного не могу... тут математическое моделирование помочь скорее может.
Если алгоритм реализован на уровне RTL - запустите симуляцию и узнаете точно сколько тактов ему нужно.

Во-первых, в этом абзаце речь шла об универсальных процессорах, то-есть система команд дана нам свыше, и ничего менять нельзя. Но эта характеристика тоже важна, поверьте.
Во-вторых, рад бы, но реализация, сами понимаете, авторская, закрытая, исходников нет.

2) "Китайци реализовали ГОСТ 28147-89 в 650GE с помощью Synopsys DesignCompiler для библиотеки UMC L180 0.18μm...."
Понятно
"А если эту самую ключевую развертку неким образом модифицировать, насколько "потяжелеет" реализация"?

Что значит потяжелеет? В мире ASIC это означает площадь кристала.
Вам надо сделать оценку площади будущего кристала или всётаки сравнить 2 RTL реализации?

Сравнить. Но при том, что сделать реализацию в синопсисе я не могу за отсутствием синопсиса. Реализации на ПЛИСах, хоть и показывают некую среднюю температуру по больнице, но иногда очень сильно лажают. На СБИСах, похоже, можно сделать гораздо лучше.
Вариант модификации ГОСТа, например, подразумевает наличие двух различных подстановок - по 4 включения каждой на итерацию. Отсюда, видится, нужно добавление одной подстановки плюс демультиплексор, зависящий от конкретного шага алгоритма. Если эта функция тривиальна - 4 верхних подстановки равны, 4 нижних подстановки равны - ну тут все просто элементарно. Но вот по криптоанализу это не всегда есть хорошо ((

а) Если сравнить реализации, то получите из ISE репорт про количество тригеров и гейтов и сравнивайте что больше, а что меньше и на сколько %
б) Если надо сделать оценку площади будущего кристала, то тут хуже...
- Достаточно точно можно получить эту оценку отсинтезив проект в Synopsys DesignCompiler в вашей UMC L180 0.18μm.
Площадь всех тригеров и гейтов будет занимать примерно 70% будущего кристала.
- Менее точно можно прикинуть так: Вычисляем сколько гейтов на тригер получилось в предыдущем RTL . Из нового RTL узнаём сколько у вас тригеров. Узнаём сколько получится гейтов (зная сколько гейт\тригер). Находим насколько % больше гейтов и тригеров в новом дизайне. увеличиваем на этот процент площадь....

Как сравнить 30 LUT-ов и 53 FF-ов c 853 GE? что больше?

Повторюсь, нет у меня синопсиса. Был бы (тут молитва к модераторам - пустите на ftp, если у вас валяется!) - сгенерил бы. Пока у меня на ПЛИСах есть ключевая развертка примерно в 700 GE если ключ извне и 160 GE если ключ фиксирован... Площадь не нужна - обычно все меряются именно чистыми GE... Но это и рядом не лежит с 650 GE на всю схему. Т.е. я не могу утверждать, что моя vhdl интерпретация госта идеальна. Можно ведь и на 30 килогейтов написать...

Ну и наверное вопрос по ходу: вот у нас висит внешний (для алгоритма) ключ 256 бит. Из него, в зависимости от такта работы алгоритма шифрования, надо выбрать 32-битное слово, а потом, опять же в зависимости от такта, из этого 32-битного слова надо выбрать 4-битное слово, которое, сложив с 4 битами промежуточных результатов Х (и с carry - мы же по модулю 2^32 работаем!) занести в память по адресу, где лежало Х... Так вот, выборка ключевой информации на ПЛИСах как-нибудь кроме мультиплексоров решается? Если ключ фиксированный, САПР генерит ROM нужных размеров, и там это все очень экономично получается. А в случае, когда ключ - это переменная?

Да, а китайци DFT вставили? А-то это есчё площади процентов 50 добавит при ваших 650 GE (тригеров 100 я так полагаю). А-то сюрпризом будет если ASIC сделать....

Я привел ссылку на их работу выше. Более достоверной информации у меня нет. И что это за DFT? Понятно, что не Direct Fourier Transform, но вот дальше гугль заманчиво обширен ))

Сообщение отредактировал Terrarium - Mar 12 2013, 18:33

[Torpeda]

Как сравнить 30 LUT-ов и 53 FF-ов c 853 GE? что больше?

А что не понятно?
засовываем RTL1 в ISE и читаем репорт - 53 FF
засовываем RTL2 в ISE и читаем репорт - 60 FF
Разве не очевидно что больше и на сколько процентов?

Ваша постановка задачи абсолютно не ясна.
Толи вам про эфективность алгоритмов надо поспорить, то-ли про оптимальность реализации разных RTL в FPGA надо поспорить, толи вам вычислить площадь ASIC надо для разных RTL....
Неясно есть ли у вас 2 разных RTL о которых речь, или есть один RTL но у китайцев и вы хотите сравнить с ним алгоритм который есчё в уме, или вы только на уровне идей как-бы реализовать алгоритмы разными способами есчё думаете....
Вы FPGA собираетесь делать или ASIC или формулу изобрести?
Вы определитесь сначала - чё надо и чё у вас есть...