Перейти к содержанию

S_Hawk

Участник
  • Публикаций

    30
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о S_Hawk

  • Звание
    Участник

Посетители профиля

578 просмотров профиля
  1. т.е. сгенерированный клок после PLL будет сдвинут относительно входящего в микросхему? тогда, получается, неправильно писать create_generated_clock -name clk2 -source [get_ports {iclk}] ... т.к. clk2, который после выхода PLL не совпадет по фазе с iclk? точнее так сформулирую вопрос: есть разница в двух описаниях create_generated_clock -source {iclk} ... create_generated_clock -source {inst_pll|pll_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|refclkin} ... между iclk и inst_pll|pll_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|refclkin есть, ведь, задержка? P.S. аа... понял... т.е. временной анализатор не учитывает этих задержек, что внутри PLL, что на пути к PLL? тогда тактовую до PLL и после PLL нужно разносить в разные группы? или предпринимать дополнительные танцы для их синхронизации, что может быть нужно в Source-Synchronous Input например?
  2. (после прочтения "Synopsys Design Constraint — язык задания временных ограничений на примере Altera TimeQuest. Часть 2" вопрос возник) Развейте, плиз, мои сомнения: Если выход PLL в .sdc-файле описать через create_generated_clock -name clk2 -source [get_ports {iclk}] [get_pins {plllaltpll_componentlauto_generated|plniclk[0]}] , то при трассировке путей временной анализатор в пути нового клока не учтет задержку от входа исходного клока iclk до входа PLL и, тем самым будет вносить ошибку в расчет времянок? В отличие от использования derive_pll_clocks, который сгенерирует строку: create_generated_clock -source {plllaltpll_componentlauto_ generated|pll1linclk[0]} -name {plllaltpll_componentlauto_generated|pll1lclk[0]} {plllaltpll_ componentlauto_generated|pll1lclk[0]} и в этой строке, по идее, должна быть учтена задержка между iclk и входом PLL? Или я что-то неправильно понимаю? Т.е. вопрос, конечно, не в выборе команд, а правильности указания в create_generated_clock порта iclk вместо выхода PLL
  3. Если есть, допустим, 100 тактов, разбиваем весь входной набор на группы по 100 бит. Для каждой группы создаем сдвиговый регистр, счетчик и фифо. На каждом из 100 тактов: если крайний бит == 1, заносим значение счетчика в фифо. увеличиваем счетчик, сдвигаем регистр на 1 бит. Остается только слить все фифо вместе...
  4. на двух гигах вылетел? Тогда либо при загрузке сказать, чтобы 3 Гига для приложений использовал, либо переходить на 64 разряда (можно и на WinXP-64 - тоже работает)...
  5. Цитата(jojo @ Jun 9 2012, 11:52) С плисами проблем нет. Вот с интегрированием и чужой программой майнера придётся повозиться. Делал и то, и другое. С программой майнера возни было значительно меньше
  6. Цитата(jojo @ Jun 8 2012, 13:16) Вы меня заинтриговали, я столько не получаю ))). Пойду, склепаю макет. Пожалуй, будет сложнее интегрироваться в чужой майнер, чем посчитать хэши. Работенка на пару месяцев. только 100ГХ/с - это ~180 шт. StratixIV-230 или ~500 шт. XC6SLX150...
  7. Цитата(jojo @ Jun 5 2012, 16:20) Скажите, пожалуйста, какой экономический эффект будет от применения этих плат. Например, есть сервер на 100 Гхэш/с, сколько баксов в месяц "нагуглится"? 100 Гхэш/с - это ~ $9000 в месяц...
  8. C8 - это и есть speed grade. то, что собирается на C6 с тактовой 200, на C8 собирается на 150 МГц.
  9. на этой плате хорошо, если выжмется 10 (десять) MH/s...
  10. я по 4 часа жду полной компиляции и около часа синтез на стратикс4-230. А что делать?... Кстати, у меня синтез в один поток идет. Подумал, может AHDL виноват? Или на Verilog и VHDL Quartus тоже в один поток синтезирует?
  11. не пойму, в чем проблема в альтеру запихать код, который совершит на лету тот же самый старый патч, который был для обычной ПЗУ? Тот патч (старый) большой был?
  12. я пару раз баловался с подобной задачей. Для себя нашел выход - собираю проект на завышенной частоте и делаю логикЛок для всего, кроме pll и интерфейсной мелочи. Потом понижаю частоту и собираю повторно.
  13. перебор ключей криптоалгоритма DES - вот та задача, на которой ПЛИС еще никто не уделал (асики не в счет). Архитектура алгоритма достаточно специфична и хорошо ложится на 6-входовые LUT-ы.
  14. Цитата(wolfman @ Oct 25 2010, 21:50) Вопрос, если шифровать IP-пакеты. Из Ethernet кадра вытаскиваем IP-пакет, шифруем, затем нужно ли его заново упаковывать в IP-пакет, ведь он станет больше по размеру или же можно сформировать обычный Ethernet-кадр? Или же потрошим не только Ethernet-кадр, но и IP-пакет, данные IP-пакета шифруем, собираем новый IP-пакет и передаем? Или все это должно задаваться на уровне ТЗ? Ethernet шифровать значительно проще, но, редко когда это бывает нужно (почти бессмысленно)... А вот с шифрованием IP столько подводных камней, что все равно, все, кто пробует это реализовать, приходят к какому-то подобию IPSEC-а. В нем есть 2 стадии: 1- стадия установления соединения. Это протокол ISAKMP. На этом этапе вырабатывается общий ключ для шифрования трафика. Если ключ прописывать заранее, то стадию можно опустить или значительно упростить. Этот обмен проходит по протоколу UDP, обычно с/на 500 порт. 2- стадия, собственно шифробмен. Пакеты пакуются в ESP с дописыванием векторов инициализации и контрольных сумм и/или подписей. В ПЛИСах реализовывать все это слишком муторно. Можно первую стадию реализовать на каком-нибудь процессоре, а ПЛИС использовать только как криптоакселератор для второй стадии. Обычно, в маршрутизаторах так и делают...
  15. а точно нужно Езернет шифровать? Насколько я понимаю, в наше время езернет в открытом виде уже по всем точкам подключения не ходит, а присутствует только в свичах. Хабы уже не делают. Кроме того, у всех пользователей должен быть один и тот же ключ, что существенно ослабляет схему. А для шифрования точка-точка лучше что-то стандартизованное использовать. Какой-нибудь ipsec, skip... Это поверх ip, но зато специфицированно.