oval

У меня identify_tps есть, но иерархия в Identify Instrumentor'e не доступна для инстанцированных в модуле верхнего уровня блоков. У меня абсолютно также. Проект у меня на VHDL. Может ситуация для Verilog несколько лучше? Точно! Пропробовал примерчик на Verilog'e - действительно все работает и иерархия доступна для просмотра и использования... Выходит либо мы что-то делаем не так на VHDL, либо нужно ждать исправлений. PS: Отправил Synplicity описание проблемы. Может быть они это как-нибудь прокомментируют... Понятно, давайте подождем. Теперь больше всего похоже на проблему интеграции Synplify и Identify.

У меня identify_tps есть, но иерархия в Identify Instrumentor'e не доступна для инстанцированных в модуле верхнего уровня блоков. У меня абсолютно также. Проект у меня на VHDL. Может ситуация для Verilog несколько лучше?

Но вот что интересно: если тот же самый проект Identify Instrumentor'a открыть из отдельно запущенного Instrumentora, то все будет работать нормально и блэкбоксов не будет... Да, действительно так, но если потом попытаться просинтезировать implementation instrumentor'а в Synplify, то он сваливается, снова не находя иерархии.

Попробовал методом от Vasiliy. Действительно все запускается и без патча, но проблема с Identify осталась, в иерархии проекта виден только верхний уровень, ниже блекбоксы :( Gate, а может быть Вы пробовали проект, в котором только один уровень иерархии? Такой вариант у меня тоже работает нормально.

Да, стоит попробовать методом от Vasiliy :) Может быть дело действительно в этом.

Да даже черт с ним, с возможностью редактирования и удаления implementation'ов. Самое обидное, что он ведь тем самым не дает подключать анализатор проекта к любой точке иерархии. Вообщем, похоже, что попытка интеграции Identify и Synplify пока не особо удалась.

