Выбор САПР для оценки 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 не удалось даже в китайском гугле...

[Torpeda]

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

Но вот возникла задачка: на конференции 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

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

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

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

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

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

Как-то так.

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