oval

To ASN: Я в Verilog не особо силен. Если можно, то объясните по подробнее Ваш вариант "двухпроцессный метода" на Verilog. Конструкция always будет использоваться одна? Среди этих двух процессов один клоковый, второй - комбинаторный. REGx - это регистры? Вы случайно не простейший конвейер имеете ввиду? To Very_hard: Рынок - сложная штука. Цена определяется не только себестоимостью. Можно продавать 100 экземпляров за 10 уе или 1000 за 1 уе. результат по прибыли будет гдето одинаков... Что касается цен на FPGA Adv... конечно это очень хороший продукт, и за него неплохо было бы получить хорошие деньги, да с этим я согласен. Кому он НЕОБХОДИМ(лицензионный), тот купит и за 30 тыс. а остальным и нелицензионного хватит :) ЧТД ;)

как раз наоборот, например собираемся сделать каконить блок, например тот же рле - кодер, работающий в data packed processing системе. Разбиваем этот блок на 3 блока-функции: 1. менеджер памяти данных источника. 2. Собственно РЛЕ кодер 3. основной КА, который рулит первыми двумя и занимаеться data_flow от-но системы. Я бы реализовал блок-"функцию" рле кодера в одном файле в тексте, воспользовался бы двухпроцесным подходом разработчиков LEON2/LEON3 для описания блока. Т.к. считаю что дробить сам РЛЕ кодер на составляющие (а это будет несколько регистров, компараторов, суматоров + логика) будет не есть хорошо, т.к. работать с одним файлом легче. Вообщем, сказать трудно, видимо надо рассматривать конкретную задачу. Некоторые соображения такие: 1. Не факт, что вообще нужет (или стоит выделять в отдельный блок "основной КА"); 2. Можно описать алгоритм работы РЛЕ кодера двумя параллельными FlowChart (LEON, кстати не плохо написан! ;) ), один FlowChart синхронный (clocked, или sequential в терминах HDL Designer), другой - комбинационный (combinatorial). Если я правильно понял "двух процессный" подход. Если линейный алгоритм РЛЕ кодера слишком перегружен ветвлениями и/или действиями, так, что графическое представление в виде алгоритма окажется слишком большим, то есть смысл оформить отдельные участки алгоритма в виде процедур и/или функций. Процедуры и/или функции можно вынести в package, либо описать в секции Process declarations диаграммы FlowChart. 3. Очень вероятно, что дробить РЛЕ кодер далее, ниже по иерархии смысла нет. :cheers:

Повторюсь, цены вполне адекватны уровню сложности САПР! Кстати, если я не ошибаюсь у них для России (СНГ) еще и большие скидки по сравнению с Англией к примеру! ;) Sorry for offtopic :) Не в обиду будет сказано, но это не "нормальная средняя фирма", пару-тройку "палаток" в деревне приносят бОльшую прибыль. Так что, это проблема рынка hightech в нашей стране. Покупают, но не много. Мы вот думаем. Очевидно, что в ближайшее время бизнес Mentor в России есть и будет убыточным. ;) А более доступная цена это какая? Цена не может быть ниже себестоимости.

Т.е. получаеться что при разработке топ-левела, сначала идет разработка каркаса и одновременно его самодокументация, а уже потом "пристегиваються" функции. С этим я согласен целиком и полностью. Ну в общем как-то так. Если проектировать "сверху-вниз". :) Без привязки к логике и регистрам, - один FlowChart - один HDL процесс. Параллелизм реализуется в HDL несколькими процессами, соответственно, несколькими параллельными FlowChart (concurrent flowcharts) диаграммами (несколько параллельных диаграмм FlowChart могут входить в ОДНО представление FlowChart (FlowChart view)). Здесь нет никакой магии :) , все как в HDL: параллельные процессы, - соответственно, несколько ASM. Каждый этап конвейера, отдельный процесс, отдельная диаграмма (ASM, State Diagram, FlowChart). Можно конечно в определенных случаях все "скомкать" в один процесс, но это не есть хорошо. Здесь все зависит от того, насколько грамотно организовать иерархию. Грамотность разбиения приходит с опытом. Похоже здесь идет речь о классическом понятии функции типа "корень", cos, sin. Да, естественно, такого рода функции пишуться на HDL и описываются в основном в пакетах (package). Дальше используются в FlowChart и т. п.

