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

Synopsys DesignCompiler сообщает площадь проекта для той библиотеки, для которой этот проект скомпилен.
из документации к библиотеке берется площадь элемента NAND2 с 0-вым выходом
поделив первое на второе получается оценка в GE

Это я понимаю, но с

проще найти компилер и библиотеку, чем, например, дать свой код для оценки китайцам

не согласен - живых ссылок найти не удалось
Если знаете - плиз, отпишите в личку...

но общие зависимости (то есть пропорция) между затратами в ISE и в DC они сохраняются - то есть получите коэффициент пересчета LUT-ов в GE из старого проекта и помножте LUT-ы в новом - вполне коректная для такого разговора оценка получицца

Если дизайн где-нибудь на 300000GE, то да. А когда речь идет о сотнях, тут уже сильно сказывается природа LUT-ов. Ведь по сути, это 32 или 64 бита памяти, которые по 5 или 6 входам (это я применительно к Virtex5) выдают однобитовый результат. А в асике вполне возможно трех или 5-битовые подстановки (хотя ее Xilinx через мультиплексор делает - красота!) эффективно нарисовать. Поэтому сравнить свои поделки с вышеприведенной работой с точностью не плюс/минус километр - увы.

ну и еще - результат работы DC (площадь, GE) зависит от многих параметров - какие опции (например DW или compile_ultra), какие констрейны, как оптимизировано (например BRAM для ксайлинса обычно улучшает по сравнению с логикой, а для DC ухудшает) и т.д. да в конце концов, насколько криво написан RTL

Ну для себя на FPGA обычно делаю оптимизацию по площади, финальные "забеги" - с повышенной точностью (хотя тогда дизайн разводится почти сутки до Static Timing Report), а про BRAM уже говорил - или все алгоритмы используют его, или все на LUT-ах. В качестве констрейнов мне наш гуру, пока не уволился, пропагандировал правило - объем заполнения кристалла не выше 70% (дальше синтезатор тупит), частота - 50% от максимально возможной кристалла. По его работам (в-основном, fully pipelined - не знаю русского термина? криптографические схемы, сколько копий удастся затолкать в дизайн, а дальше некая логика анализа результатов перебора), если в них не укладываться, обычно проще было поставить два кристалла рядом, и разбить алгоритм пополам. Хотя перед пенсией ГОСТ он любовно "вылизал" до 450МГц на Virtex5, если не ошибаюсь... Уперся в тепловыделение конкретных закупленных плат.

и мне покоя не дает цифра 650 (очень мало) - это получается что-то проще DES-а? (я в криптографии профан-любитель, пару лекций послушал когда-то давно, про ГОСТы вообще не знаю)

Ну они там "жульничают" вовсю, на самом деле... Так, если посмотрите, то 256 бит ключа берутся "из воздуха" (а я их обычно "защелкиваю" в триггеры), есть еще натяжки с точки зрения "жизненной" а не теоретической реализации. Так, хотя стандарт ничего не говорит о том, что подстановки (8 4-битных) должны быть разные, понятно, что применение одной подстановки к 4-битным блокам по очереди тоже позволяет оптимизировать дизайн, ну и т.д.

А я по сути в схемотехнике профан-любитель, но иногда математики-теоретики очень хотят знать, как выглядят те или иные конструкции "в железе". Приходится вспоминать институтские крохи