oval
-
Постов
260 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные oval
-
-
Добрый день, des00!
У меня не много другая ситуация и по поводу первых "пристрелок" лучшим вариантов выглядит вариант с сигналом разрешения.Насчет вопроса про CLK, CLK2 меня вот что интересовало,
в своей схеме я делаю сигнал разрешения (CLK) на тригере, и потом сигнал с этого тригера идет на входы разрешения блока работающего на частоте CLK2.
Такой вариант правильный. В этом случае сформированный сигнал разрешения будет синхронен очевидно к CLK, а также и к CLK2 (CLK и CLK2 формируются блоком DCM (PLL и т. п.)). В разбеги фаз будут учтены.
Вот я и по думал а нужен ли этот тригер, если можно снять этот сигнал с DCM(CLK) и так же подать на входы enable блока работающего на частоте CLK2. Плюсы такого решения в том, что для сигнала разрешения используеться линия с большим fan-out.Таким образом ИМХО я бы делать не советовал, поскольку есть очень большая вероятность пападать фронтами переключения сигнала разрешения в критичный промежуток предустановки/удержания, что приведет к ошибкам. Если у меня не изменяет память, то по-моему вывести сигнал разрешения в первом варианте реализации на глобальную цепь (линия с большим fan-out) можно.
Потом я подумал, а что если просто тактировать НЧ часть от CLK, а ВЧ от CLK2, если бы клоки были синхронны то проблем с метастабильностью не было бы и просто потребовалась бы перетактирование сигналов от НЧ к ВЧ части на 1ом тригере, а не на 2-х.Не могли бы вы прояснить данную ситуацию ?
Совершенно верно, никакого 2-х тактного подтактирования в данном случае не требуется. Клоки получаются синхронные (CLK и CLK2), все разбеги учитываются.
У нас практически постоянно возникают подобные задачи. Вышеописанные принципы синхронизации многократно реализовывались и аппаратно проверены для нескольких технологий, в том числе Xilinx (DCM) и Actel (PLL). Пока проблем связанных с этим не встречалось.
-
У меня datasheet в CoreGen`e не работает. Ничего не срабатывает и не выскакивает! Версия CoreGen 5.2.03i Может версия глючная у меня или патчик какойнибудь нужен?
Зараннее спасибо!
Можно посмотреть datasheet "ручками" по месту нахождения CoreGen'а: $Xilinx\coregen\ip\xilinx\primary\com\xilinx\ip\название_компонента\doc
Удачи!
-
2. на вкладке iice иерархия видна на левой панели и при переходе по ней в правой открыватся нужный исходник и там можно манипулировать сигналами.
У меня в список лицензий добавлен "identify_tps", и он запрашивается при работе, м.б. дело в нем?
У меня identify_tps есть, но иерархия в Identify Instrumentor'e не доступна для инстанцированных в модуле верхнего уровня блоков.
У меня абсолютно также. Проект у меня на VHDL. Может ситуация для Verilog несколько лучше?
Точно! Пропробовал примерчик на Verilog'e - действительно все работает и иерархия доступна для просмотра и использования... Выходит либо мы что-то делаем не так на VHDL, либо нужно ждать исправлений.
PS: Отправил Synplicity описание проблемы. Может быть они это как-нибудь прокомментируют...
Понятно, давайте подождем. Теперь больше всего похоже на проблему интеграции Synplify и Identify.
-
2. на вкладке iice иерархия видна на левой панели и при переходе по ней в правой открыватся нужный исходник и там можно манипулировать сигналами.
У меня в список лицензий добавлен "identify_tps", и он запрашивается при работе, м.б. дело в нем?
У меня identify_tps есть, но иерархия в Identify Instrumentor'e не доступна для инстанцированных в модуле верхнего уровня блоков.
У меня абсолютно также. Проект у меня на VHDL. Может ситуация для Verilog несколько лучше?
-
Попробовал методом от Vasiliy. Действительно все запускается и без патча, но проблема с Identify осталась, в иерархии проекта виден только верхний уровень, ниже блекбоксы :(
Но вот что интересно: если тот же самый проект Identify Instrumentor'a открыть из отдельно запущенного Instrumentora, то все будет работать нормально и блэкбоксов не будет...
Да, действительно так, но если потом попытаться просинтезировать implementation instrumentor'а в Synplify, то он сваливается, снова не находя иерархии.
-
Попробовал методом от Vasiliy. Действительно все запускается и без патча, но проблема с Identify осталась, в иерархии проекта виден только верхний уровень, ниже блекбоксы :(
Gate, а может быть Вы пробовали проект, в котором только один уровень иерархии? Такой вариант у меня тоже работает нормально.
-
Странно, у меня все работает. Возможно у вас дело дело в неправильном патче. Сейчас сделаю тему и напишу, как запускать продукты synplicity без synecc.exe как рекомендовал Vasiliy.
Да, стоит попробовать методом от Vasiliy :) Может быть дело действительно в этом.
-
Кстати, да. Ведь когда Instrumentor запущен из-под Synplify он не дает модифицировать проект (удалять Implementationы) и при этом говорит, что работает в Integration mode. Т.е. вполне возможно, что в этом режиме он дает возможность работать только с сущьностью верхнего уровня. Только вот напрашивается вопрос - а зачем он тогда вообще нужен, этот режим? :blink:
Да даже черт с ним, с возможностью редактирования и удаления implementation'ов. Самое обидное, что он ведь тем самым не дает подключать анализатор проекта к любой точке иерархии. Вообщем, похоже, что попытка интеграции Identify и Synplify пока не особо удалась.
-
Действительно, есть такая проблема. :(
Сделал почти все то же самое, т.е. создал проект Identify с помощью самого Identify и откомпилировал. После этого блэкбоксы больше не показывались. Все как и должно быть, можно ходить по исходникам. Однако это коренным образом не решает проблемы...
Точно! "Ручками" получается. Но проекты-то большие, библиотек много :( Похоже придется скрипты писать.
Такое ощущение, что самому synplify не хватает какой-то части лицензии, чтобы правильно запускать Identify. Но вот какой... Это пока неизвестно. :(
Да, возможно. Есть еще предположение, что несколько неудалась попытка более тесно интегрировать Synplify и Identify. Я с таким встречался на Mentor'овских продуктах, когда в некоторых релизах даже элементарные вещи не работали. Identify 2.2 также валиться довольно часто.
-
Действительно, есть такая проблема. :(
Сделал почти все то же самое, т.е. создал проект Identify с помощью самого Identify и откомпилировал. После этого блэкбоксы больше не показывались. Все как и должно быть, можно ходить по исходникам. Однако это коренным образом не решает проблемы...
Точно! "Ручками" получается. Но проекты-то большие, библиотек много :( Похоже придется скрипты писать.
-
Попробовал создать проект в 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, ситуация лучше.
-
Насколько это вообще возможно. Сейчас это 500 пс. Кристалл V2-2000. Среда ISE7.1. Хотя я вот уже думаю, что пик 100-150 меня бы устроило.
Думаю, такую точность получить на ПЛИС нереально, возможно нужно использовать внешние специализированные буферы-разветвители. На ПЛИС все будет очень сильно привязано к условиям (температура, напряжение питания и т. п.) У нас неоднократно возникали проблемы с подобными фокусами, даже на относительно низких частотах порядка 50МГц. Но, кто знает, может и повезет. ИМХО, такие вещи нужно делать с помощью специализированных элементов.
Точно - прогнал! :) У меня не так было: нужен был клок 100 МГц, задержанный от данных, сгенерил на ФАПЧе два клока 100 МГц и 200 МГц со сдвигом (200 МГц задержан относительно 100 МГц). 100 МГц - системый клок, а двухсотмегагерцовым тактировал тот I/O триггер, через который клок наружу шел. Задержка четко была, как заказано (где-то порядка 1.7 нс).А чем Вы с такой точностью измеряли эту задержку? Или это просто данные анализатора времен?
-
Доброго времени суток :)
Есть такой вопрос. Разработано собственное 33MHz PCI ядро. Есть ACEX1K100 speed grade 3. При синтезе Synplify 8.2.1 показывает порядка 70-75MHz тактовую частоту всего этого добра при необходимых 33MHz. После раскладки Quartus 5.0 Fmax уменьшается на не критичных 5-10MHz, однако времена Setup/Hold для входных и выходных сигналов стандарту PCI не соответствуют. Попытки задать более жесткие ограничения на tsu/tso/th результатов не дали никаких. Просто большее или меньшее количество путей в отчете не выполняют заданные ограничения. При этом практически все входные триггера, на которые не выполняются ограничения просто разбросаны по всему кристаллу :maniac:. При "ручном" перемещении триггера к интересующему пину все приходит в норму по конкретному пути, однако очень не хочется выполнять всю разводку вручную.
Есть ли способ как-нибудь объяснить Quartus, что задержка на входной сигнал должна быть не больше заданной? Тот же вопрос и о выходных сигналах?
Можно попробовать вручную спланировать размещение внутри кристалла, например, задать области кристалла в которые поместить входные/выходные защелки шины 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 всегда зашифрован.
-
Сделал проект, скомпилил,указал что хочу видеть,нажал на кнопочку со скрипкой :) .
Софтина выдала мне правленные мои исходики и файл syn_dics.vhd.
При попытки синтезнуть,синтезатор ругается на ошибку в файле syn_dics.vhd.Открываю его- а там каракули какие-то.
Вопрос- как это лечится?
з.ы.Identify брал с фтр, кряк там же.
Никак не лечиться, да и лечить не надо. Так и должно быть, просто указанный файл зашифрован. Читайте документацию, там все написано. Удачи!
-
есть переменная в цикле
lines : integer range 0 to 1000;
я так понимаю следующая за 1000 будет 0.
и обнулят мне её не надо так как это пока симуляция.
ModelSim ругается что я вышел на следующем цикле
за рамки.
Нет, следующее за 1000 значение будет 1001. Если нужно 0, то используйте функцию модуля (mod).
Удачи.
-
Наверняка найдутся люди которые знают и/или работали с IP Cores от Actel.
Конкретно с IP Cores от Actel не работали, но работали с другими и создавали, и создаем собственные.
- в каком виде эти "корки" реально приходят к разработчикуВарианты здесь могут быть разные, в виде RTL исходников и/или синтезированного netlist'а. С исходниками, очевидно, в разы дороже.
- целесообразность их покупкиИмеет смысл, хотя бы потому, что значительно сокращается время разработки (если это конечно важно). Совершенно очевидно, что множество западных производителей пользуется именно таким подходом. Единственным препятствием может являться цена.
- перспективы с модернизацией и/или переделкой их для других проектовВозможно, но естественно при наличии RTL исходников. Был такой опыт, но можно сказать, что времени отнимает очень много даже для незначительных изменений. Здесь речь идет о модернизации самого IP ядра. Производители обычно предоставляют не параметризованную RTL модель, а сборку "заточенную" под конкретные параметры, заказанные Вами при покупке. Это значительно усложняет задачу модернизации. Вообщем, все зависит от типа ядра, но модернизация дело очень трудоемкое.
- на сколько быстрее получается реализация проекта, если используешь готовое ядроМожет отличаться в разы, все зависит от составляющих системы. Например, чтобы создать полноценный
контроллер шины PCI (PCI master + PCI slave с поддержкой всего, что только можно) с нуля потребуется не менее полугода, а то и более, работы коллектива профессионалов (здесь я не имею ввиду изделия "на коленках", а имею ввиду качественные изделия с качественным тестированием и продуманные на начальном этапе проекта). На подключение готового ядра обычно достаточно до месяца. Вот и оценивайте.
- удобство в отработке- и т.д.
Если модель качественная (хорошая документация, хороший код, удобный внешний интерфейс), то, как правило, проблем не возникает.
P.S. Обратите внимание на предоставляемую на IP гарантию и поддержку. У крупных компаний получить оперативную поддержку даже в случае обнаружения фатальной ошибки в модели достаточно проблематично, обычно не менее месяца, пока они достучатся до разработчиков. Качественнее всего сервис у небольших компаний, которые "живут" за счет IP, это и понятно. Небольшие компании даже могут взяться за модернизацию IP по Вашему заказу.
Все вышесказанное, мое личное мнение.
Будут вопросы, спрашивайте.
С уважением,
oval
-
используем ProASICPlus APA150
Имея не малый опыт работы с ПЛИС Actel, могу предположить, что запустить схему на частоте 152МГц для семейства ProASICPlus нереально, разумеется если эта схема не простой сдвиговый регистр. Попробуйте в порядке эксперимента создать проект простого счетчика и оценить полученные временные характеристики. Количество разрядов счетчика, который сможет работать на частоте 152МГц, может Вас удивить! Мы неоднократно боролись за частоты работы порядка 50МГц! Вообщем, вопрос г-на vitus_strom относительно семейства мне вполне понятен.
-
Фирме ЗАО "ПКК Миландр" (Москва, Зеленоград) специализирующейся в области разработки заказных цифровых и аналоговых микросхем требуется специалист по тестированию проектов.
В результате не получено ни одного резюме :(
В качестве Офф: что не так ? Нериальные требования или типа "черновая работа" тестирование ?
Интересует просто так, на будующее....
На мой взгляд обязанности и требования сформулированы для целого отдела тестирования, но никак не для одного специалиста. Насколько я понял, Вам требуется целый коллектив. Думаю, что таких "универсальных солдат", подходящих под эти требования не так уж много.
Особенно разносторонние области среди изложенных требований это, на мой взгляд, программирование PC (под Win) и знание Verilog и средств верификации, Verilog XL, Code Coverage. Слишком разные и специфические вещи. Что-то одно - не вопрос. Я сам, например, уже достаточно давно занимаюсь проектированием логики микросхем для FPGA и ASIC, но никогда не касался программирования под Win. Я лишь представляю себе, что требуется сделать и как должно выглядеть, а выполняют это уже специалисты в области программирования под Win.
P.S. Все выше сказанное, мое личное мнение.
С уважением,
oval
-
Помогите найти человеческую кору контроллера SDRAM на VHDL для реализации на ПЛИС Xilinx
"Человеческая" подразумевает возможноть изменения разрядности шины данных и адреса, а также обязательно наличие режима burst для чтения и записи
Есть такой, "человеческий". Все вышеназванное параметризовано и даже больше. Мультипортовый на AMBA AXI. Глубокая оптимизация трафика. Для Virtex-II в варианте 2 порта AXI, 32-bit, SDRAM (не DDR), single + burst занимает 756 LUT + 729 DFF. Можно без AXI. Если интересно, пишите.
-
Умом-то я понимаю, что правая часть набора присвоений и есть результат сокращения 10 итераций 1-разрядного генератора. Но попытки сделать параллельный генератор "вручную" ни к чему не привели - результировавшая последовательность была кривой. Может есть софт для синтеза таких генераторов?
Софта для синтеза нестандартных генераторов не встречал. Всегда делал так: делал функцию, которая выполняла одну итерацию, далее в цикле вызывал эту функцию необходимое количество раз, получал требуемый результат. Оптимизацией логики вручную не занимался. У меня все было на VHDL. При таком подходе реализация не займет более получаса. Пробуйте.
Удачи
-
Задача сделать на ПЛИС генератор ПСП с параллельным выходом, т.е. дающим сразу N бит ПСП за такт, причем степень полинома должна быть 9, а ширина выходной шины, т.е. разрядность регистра - 10. Для вариантов, когда разрядность шины была меньше или равна степени полинома здорово выручал www.easics.be тулз, а вот в данной ситуации я в тупике.
Для примера привожу верилог генератора с разрядностью 10 и полиномом десятой степени:
// 1 + x^7 + x^10 poly 10 bit PRS generator
module prs10d10(clk, rst, clr, prs);
input clk, rst, clr;
output [9:0] prs;
reg [9:0] prs;
always @ (posedge clk or posedge rst)
if(rst)
prs <= 0;
else
if(clr)
prs <= 10'h3ff;
else
begin
prs[0] <= prs[0] ^ prs[3] ^ prs[6] ^ prs[9];
prs[1] <= prs[1] ^ prs[4] ^ prs[7];
prs[2] <= prs[2] ^ prs[5] ^ prs[8];
prs[3] <= prs[3] ^ prs[6] ^ prs[9];
prs[4] <= prs[4] ^ prs[7];
prs[5] <= prs[5] ^ prs[8];
prs[6] <= prs[6] ^ prs[9];
prs[7] <= prs[0] ^ prs[3] ^ prs[6] ^ prs[7] ^ prs[9];
prs[8] <= prs[1] ^ prs[4] ^ prs[7] ^ prs[8];
prs[9] <= prs[2] ^ prs[5] ^ prs[8] ^ prs[9];
end
endmodule
На самом деле никакой проблемы здесь нет. Насколько мне известно из теории построения генераторов ПСП, единожды выполненная над битовым вектором функция, дает в результате один псевдослучайный бит. То есть за одно применение функции (за один сдвиг битового вектора) имеем право взять как псевдослучайный только один бит, который "выдвигается" из битового вектора (он же, в случае генератора ПСП, "вдвигается"). Этот бит формируется функцией обратных связей, которые задаются собственно многочленом. Следовательно, чтобы получить N псевдослучайных бит, нужно выполнить функцию над битовым вектором N раз, что мы и видим в преведенном Вами коде, где псевдослучайная функция выполняется над битовым вектором prs[9:0] десять раз за такт. В Вашем случае, где необходимо получить 10 псевдослучайных бит за такт, а определяющая функция имеет степень 9, Вам необходимо также выполнить над битовым вектром prs[8:0] функцию 10 раз, но с той лишь разницей, что сохранить 10-ый псевдослучайный бит в дополнительном разряде битового вектора. Полученные 10 бит и будут необходимым Вам результатом.
Вот Вам еще полезный для понимания файлик: crc.pdf
Будут вопросы, спрашивайте. Удачи.
-
Если не предполагаеться использовать паралельно подключенные несколько
микросхем и переключать их CS и нет надобности управлять маской при записи DM можно ли просто повесить данные сигналы на землю. Необходимость возникла в связи с катастрофической недостачей контактов на фпга.
Да, можно. Однако, что касается CS, то нужно будет правильно управлять остальными сигналами управления (CAS, RAS). Некоторые контроллеры SDRAM используют функциональность CS при подаче команд SDRAM. По DM ограничений не встречал.
Удачи
Identify 2.3: проблемы
в Среды разработки - обсуждаем САПРы
Опубликовано · Пожаловаться
Господа интересующиеся! :1111493779: Появился Identify 2.3.1! Еще не успел проверить, но возможно, что вышеописанная проблема в этой версии исправлена. Будем пробовать.