Нет, я не из тех "товарищей". :) Я просто достаточно давно работаю в направлении HDL проектирования. Уже давно сделал выбор в сторону Mentor'а, возможно откажусь в пользу чего-то другого, но пока альтернатив не вижу. Не совсем согласен. Это имеет смысл даже в случае чисто HDL проектирования. У нас, например, разработчики схематики и PCB не используют Mentor. Да, действительно одиночному пользователю официально вряд-ли доступно. Согласитесь, если здраво размыслить, то если было-бы доступно, тоже бред, не в игрушки ведь играем. Mentor, как и все фирмы, работающие в этой области должны окупать проекты и получать прибыль или как??? Проблема возможности приобретения, это проблема не Mentor'а, а фирм-разработчиков и бюджета данной индустрии в стране! Во всем правы, кроме последней фразы. Не за что их ненавидеть. Цены соответствуют сложности выполненной работы. У них ведь тоже все хотят получать зарплату и достойную! Повторюсь, проекты должны как минимум окупаться, но чтобы им жить и развиваться нужно еще, чтобы они и прибыль приносили. ;)

Хмм в таком случае мне вот что непонятно, языки ХДЛ появились как следствие неудобства разработки больших проектов на графике (тоже из готовых блоков). Верно, то есть для описания на более высоком уровне. Здесь Вы не совсем поняли общую концепцию. Все блоки внутри иерархии проекта, которые можно разделить на отдельные функционально законченные блоки (управление, передача данных и т. п.), мы оформляем как блок диаграммы (block diagram), соединяя соответствующие функционально законченные блоки между собой (кроме представления block diagram можно также использовать представление IBD (interface based diagram - таблица соединений)). Далее каждый из функционально законченных блоков описывается как одно из представлений: алгоритм (flowchart), автомат состояний (state diagram, ASM - algorithmic state machine), таблица истинности (truth table). На высоком уровне , а не на уровне триггеров или LUT! Посмотрите примеры в составе HDL Designer, может быть станет более понятно. В общем примерно так: с ростом объема логики и ее сложности, все больше этапов проектирования отдается САПР, ибо в противном случае время проектирования стремиться к бесконечности. Забавный пример: всем известный Microsoft Excel - 500 человеко/лет! Делайте выводы. ошибся компилятор ест-но :) т.е. написав код ХДЛ блока, можно сразу проверить его "собираемость" компилятором. Опять же каким компилятором? Фактически каждый САПР имеет свой компилятор. ModelSim - свой, Synplify - свой, Xilinx ISE - свой, и т. д. HDL Designer имеет некоторый собственный встроенный предпроцессор, проверяющий синтаксис и не только. Также, как я упоминал ранее, есть DesignChecker. Специфическая компиляция (ModelSim, Synplify и т. д.) без проблем вызывается из самого HDL Designer'а. В том то и дело, что код сгенерированный, а я имел в виду код разработанный. Хотя все это нужно рассматривать в сфере первого моего вопроса, а именно : Те участки кода, которые относятся к разработанному коду (выражения, идентификаторы и т. п.) проверяются на правильность непосредственно в процессе их ввода внутри всех графических представлений HDL Designer'а. Попытался :) Не знаю, получилось ли :cheers:

