[Epikur 0]

lincolndsp

BSV опередил меня с ответами :) Тут только стоит добавить, что компонент двухпортовой памяти генерируется автоматически при помощи утилиты CoreGen (в составе Xilinx ISE). Задаёшь размерность шин адресов и данных, уровни активных сигналов, и всё. Но если в этом нет необходимости, хранилище ключа можно сделать и просто на 256 D-триггерах.

 

BSV

Спасибо!

 

В предлагаемом варианте совершенно не рассмотрен такой эротичный и каверзный момент, как загрузка узла замены (подстановки). Видимо, предполагается работа с фиксированным узлом замены, однако не всегда это допустимо.

Да, узел замены фиксированный. Для ГОСТ-а это долговременный открытый параметр, и в большинстве случаев фиксированная таблица замены вполне пригодна. В случае FPGA это позволяет экономить огромное количество ресурсов и (скорее всего) повышает производительность. К тому же, фиксированная таблица замены защищает потребителя от заведомо слабой таблицы.

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

Также, этот участок кода...

Он синтезируется на D-триггерах с асинхронными сбросом и предустановкой. ИМХО, это решение лучше, так как позволяет развести часть логики на другие входы.

Тем более, что компоненты D-триггеров с синхронными сбросом и предустановкой (кажется) синтезируются из асинхронных с внешней синхронизацией сброса и предустановки. (Сейчас не могу проверить).

[BSV 0]

Да, узел замены фиксированный. Для ГОСТ-а это долговременный открытый параметр, и в большинстве случаев фиксированная таблица замены вполне пригодна. В случае FPGA это позволяет экономить огромное количество ресурсов и (скорее всего) повышает производительность. К тому же, фиксированная таблица замены защищает потребителя от заведомо слабой таблицы.

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

Для систем защиты конфиденциальной информации - этот подход применим, обычно используется узел замены из контрольного примера к ГОСТ'у. Но лучше сделать его загружаемым, тем более, что сделать это можно и без потери производительности (но не без дополнительных ухищрений ), это позволит не пересобирать проект при смене узла замены.

 

Он синтезируется на D-триггерах с асинхронными сбросом и предустановкой. ИМХО, это решение лучше, так как позволяет развести часть логики на другие входы.

Тем более, что компоненты D-триггеров с синхронными сбросом и предустановкой (кажется) синтезируются из асинхронных с внешней синхронизацией сброса и предустановки. (Сейчас не могу проверить).

Не выйдет у Вас такой фокус, хотя получилось бы красиво - позволило бы выкинуть мультиплексоры на входе в N1 и N2. А в Вашем случае от входа (динамически меняющегося параметра) зависит что применять - сброс или предустановку, или нужно предварительно сбрасывать регистры в 0 или 1, а уж затем грузить в них Вашим способом значения, но тогда описание уже должно быть совсем другое.

[Epikur 0]

Для систем защиты конфиденциальной информации - этот подход применим, обычно используется узел замены из контрольного примера к ГОСТ'у. Но лучше сделать его загружаемым, тем более, что сделать это можно и без потери производительности (но не без дополнительных ухищрений ), это позволит не пересобирать проект при смене узла замены.

Интересно было бы послушать как, если это не коммерческая тайна :)

 

Не выйдет у Вас такой фокус, хотя получилось бы красиво

Чёрт его знает, на самом деле. По моему представлению, каждый бит вектора "LongWordIn" подаётся и на сброс и на предустановку соответствующего триггера, но предварительно маскируется сигналом "StartDelay". Легко может быть, что ошибаюсь.

То, что эта реализация работает - 100%. Но всё равно проверю ваш метод - будет ли лучше. Только это будет не сразу.

[lincolndsp 0]

а что значит Startdelay? пожалуйста скиньте скриншоты работы

Testbench, чтобы лучше понять как программа работает по алгоритму.

сколько бит за такт обрабатывает программа?

Изменено 24 сентября, 2007 пользователем lincolndsp

[Epikur 0]

Всё же захотелось проверить прямо сейчас.

У меня там в самом модуле логика немного иная, но эта часть такая же.

По исходному методу

Максимальная частота: 102, 469 Мгц

Количество слайсов: 129

По вашему методу

Максимальная частота: 93,423 Мгц

Количество слайсов: 120

 

Хотя на заявленные 102 Мгц схема всё равно не работает. Реально используется частота 72 Мгц.

[BSV 0]

Всё же захотелось проверить прямо сейчас.

У меня там в самом модуле логика немного иная, но эта часть такая же.

По исходному методу

Максимальная частота: 102, 469 Мгц

Количество слайсов: 129

По вашему методу

Максимальная частота: 93,423 Мгц

Количество слайсов: 120

 

Хотя на заявленные 102 Мгц схема всё равно не работает. Реально используется частота 72 Мгц.

А что за камень? То, что Ваш вариант быстрее - это очевидно - там на один LUT в цепочке меньше. Я наверно не совсем прав по поводу реализуемости, обдумал получше - это возможно (как вы и описали маскированием StartDelay), но я бы все же описал явно и сброс и предустановку - нельзя давать синтезатору повод для самодеятельности.

 

