сразу оговорюсь, что, возможно, рецепта, которого я ищу и нету.
цель: более рационально использовать блоки BlockRAM:
в времена Spartan, SpartanII & Virtex все было хорошо: размер блоков ОЗУ был 512байт
при реализации т.н. S-boxes (а их надо, к примеру, 16 шт) с 8битной шиной адреса и 8битной шиной данных (8бит вошло - 8 вышло) ресурс BlockRAM используется полностью:
за счет двухпортовости используем 521байтное ОЗУ как два ПЗУ по 256байт - одно для прямого S-box, второе - для инверсного S-box (если проект того требует, если не требует - то блоки ОЗу задействованы на 1/2: использована двухпортовость, но половина адресного пространства не используется).
а вот как бы так заоптимизировать появившиеся в Spartan3, VirtexII & & Virtex4 блоки озу размеров 2Кбайта ?!?
сколько ни думал - всё одно получается - используется на 1/8 от номинального объема :(
может как-то спец. образом можно объединять массивы из BlockRAM (учитывая что этих S-box'ов нужно 16 шт?) дабы получить выигрыш в оптимальном использовании ресурсов(хотя за счет длин трасс может упасть производительность) ?!
Полная версия этой страницы: BlockRAM: экономная экономика
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(Doka @ Oct 28 2006, 18:20) 
может как-то спец. образом можно объединять массивы из BlockRAM (учитывая что этих S-box'ов нужно 16 шт?) дабы получить выигрыш в оптимальном использовании ресурсов(хотя за счет длин трасс может упасть производительность) ?!
Например, чтобы упростить MixColumns.
Oldring, спасибо. Мысль понятна. Щас нагуглил вот:
:)
Цитата
On systems with 32-bit or larger words, it is possible to speed up execution of this cipher by converting the SubBytes, ShiftRows and MixColumns transformations into tables. One then has four 256-entry 32-bit tables, which utilizes a total of four kilobytes (4096 bytes) of memory--a kilobyte for each table. A round can now be done with 16 table lookups and 12 32-bit exclusive-or operations, followed by four 32-bit exclusive-or operations in the AddRoundKey step.
If the resulting four kilobyte table size is too large for a given target platform, the table lookup operation can be performed with a single 256-entry 32-bit table by the use of circular rotates.
If the resulting four kilobyte table size is too large for a given target platform, the table lookup operation can be performed with a single 256-entry 32-bit table by the use of circular rotates.
:)
Цитата(Doka @ Oct 28 2006, 22:01)
Oldring, спасибо. Мысль понятна. Щас нагуглил вот:
Цитата
On systems with 32-bit or larger words, it is possible to speed up execution of this cipher by converting the SubBytes, ShiftRows and MixColumns transformations into tables. One then has four 256-entry 32-bit tables, which utilizes a total of four kilobytes (4096 bytes) of memory--a kilobyte for each table. A round can now be done with 16 table lookups and 12 32-bit exclusive-or operations, followed by four 32-bit exclusive-or operations in the AddRoundKey step.
If the resulting four kilobyte table size is too large for a given target platform, the table lookup operation can be performed with a single 256-entry 32-bit table by the use of circular rotates.
If the resulting four kilobyte table size is too large for a given target platform, the table lookup operation can be performed with a single 256-entry 32-bit table by the use of circular rotates.
Зачем искать? http://csrc.nist.gov/aes/ - есть много описаний разнообразных реализаций. Анализируйте идеи.
Цитата(Oldring @ Oct 29 2006, 13:20)
Зачем искать? http://csrc.nist.gov/aes/ - есть много описаний разнообразных реализаций. Анализируйте идеи.
что-то у меня уже второй день линк "Not Found" выдает :-/
Цитата(Doka @ Oct 30 2006, 14:19)
Цитата(Oldring @ Oct 29 2006, 13:20)
Зачем искать? http://csrc.nist.gov/aes/ - есть много описаний разнообразных реализаций. Анализируйте идеи.
что-то у меня уже второй день линк "Not Found" выдает :-/
Да, простите. http://www.nist.gov/aes
http://www.xilinx.com/bvdocs/appnotes/xapp228.pdf и далее по аналогии.
DmitryR, спасибо за XAPP.
Хоть это немного с другой стороны оптимизация и должны выполняться некоторые условия (запас по 2х разгону блочногоОЗУ), но с другой стороны, появляется возможность путем минимизации числа блочныхОЗУ уменьшить число длинных трасс, что по идее благоприятно скажется на общей производительности.
Хоть это немного с другой стороны оптимизация и должны выполняться некоторые условия (запас по 2х разгону блочногоОЗУ), но с другой стороны, появляется возможность путем минимизации числа блочныхОЗУ уменьшить число длинных трасс, что по идее благоприятно скажется на общей производительности.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.