ИМХО Странно то что open описывает назначение порта типа OUT, а Вы цепляете его на вход. Во всей инфе что я когда либо видел, на неиспользуемые порты цепляеться определенное значение сигнала, например 0. Как open может быть объявлен и вход в том числе. Просто в самом описании компонента (entity), вход которого объявляется на уровне выше, как open, обязательно должно присутствовать начальное значение (initial value) этого порта, собственно это значение и будет использоваться как состояние порта при моделировании.

Учтите, что значение задержки будет варьироваться в зависимости от температуры, напряжения питания и т. п., и в достаточно широких пределах. Можно поиметь большие проблемы. Xilinx не предназначен для решения подобных задач. ИМХО лучше найти другое решение. Следует также иметь ввиду, то для какого случая (худшего, лучшего и т. п.) анализатор времен Xilinx показывает значение задержки. Удачи!

Не совсем согласен. Основная масса проектов у нас сделана с использованием HDL Designer с "нуля". Нарисовать практически всегда проще, быстрее, нагляднее, чем писать текстом (разумеется, когда уже хорошо владеешь продуктом). При этом всегда меньшая вероятность мелких оплошностей (типа несоответствия имен в заголовке и в конце описания и т. п.), так как среда следит за этим автоматически. Кроме того, месяца через три после создания по графической диаграмме гораздо проще "без стакана" разобраться, "а что это собственно я тут сделал". Проверено опытом. "Косяков" конечно тоже хватает, но развивается HDL Designer ИМХО в нужную сторону, и вроде как достойных конкурентов не имеет, хотя может я чего не знаю. Вообщем RTL уровень описания в графике ИМХО на высоте. Кстати, для разработки сложных иерархических систем из уже готовых (написанных, нарисованных и т.д.) блоков существует отдельный класс средств, к примеру Xilinx EDK, Mentor Platform Express и т. п. Да, согласен, что разработка непостредственно на HDL не самая удобная вещь, в основном за счет "тупого" встроенного редактора. Но, разработка непосредственно на HDL и не нужна (по крайней мере на RTL уровне), это уже становиться в некотором роде архаизмом. Надеюсь, что причины этого очевидны. Непосредственно из того, что мы делаем текстом, это пакеты (VHDL) и некоторые участки кода тестбенчей (сейчас уже стараемся на System-C), все остальное в графике. Встроенный редактор можно заменить внешним (как я понял из другой ветки, Вы так и сделали, судя по всему мы тоже так сделаем, до лучших времен, поскольку System-C код в основном приходится писать "ручками"). На счет я не совсем понял о чем речь? Синтезатор чего? Здесь я тоже не понял почему? Код, сгенерированный HDL Designer'ом соответствует стандартам. Разве нет? Кроме того, в составе HDL Designer есть средство DesignChecker, он позволяет настроить практически любые design rules, policies и т. п., и будет автоматически проверять.

Посмотрите в сторону Mentor HDL Designer. Там можно делать проекты графически.

В верилоге нет таких проблем: module Counter( input Clk, output reg [7:0]Out ); always @(posedge Clk) Out <= Out + 1; endmodule Да, в Verilog такой проблемы нет. Уточнил, что в ближайшей редакции стандарта VHDL будет как в Verilog, порты можно будет читать, а вот по поводу того, будет ли исключен тип buffer ничего конкретного не указано. В любом случае, лучше buffer не использовать.

Я бы сказал, что это единственно правильный вариант. Нет, есть любители задавать пины прямо в VHDL-коде с помощью атрибутов, но это от лукавого. Извините за назойливость, но в даташитах сказано примерно так: "глобальные выводы могут быть запрограммированы и как обычные". И у меня возникают сомнения, что фраза типа NET"CLOCK" LOC = "P181" в UCF гарантирует, что вывод 181 будет запрограммирован как глобальный клок. Ведь действительно, откуда ISE знает, что я сигнал CLOCK считаю тактовым? А вдруг это обычный сигнал и вывод должен быть запрограммирован как обычный? Системы проектирования ведь мыслей не читают. Обычно САПР типа ISE определяют автоматически "потенциальных кандитатов" на использование глобальных цепей основываясь на коэффициенте разветвления цепи, заданных пользователем ограничениях, на том подключена ли цепь к тактовому входу триггеров и т. п. В Вашем случае в логах ISE можно все это выяснить. То есть, под какие сигналы задействованы глобальные цепи кристалла.