Про загрузке подстановки. Как Вы давно наверно поняли, основная проблема - как избавиться от мультиплексора на входе блоков замены, но вместе с тем иметь возможность подавать адреса при загрузке. Очень просто - нужно либо загрузить нулевой ключ и задвигать в накопители векторы с нужными адресами 0 ... 0, 1 ... 1, F ... F, либо сбросить в 0 N1 и вместо ключа записать те же адреса (память позволяет - в один блок распределенной памяти 16x32 влезает 2 ключа), выбор адреса будет обеспечиваться счетчиком циклов. Возни много, но это нужно делать только один раз при старте схемы, так что значения это не имеет.

 

а что значит Startdelay? пожалуйста скиньте скриншоты работы

Testbench, чтобы лучше понять как программа работает по алгоритму.

сколько бит за такт обрабатывает программа?

Да уж, Вам все разжуй и в рот положи :angry2: . Один такт - один цикл алгоритма. Соответственно результат (64 бита) получается за 32 такта (ну или чуть больше, если учесть загрузку и выдачу результата).

[Epikur 0]

lincolndsp

Для чего нужен StartDelay - сейчас уже не помню, честно говоря. Но помню, что ввёл его не спроста. Скорее всего это для того, чтобы блочная память успела переключиться на первый кусочек ключа после старта. Если Start короткий (1 такт), то не успеет.

 

Выкладываю симуляцию в модельсиме.

Test89.txt - очень кратенькое описание

UntitledN.bmp - 4 скрина, показывающие процесс работы после команды Старт.

Там же в пакете есть файлы для тестирования и файл блока двухпортовой памяти. Во избежание, так сказать :).

Моделировать можно при помощи Модельсима, в режиме "Simulate Post Translate Model" (если сделать Behavioral, то блочная память окажется не найденной). Само собой, в модельсиме должны быть подключены Xilinx-библиотеки.

Заодно и сам проверил - код работает нормально.

Фсё, наслаждайтесь :)

 

BSV

Камень Spartan3

...нельзя давать синтезатору повод для самодеятельности.

Да, скорее всего я так и сделаю. Тем более, что частота всё равно не граничная, а 9 слайсов сэкономлю :)

TestBench.rar

[lincolndsp 0]

Epikur,

спасибо. с testbench и конкретно заданными параметрами намного

все понятней стало. Но все же я заметил некоторые изменения по

сравнению с файлами , которые ты выложил на форуме ранее, например,

отсутствие флага lastcycle. Пожалуйста, выложи исходники со всеми изменениями.

Изменено 24 сентября, 2007 пользователем lincolndsp

[Epikur 0]

:D

Исходники не менялись, LastCycle никуда не делся. Просто на симуляции я забыл его вывести. Попробуй сделать симуляцию самостоятельно - там для этого теперь всё есть.

[BSV 0]

А если еще все компоненты схемы - N1, N2, Память ключей (у меня была распределенная), сумматор, память подстановок RLOC'ами в кучку (прямоугольник 5x16 слайсов) собрать - можно и 120 МГц получить, но это хлопотно.

[lincolndsp 0]

сейчас займусь)

[Epikur 0]

BSV

Ффух... Увы, но моя квалификация ещё пока не позволяет мне этого сделать. Хотя, никогда не поздно подняться выше. Спасибо за идею :)

[Very_hard 0]

Кроме всего вышеописанного ключи и подстановки можно хранить не в памяти, а в триггерах, и даже не в триггерах, а в элементах SRL16E(применительно к Xilinx). Это очень компактно по размещению и просто по загрузке. Производительность в районе 100 МГц.

[BSV 0]

Кроме всего вышеописанного ключи и подстановки можно хранить не в памяти, а в триггерах, и даже не в триггерах, а в элементах SRL16E(применительно к Xilinx). Это очень компактно по размещению и просто по загрузке. Производительность в районе 100 МГц.

А какая с этого радость, учитывая то, что ключи на циклах 25-32 подаются в обратном порядке? Все равно выбирать вектор ключа придется адресом, так что выигрыша в скорости по сравнению с распределенной памятью это не даст. Распределенная память (однопортовая ячейка 16х1) по размещению занимает ровно столько же - один LUT. Единственное что можно с этого поиметь - уменьшить количество линий на загрузку ключа и грузить его последовательно. Но информация редко шифруется на фиксированных ключах - чаще на производных, поэтому ключ нужно грузить часто, а потому быстро. Указанная Вами частота довольно смешно смотрится без указания типа ПЛИС, на которой она достигается.

[Very_hard 0]

BSV

Да, действительно: Spartan 3 - порядка 100Мгц, SpartanIIE - немного меньше. :)

Что касается ключей - ничто не мешает организовать последовательную загрузку ключей и блока подстановки блоками по 32 или 64 разрядов. Такой себе параллельный сдвиговый регистр... ;)