[makc 192]

Reset в схеме присутствует?

[lincolndsp 0]

в таком виде:

 

RST_I:IN std_logic

 

использовал только для сброса конечных автоматов в S_IDLE.

[makc 192]

Это Ваш пользовательский сигнал, я же имел в виду GSR. Что у Вас с ним происходит?

[lincolndsp 0]

Это Ваш пользовательский сигнал, я же имел в виду GSR. Что у Вас с ним происходит?

 

поиском сигналов,нашел только множество сигналов gsr_resolved,которые сначала '1' длительностью 1 цикл, а затем принимают нулевое значение. отдельно сигнала GSR не отображается.

 

1.скрин с результата Behavioral Simulation

2. cкрин с результата Post-Translate Simulation

 

не пойму, в чем проблема :smile3046:

[BSV 0]

В проекте используется один тактовый сигнал или несколько? Параметры сигналов тестбенча (setup, hold time) нормальные?

 

Приведенные времянки неудачны, так как проблемы начинаются видимо раньше. Сигналы ready_o, we_gamma_o, addr_gam_o кто формирует? Почему они в неопределенном состоянии? Влияют они на интересующие Вас сигналы?

[Ufolog 0]

Вот здесь лежат исходники для ГОСТ 28147-89 для режима простой замены

http://www.sendspace.com/file/haeds8

Режим с обратной связью предлагаю доделать самостоятельно, если он нужен.

 

Можно еще раз выложить а то ссылка битая ((( или может у кого нибудь осталась та версия буду очень презнателен

Изменено 4 февраля, 2008 пользователем Ufolog

[lincolndsp 0]

В проекте используется один тактовый сигнал или несколько? Параметры сигналов тестбенча (setup, hold time) нормальные?

 

Приведенные времянки неудачны, так как проблемы начинаются видимо раньше. Сигналы ready_o, we_gamma_o, addr_gam_o кто формирует? Почему они в неопределенном состоянии? Влияют они на интересующие Вас сигналы?

 

все спасибо BSV. Проблема была в том, что входной сигнал Start_1 надо было инициализировать

в тестбенче в ноль, а то при выполнении if Start_1='1' then... else .... стопорилось, так как неопределенное состояние никак не вписывалось.

 

В проекте используется один тактовый сигнал или несколько? Параметры сигналов тестбенча (setup, hold time) нормальные?

используется 1 GCLK, тестбенч пишу в текстовом файле, поэтому не устанавливал setup и hold time

[lincolndsp 0]

На кристалле Spartan 3 xc3s400 на Post_Route and Place удалось реализовать ГОСТ

в режимме гаммирования с timing constraint 15 ns, меньше не получается.

При пересчете на пропускную способность из расчета 35(32+3 дополнительные) циклов

получается в районе 150 Мбит/с.

Хотел бы спросить мнение профи, насколько удачно получилось у меня это сделать и тп.

[BSV 0]

В режимах гаммирования и гаммирования с обратной связью можно и вовсе обойтись 32 тактами. Максимальная частота на Спартане3 с самым большим спидгрейдом получалась около 120 МГц (только ядро, то бишь простая замена), но уж 100 всяко должно получиться. Гаммирование - более сложный алгоритм, так как там есть еще один 32-разрядный сумматор (даже 33, если учесть сложение с переносом из старшего разряда) и может получиться похуже. 15 нс получалось даже на Спартане 2е.

[ReedCat 0]

В ту же тему... :)

 

Пробую реализовать режим простой замены.

Для первичного тестирования гоняю алгоритм с нулевым ключом (чтобы не влиял порядок подключей) и тождественным коммутатором.

 

По идее - два прогона через алгоритм должны давать исходные данные.

Ан нет, не дает... Интереса ради зациклил - и получил, что он даёт-таки исходные данные, но не через два, а через три (!!) прогона через алгоритм.

Вот сижу и думаю, как такое может быть? :(

[BSV 0]

Должно, так как при нулевом ключе это будет эквивалентно последовательным операциям зашифрования, а затем расшифрования или наоборот (причем от узла замены, по-вашему - коммутатора, это не зависит). Что-то не так в реализации - накопители после 32-х циклов местами меняете?

[ReedCat 0]

накопители после 32-х циклов местами меняете?

 

Нет, не меняю. А надо? Расшифрование отличается не только порядком ключей, но и порядком накопителей?

 

З.Ы. Опечатки в официальном тексте стандарта просто измучали. :(

Видимо, не все восстановил. :(

[BSV 0]

Нет там никаких опечаток, читайте внимательней. После 32-х циклов преобразования (неважно при зашифровании или расшифровании) значения в накопителях (неудачно выразился в предыдущем посте) меняются местами.

[ReedCat 0]

Нет там никаких опечаток, читайте внимательней. После 32-х циклов преобразования (неважно при зашифровании или расшифровании) значения в накопителях (неудачно выразился в предыдущем посте) меняются местами.

 

Сергей, Ваша правда, действительно, если их поменять местами, то всё начинает работать как нужно.

 

И при внимательном чтении стандарта "засада" нашлась... :01:

 

Спасибо!

[SAR 0]

В режимах гаммирования и гаммирования с обратной связью можно и вовсе обойтись 32 тактами. Максимальная частота на Спартане3 с самым большим спидгрейдом получалась около 120 МГц (только ядро, то бишь простая замена), но уж 100 всяко должно получиться. Гаммирование - более сложный алгоритм, так как там есть еще один 32-разрядный сумматор (даже 33, если учесть сложение с переносом из старшего разряда) и может получиться похуже. 15 нс получалось даже на Спартане 2е.

 

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

 

У меня такой фокус получился с кордиком на спартане - вместо одного 16-битного параллельного вычислителя было поставлено 16 последовательных, однобитных. Насчет экономии по площади кристалла сейчас уже трудно вспомнить, но общая производительность стала больше на 20%.

 

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