Не, тем не менее тип порта buffer лучше не использовать!!! Раньше некоторые средства синтеза не поддерживали этот тип. Вообщем использование этого типа считается "дурным тоном", и об этом встречаются фразы практически в каждой "нормальной" книге по VHDL. Кроме того, если я не ошибаюсь, из очередного стандарта VHDL этот тип будет вообще исключен.

В объявлении компонента eee (entity eee) для порта XLXN_2 нужно указать начальное значение (initial value).

Сам не проверял, но возможно предупреждение ISE связано с тем, что порт типа buffer при синтезе преобразуется в примитив IOBUF (а не OBUF), и соответственно в полученной после синтеза схеме, где считывается (используется) состояние этого порта, используется сигнал подключенный к входному буферу примитива IOBUF. То есть, используемое внутри значение будет отражать реальное состояние линии порта, а не значение, которое выдается на линию. З.Ы. Если удасться выяснить во что реально преобразуется порт после синтеза, напишите здесь.

Здесь Вы зделали все правильно. CLOCK лучше и правильнее заводить на глобальный вход. Скорее всего у Вас глобальная ошибка в самом проекте. Проект должен вести себя логически одинаково независимо от того, на какой вход подается CLOCK (10МГц). Возможно стоит убедиться в том, что на входах XCR присутствует то, что должно быть (в частности правильная частота CLOCK). Еще, как вариант, но с меньшей вероятностью, в версиях САПР Xilinx более ранних чем 7.1SP1, если я не ошибаюсь, была проблема при работе с CPLD, но опять же в данном случае вряд ли. Возможно, что имеет место очень серьезное нарушение по временам. Очень похоже на присутствие элемента асинхронности (концептуальная ошибка) в проекте.

Не раз встречался с такими группами разработчиков. Могу сказать, что первое впечатление далеко не всегда верно. "Не от мира сего" товарищи обычно такие же люди, как и все мы. Настоящих "гуру" там, как правило максимум парочка :) Много исходников видел от "таких" товарищей. Далеко не все там идеально. Если посмотреть исходники IP разных брендов, то порой в ужас приходишь! Не особо они парятся за качество кода, многое делается "в лоб". Нет видимо у этих "товарищей" времени на серьезную проработку, да может и не требуется, time to market все-таки. А по поводу количества ксилов, - ИМХО это не показатель. Завит от разрядности данных алгоритма, количества необходимой памяти и т. п. Делал как-то шифр AES аппаратно, вроде все достаточно просто, но "не лез" он ни в один из существующих на том момент кристаллов, - слишком уж много симметричной логики!

Можно посмотреть например здесь: Questa_Product_Comparison_Chart.pdf ;)

Смотрел софт от FS2, правда до практики пременения не дошло, как-то показалось очень тяжело интегрировать с достаточно большим проектом. Однако имеется некоторый опыт работы с подобным, но на мой взгляд гораздо более продвинутым пакетом Identify. Так вот, по сути вопроса, все зависит от того какие параметры конфигурации задать: количество наблюдаемых сигналов, количество триггеров, глубину сэмплинга и т. д. Если наблюдаете 1 сигнал, задействовали 1 триггер, то размер клиентской части должен быть очень маленьким, тем более относительно APA300. Если нет, значит смотрите netlist, там можно посмотреть, что съедает ресурсы. Кроме того, в документации к этому пакету (FS2 Logic Navigator) достаточно подробно описано, что он создает и как. Удачи!