Точно! "Ручками" получается. Но проекты-то большие, библиотек много :( Похоже придется скрипты писать. Такое ощущение, что самому synplify не хватает какой-то части лицензии, чтобы правильно запускать Identify. Но вот какой... Это пока неизвестно. :( Да, возможно. Есть еще предположение, что несколько неудалась попытка более тесно интегрировать Synplify и Identify. Я с таким встречался на Mentor'овских продуктах, когда в некоторых релизах даже элементарные вещи не работали. Identify 2.2 также валиться довольно часто.

Точно! "Ручками" получается. Но проекты-то большие, библиотек много :( Похоже придется скрипты писать.

Попробовал создать проект в Identify 2.3 и столкнулся вот с такими проблемами: создал проект в Synplify и оттуда вызвал Identify. Соответственно Identify взял исходники проекта Synplify, откомпилировал их и добавил в свой проект (в проект Identify). Так вот в этом проекте Identify, в иерархии проекта (закладка IICE) видно только содержимое верхнего уровня HDL модели, и все компоненты, его составляющие, видны как BlackBox компоненты. :( Кроме того, из Identify не удается открыть ни одного HDL исходника. В Identify 2.2 все было нормально. Может кто-нибудь встречался с подобным. В чем может быть дело? P.S. Есть подозрение, что Identify все еще болеет. При лечении использовал здешний метод от makc'а.

Не измерял - это Квартус позволяет задавать в свойствах мегафункции ФАПЧ. И в симуляторе (на времянках) это отследил - точно так и есть. До железяки дело пока недошло (через пару месяцев должно дойти), там и проверим, для этого есть резвый цифровой скоп. Только с чего там погрешности-то взяться? Только некоторый разброс задержки от триггера элемента ввода-вывода до пина. А он не долен быть большим. Вот заодно и узнаем, как оно на самом деле. :) Понятно. Да, скоп должен быть действительно резвый :) Но дело даже не в свойствах ФАПЧ, там действительно достаточно приличная точность, а в задержках трассировки и буферов ввода/вывода. На относительно старых технологиях, типа Xilinx V-II, я сталкивался с проблемами при попытках реализации таких фокусов. Возможно в более свежих, например V-4, ситуация лучше.

Думаю, такую точность получить на ПЛИС нереально, возможно нужно использовать внешние специализированные буферы-разветвители. На ПЛИС все будет очень сильно привязано к условиям (температура, напряжение питания и т. п.) У нас неоднократно возникали проблемы с подобными фокусами, даже на относительно низких частотах порядка 50МГц. Но, кто знает, может и повезет. ИМХО, такие вещи нужно делать с помощью специализированных элементов. А чем Вы с такой точностью измеряли эту задержку? Или это просто данные анализатора времен?

Можно попробовать вручную спланировать размещение внутри кристалла, например, задать области кристалла в которые поместить входные/выходные защелки шины PCI.

Вы имеете ввиду про use encrypting? Поставил галочку.При создании попросил пароль с подтверждением и выдал такую строку: Files being saved can not be encrypted -- no license for encryption is available :( Кряк брал с фтр (patch_identify.exe).Правда, с файлом лицензии ничего не делал( а надо?). Нет, насколько я понял, опция use encrypting распространяется только на файлы ваших исходников, то есть при сохранении проекта после вставки анализатора IICE, существует возможность сохранить и исходники в зашифрованном виде. Файл syn_dics.vhd всегда зашифрован.

Никак не лечиться, да и лечить не надо. Так и должно быть, просто указанный файл зашифрован. Читайте документацию, там все написано. Удачи!

Нет, следующее за 1000 значение будет 1001. Если нужно 0, то используйте функцию модуля (mod). Удачи.

Конкретно с IP Cores от Actel не работали, но работали с другими и создавали, и создаем собственные. Варианты здесь могут быть разные, в виде RTL исходников и/или синтезированного netlist'а. С исходниками, очевидно, в разы дороже. Имеет смысл, хотя бы потому, что значительно сокращается время разработки (если это конечно важно). Совершенно очевидно, что множество западных производителей пользуется именно таким подходом. Единственным препятствием может являться цена. Возможно, но естественно при наличии RTL исходников. Был такой опыт, но можно сказать, что времени отнимает очень много даже для незначительных изменений. Здесь речь идет о модернизации самого IP ядра. Производители обычно предоставляют не параметризованную RTL модель, а сборку "заточенную" под конкретные параметры, заказанные Вами при покупке. Это значительно усложняет задачу модернизации. Вообщем, все зависит от типа ядра, но модернизация дело очень трудоемкое. Может отличаться в разы, все зависит от составляющих системы. Например, чтобы создать полноценный контроллер шины PCI (PCI master + PCI slave с поддержкой всего, что только можно) с нуля потребуется не менее полугода, а то и более, работы коллектива профессионалов (здесь я не имею ввиду изделия "на коленках", а имею ввиду качественные изделия с качественным тестированием и продуманные на начальном этапе проекта). На подключение готового ядра обычно достаточно до месяца. Вот и оценивайте. Если модель качественная (хорошая документация, хороший код, удобный внешний интерфейс), то, как правило, проблем не возникает. P.S. Обратите внимание на предоставляемую на IP гарантию и поддержку. У крупных компаний получить оперативную поддержку даже в случае обнаружения фатальной ошибки в модели достаточно проблематично, обычно не менее месяца, пока они достучатся до разработчиков. Качественнее всего сервис у небольших компаний, которые "живут" за счет IP, это и понятно. Небольшие компании даже могут взяться за модернизацию IP по Вашему заказу. Все вышесказанное, мое личное мнение. Будут вопросы, спрашивайте. С уважением, oval

Имея не малый опыт работы с ПЛИС Actel, могу предположить, что запустить схему на частоте 152МГц для семейства ProASICPlus нереально, разумеется если эта схема не простой сдвиговый регистр. Попробуйте в порядке эксперимента создать проект простого счетчика и оценить полученные временные характеристики. Количество разрядов счетчика, который сможет работать на частоте 152МГц, может Вас удивить! Мы неоднократно боролись за частоты работы порядка 50МГц! Вообщем, вопрос г-на vitus_strom относительно семейства мне вполне понятен.

В результате не получено ни одного резюме :( В качестве Офф: что не так ? Нериальные требования или типа "черновая работа" тестирование ? Интересует просто так, на будующее.... На мой взгляд обязанности и требования сформулированы для целого отдела тестирования, но никак не для одного специалиста. Насколько я понял, Вам требуется целый коллектив. Думаю, что таких "универсальных солдат", подходящих под эти требования не так уж много. Особенно разносторонние области среди изложенных требований это, на мой взгляд, программирование PC (под Win) и знание Verilog и средств верификации, Verilog XL, Code Coverage. Слишком разные и специфические вещи. Что-то одно - не вопрос. Я сам, например, уже достаточно давно занимаюсь проектированием логики микросхем для FPGA и ASIC, но никогда не касался программирования под Win. Я лишь представляю себе, что требуется сделать и как должно выглядеть, а выполняют это уже специалисты в области программирования под Win. P.S. Все выше сказанное, мое личное мнение. С уважением, oval

Есть такой, "человеческий". Все вышеназванное параметризовано и даже больше. Мультипортовый на AMBA AXI. Глубокая оптимизация трафика. Для Virtex-II в варианте 2 порта AXI, 32-bit, SDRAM (не DDR), single + burst занимает 756 LUT + 729 DFF. Можно без AXI. Если интересно, пишите.

Софта для синтеза нестандартных генераторов не встречал. Всегда делал так: делал функцию, которая выполняла одну итерацию, далее в цикле вызывал эту функцию необходимое количество раз, получал требуемый результат. Оптимизацией логики вручную не занимался. У меня все было на VHDL. При таком подходе реализация не займет более получаса. Пробуйте. Удачи

На самом деле никакой проблемы здесь нет. Насколько мне известно из теории построения генераторов ПСП, единожды выполненная над битовым вектором функция, дает в результате один псевдослучайный бит. То есть за одно применение функции (за один сдвиг битового вектора) имеем право взять как псевдослучайный только один бит, который "выдвигается" из битового вектора (он же, в случае генератора ПСП, "вдвигается"). Этот бит формируется функцией обратных связей, которые задаются собственно многочленом. Следовательно, чтобы получить N псевдослучайных бит, нужно выполнить функцию над битовым вектором N раз, что мы и видим в преведенном Вами коде, где псевдослучайная функция выполняется над битовым вектором prs[9:0] десять раз за такт. В Вашем случае, где необходимо получить 10 псевдослучайных бит за такт, а определяющая функция имеет степень 9, Вам необходимо также выполнить над битовым вектром prs[8:0] функцию 10 раз, но с той лишь разницей, что сохранить 10-ый псевдослучайный бит в дополнительном разряде битового вектора. Полученные 10 бит и будут необходимым Вам результатом. Вот Вам еще полезный для понимания файлик: crc.pdf Будут вопросы, спрашивайте. Удачи.

Да, можно. Однако, что касается CS, то нужно будет правильно управлять остальными сигналами управления (CAS, RAS). Некоторые контроллеры SDRAM используют функциональность CS при подаче команд SDRAM. По DM ограничений не встречал. Удачи

Как вариант: architecture a_X of e_Y is constant N : positive := 19; signal S : std_logic_vector(0 to N); begin process(Res, Clk) begin if Res = '1' then C <= (others => '0'); S <= ('1', others => '0'); elsif rising_edge(Clk) then C <= B; if S(0) = '1' then C<= A; end if; S <= S(N) & S(0 to N-1); end if; end process; end a_X; Здесь сигнал С регистровый, можно сделать комбинаторный: architecture a_X of e_Y is constant N : positive := 19; signal S : std_logic_vector(0 to N); begin process(Res, Clk) begin if Res = '1' then S <= ('1', others => '0'); elsif rising_edge(Clk) then S <= S(N) & S(0 to N-1); end if; end process; C <= A when S(0) = '1' else B; end a_X; Удачи

Делали неоднократно. По опыту могу сказать, что для начала задача слишком сложная. Читайте, как устроены подобные системы, в сети есть все, что нужно, дальше углубляйтесь по каждому составляющему блоку в отдельности, то есть, как обычно, сверху-вниз. ИМХО, если ранее с этим дела не имели, делать будете долго. Удачи. P.S. Будут вопросы, спрашивайте, чем сможем, поможем. Если делать хорошо и качественно, не меньше года уйдет. <{POST_SNAPBACK}> <{POST_SNAPBACK}> Прошу прощения, не совсем внимательно прочитал. Поскольку тема "железная", то подумал, что требуется написать само железо, но, как теперь понял, нужен софт. Там действительно все намного проще.

Делали неоднократно. По опыту могу сказать, что для начала задача слишком сложная. Читайте, как устроены подобные системы, в сети есть все, что нужно, дальше углубляйтесь по каждому составляющему блоку в отдельности, то есть, как обычно, сверху-вниз. ИМХО, если ранее с этим дела не имели, делать будете долго. Удачи. P.S. Будут вопросы, спрашивайте, чем сможем, поможем. Если делать хорошо и качественно, не меньше года уйдет.