Выбор САПР для оценки 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]

если у этого чипа будут какие-то ножки наружу - то одна ножка будет больше 650 гейтов по площади

а если это все-таки какой-то фрагмент, который 100000 раз повторяется в проекте, то возможно накладные расходы (доставка значений ключа и сообщения до этого блока) может быть гораздо больше чем логика в блоке

так же есть оптимизация по скорости, а не по площади - может быть на 650 гейт будет работать на 10МГц, а чтоб заработал на 100МГц понадобится 2000 гейт
также для скорости могут вставлятся дублирующие триггеры и логика

также между ячейками оставляются пространства для проводов и т.д.

Естественно, не рассматриваются "ножки наружу". То есть, это - по сути аналог IP-Core Xilinx, делаем некое криптоядро для использования снаружи, вокруг вешаются всякие модули приема/передачи информации, соответствия неким протоколам, и т.д., т.е. о входах/выходах алгоритма авторы заботиться и не должны.

Скорость там тоже на уровне - Вы посмотрите внимательно, там за такт работы схемы реально считаются только 4 бита результата 1 итерации ГОСТа (итого, 8 тактов на итерацию, 256 тактов на зашифрование 64 бит открытого текста, и похоже, еще 8 тактов на обмен состояниями). Мне ISE дает оценку 340 МГц из 500 возможных для Virtex5.

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

Вот не очевидно: как сравнить число LUT и FF ПЛИС c GE ASIC?
На практике для ПЛИС получается так:
1. 100 LUT + 200 FF
2. 200 LUT + 100 FF
и что из них лучше если тупо VHDL скомпилировать под ASIC?
У ПЛИСов фиксировано количество входов LUTов, поэтому для них методы оптимизации совсем другие.

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

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

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

Сообщение отредактировал Terrarium - Mar 13 2013, 17:40