Можно сделать, и достаточно легко. Внутри процесса, описывающего требуемый умножитель, сначала вычисляете (можно не вычислять, а передать, как константу или параметр, к примеру) период входного (опорного) тактового сигнала. Далее делите этот период на требуемый умножитель (10 или 20), получаете период умноженного тактового сигнала. Формируете тактовый сигнал с вычисленным периодом, но с одной важной поправкой: чтобы фронт (или спад, в зависимости от того, что должно быть синхронно) полученного умноженного тактового сигнала формировался либо по истечение вычисленного полупериода, либо по фронту исходного опорного тактового сигнала. Главное, чтобы накопление ошибки в результате округления при вычислении периода не превысило полупериод умноженного тактового сигнала. Вообщем, вариантов масса, подумайте сами, не все так сложно. Удачи!

Не получилось у меня пока поработать!!! :angry2: Все довел до конца (под Actel ProASICPlus) как положено, прошил. Все Ок! Запускаю RTL Debugger: пишет, что не может найти "instrumented design", попробовал несколько раз, результат один. Правда пока попробовал только на одной машине. Вообщем, все начинается похоже с того, что он неправильно считывает через JTAG ID микросхемы, на что честно выдает соответствующий Warning. Никак разучился теперь с кабелем работать?! :( Понятно, как появиться время, попробую. А пока ждем ;)

Первые впечатления следующие: одно "лечим", другое "колечим" :( Для проекта под Actel ProASICPlus при запуске Identify Instrumentor'a из Synplify вообще вываливается с Internal error. Как выяснилось, теперь ему не нравиться ссылка на библиотеку технологических примитивов APA во всех модулях, сгенерированных ActGen'ом (аналог CoreGen у Xilinx). Отдельно Synplify все "съедает" на ура! После исправления этого "косяка" вручную, проект загружается в Identify нормально и даже видно всю иерархию! Ура! Но вот не задача, после завершения настроек проекта в Identify, возврашаемся в Synplify и пытаемся просинтезировать созданный Identify implementation. Вообщем, все хорошо, кроме самого главного, все, что добавил в проект Identify оказывается "blackbox'ами"!!! Причиной тому, как и было раньше, является то, что созданный Identify файл syn_dics.vhd оказывается в самом конце списка исходников, посему и дело до его компиляции вообще не доходит! Так что, пока делать приходится опять все "ручками"!!! Ждем дальше. :angry2: P.S. Проект не тривиальный. Используется много библиотек. Библиотеки work нет. 2 makc: Если у Вас налажена связь с Synplicity и есть время, то можно им отписать, может задумаются ;)

Господа интересующиеся! :1111493779: Появился Identify 2.3.1! Еще не успел проверить, но возможно, что вышеописанная проблема в этой версии исправлена. Будем пробовать.

Добрый день, des00! Такой вариант правильный. В этом случае сформированный сигнал разрешения будет синхронен очевидно к CLK, а также и к CLK2 (CLK и CLK2 формируются блоком DCM (PLL и т. п.)). В разбеги фаз будут учтены. Таким образом ИМХО я бы делать не советовал, поскольку есть очень большая вероятность пападать фронтами переключения сигнала разрешения в критичный промежуток предустановки/удержания, что приведет к ошибкам. Если у меня не изменяет память, то по-моему вывести сигнал разрешения в первом варианте реализации на глобальную цепь (линия с большим fan-out) можно. Совершенно верно, никакого 2-х тактного подтактирования в данном случае не требуется. Клоки получаются синхронные (CLK и CLK2), все разбеги учитываются. У нас практически постоянно возникают подобные задачи. Вышеописанные принципы синхронизации многократно реализовывались и аппаратно проверены для нескольких технологий, в том числе Xilinx (DCM) и Actel (PLL). Пока проблем связанных с этим не встречалось.

Можно посмотреть datasheet "ручками" по месту нахождения CoreGen'а: $Xilinx\coregen\ip\xilinx\primary\com\xilinx\ip\название_компонента\doc Удачи!