oleg_rudakov

Priamogo dokumenta, kotoryj Vam skazhet ob etom - net. Tochnee, on est. Eto vnutrennij dokument (VHDL RTL Design Guidelines), prinjatyi kak vnutrennij standart predprijatija, na kotorom ja truzhus (_I_n_f_i_n_e_o_n_). U synthesis/layout tools voznikajut problemy raspoznavanija takih schin kak clocki. Po umolchaniju prinjato ne objedinijat clocki v schinu. Inache synthes, STA, layout budut traktovat ih kak signaly dannyh. Clock tree pri etom budet mjiagko govorjia krivaja. Esli voobsche budet postroena. Esli v marshrute proektirovanija Vashego predprijatija ispolsujutsa sredstva linting (A_t_r_e_n_t_a SpyGlass, naprimer), to etot instrument ukazhet Vam na nedopustimost takogo stilja v opisanii RTL v vide fatal error. Postarajus poluchit otvet iz _S_y_n_o_p_s_i_s_ na Vash vopros. S uvazheniem...

Odno dobavlenije... Zepi clock'a v shinu ne ob'edinjajutsa. Eto dla dannyh i upravlenija podojdet. Kazdyj clock dolzen idti svoej dorogoj. Inache budut problemy s "ponimaniem" design'a u sintezatora i PrimeTime, naprimer.

Primer: Vash proekt - microkontroller tipa ChipCard. U nego est vstroennyj oscillator na osnove VCO ili VRO, no takzhe est i vozmozhnost rabotat ot vneshnego clocka. Microcontrollery bankovskih kart i e-passport ustroeny imenno tak. Schema perekluchenija istochnika clocka zakanchivaetsa OR gate. Schema - v prizepe. Podcherkivaju krasnym - etot design ne FPGA! Eto ASIC! Poetomu OR gate i ne tolko eto dopuskajutsa.

Rezultatom sinteza vashego opisaniya v DC budet, skoree vsego OR gate v zepi clock'a. Dlia ASIC-syntezatora eto prohodit, ne ochen krasivo, no, idet. Synplify - FPGA-orientirovannyi syntezator. Logicheskie ventili v zepiah clocka, kak i clock gating cells dlja FPGA ne primenjautsa i syntezator obychno soobschaet ob oshibke. V FPGA eto mozhno realizovat cherez logiku v clock enable. Tak, po krainei mere, delaetsa ASIC emulation na FPGA. Eta konstrukzia na Verilog - ochen udobna dlja Behavioral Simulation, no ne dlja Synthesis. S uvazheniem.... PS. Izvinite za translit. Ruskoj raskladki net na machine.

Подобная проблема наблюдалась всякий раз и в разных проектах, когда использовались опорные конденсаторы небольшой емкости (обвязка ПЛИС по питанию). Необходимо использовать бОльшие емкости с целью обеспечения стабилизации напряжения, особенно это критично при конфигурировании кристалла. Он потребляет большой ток, и если питание не дотягивает - конфигурация завершается с ошибкой. Пробуйте добавить емкости в каждую из цепей питания. Кстати, из прошлого опыта, Xilinx требует питания на каждый блок, даже если ни одна ножка не используется. Удачи...

Dobryi den', Nahozhus' neposredstvenno za bugrom (Austria). Zadal vopros specam po PCB (zakazy delaiut i v Germanii tozhe). Vot otvet: I don't know about a standard of the symbols. In CAD tools like Protel or Eagle you can find a lot of predefined symbols. For my PCBs I never followed a special standard. If you have a part list it is well defined, because every part has its own number. This number should also be viewable on the PCB board (for example IC1, IC2.., LED1, LED2, LED3…..). If this is well defined you won't have any problems for the production. Drugimi slovami, ispol'zuite standartnyi zabugornyi CAD i budet schastie. :)

Третью редакцию могу выслать в почту. Не помню место, где она лежит на FTP. Да и лежит ли вообще... На ФТП не нощел. Если можно отправте мне по адресу manuk_shСОБАЧКА.yahoo.com Спасибо! Залил на FTP: /upload/DOCs/Books/RMM

Третью редакцию могу выслать в почту. Не помню место, где она лежит на FTP. Да и лежит ли вообще... а можете выслать на s*h*e*k*h*a*l*e*v*d*v собака elecard.net.ru Выслал

Третью редакцию могу выслать в почту. Не помню место, где она лежит на FTP. Да и лежит ли вообще...

ALDEC выпустил patch для Active-HDL 7.1 для добавления в design flow manager ссылок на Xilinx ISE 8.1 и Synplify 8.4. Залил в /upload/FPGA/Aldec Active-HDL 7.1/patch_flow_7.1.rtm.zip Просто распакуйте содержимое ZIPа в каталог с Active-HDL.

Я давно уже "по диагонали" читал документацию на smartmodels. Там не все просто. Нужно внимательно изучить вопрос лицензий, начальной инициализации моделирования и т.п.

Smartmodels (по крайней мере интересующая Вас GT11_swift) поставляются в VHDL и Verilog виде с XILINX ISE Foundation Express. <Xilinx_HOME>\smartmodel\nt\wrappers\mtivhdl\smartmodel_wrappers.vhd По поводу подключений и моделирования нужно читать manual, <Xilinx_HOME>\smartmodel\nt\image\manuals\simcfg.pdf в частности.

В стандартном VHDL без специальных ухищрений можно работать только с текстовыми файлами. Возвращается/записывается текстовая строка. На совести пользователя преобразовать ее содержимое в тот тип данных, который требуется. Я это делаю так: 1. Использую package с функциями для преобразования строк текста в любой из VHDL-типов и работы с файлами (CASTutil.zip в прицепе). 2. В Вашем testbench делаете нечто похожее на следующее library std; use std.textio.ALL; use CASTutil.all; . . . . MAIN_PROC: process FILE MY_FILE : text open read_mode is <путь к файлу\имя>; VARIABLE MY_FILE_LINE : line; VARIABLE MY_FILE_DWORD : std_logic_vector(31 downto 0); begin . . . if <ваше некое условие> and not endfile(MY_FILE) then readline(MY_FILE, MY_FILE_LINE); read(MY_FILE_LINE, MY_FILE_DWORD); end if; . . . end process; В указанном package определены процедуры записи и чтения данных типов, не совпадающих со стандартным package'м STD.TEXTIO. Удачи. CASTutil.zip

Хорошо бы взглянуть на исходный проект (HDL / Schematic). Маловато исходных данных для анализа...

А в чем отличие "заплатки к retail-версии в" от официальной заплатки? <{POST_SNAPBACK}> Ни в чем. Версий две - web и retail (официальная). Залил для официальной.

Залил заплатку к retail-версии в /upload/FPGA/ALTERA.Quatrus50.Patch

Причины как я уже указал, в том, что хочу научиться писать на хдл, без применения black box, там где это возможно, например с помощью констрейна RAM_STYLE можно уложить память описанную на хдл, туда куда нужно. А насчет distributed ram если нужен фифо на 16 слов, зачем пользовать 2 килобайтный блок ? ?) <{POST_SNAPBACK}> Действительно, для указанного объема памяти использовать 2 Кб ресурсов не следует. До 256 байт - вполне подойдет регистровая память. Об этом я писал выше.

Есть негласный стандарт при проектировании ASIC и FPGA: все, что касается памяти, делать на имеющихся на кристалле ресурсах (hardcore macroses). IBM ASIC Design Group проводила исследование по поводу эффективности применения регистровой памяти (а здесь именно этот тип и получится) при построении FIFO/LIFO. Так вот, до 256 байт - можно. Существенной деградации производительности и ресурсозатрат не проиходит. Все, что свыше этого - только с помощью ядер (аппаратаных примитивов типа BlockRAM у XILINX). Как-то очень давно, роясь в XILINX DataSheets, прочитал прямое указание использовать исключительно BlockRAM для генерации FIFO вместо HDL-inferred. Нельзя ли уточнить, каковы причины использования Inferred RAM вместо применения готовых и оптимизированных ресурсов?

Господа! Три !!! раза безуспешно пытаюсь слить с сайта Xilinx SP1 к ISE 7.1. Это три раза по 311 (почти) мегабайт. По не совсем понятным причинам ни докачка, ни прямой залив из IE 6 и Opera к успеху не привели. Если есть у кого-нибудь возможность - залейте SP1 на FTP, пожалуйста!

Да, модельное время отсутствует в EDS. Его учет не ведется автоматически, и это дело пользователя.

Думаю, что в случае EDS перерасчет схемы делается по любому событию, приходящему от любого источника. Другими словами, timescale здесь не применяется вообще, ибо нет нужды. Если значение любого сигнала меняется - перерассчитывается все устройство и так - для каждого события. Могу ошибаться, но по логике вещей должно быть так...

В CBSе чаще всего имеется так называемый системный (опорный) клок, являющийся глобальным событием. Это не пользовательский, а чисто внутренний по отношению к симулятору, но внешний и отдельно бегущий по отношению к моделируемому устройству. По большому счету - CBS - это частный случай EBS. Именно за счет этого глобального клока симулируются проекты, содержащие различные синхродомены. Это из теории разработки подобного ПО. Можно нарыть побольше информации по теме. Задержки - это несколько иное. Все остается на своих местах, но переключения сигналов осуществляются с учетом задержек, хотя перерасчет схемы остается таким же, каким и был. Точность моделирования (частота того самого системного клока) задается пользователем и чаще всего составляет 1 ps.

IMHO, он одинаково поддерживает оба вида моделирования: Cycle-based simulator : Cycle simulation is a technique (i.e. an algorithm) for digital circuit simulation. It does not simulate detailed circuit timing, but instead computes the steady state response of a circuit at each clock cycle. The user cannot see the glitch behavior of signals between clock cycles. Instead the user observes circuit signals once per clock cycle. Cycle based simulators work with only synchronous designs. Event based : Simulation based on events in logic, which means, when ever there is change in a input event, the output is evaluated. This makes the simulation very slow compared to Cycle based simulators. Verilog-XL is an event-driven simulator. Могу ошибаться, но... По ссылке есть некоторая информация по вопросу: http://www-cad.eecs.berkeley.edu/~nardi/EE...ec13_bw_2xp.pdf

Проблема эта имеет два среза: психологический и технологический... 1. Психологический заключается в том, что если изначально человек длительное время занимался проектированием цифровых устройств и ПЛИС в схематике, то переход к "программисткому" подходу затруднен, но не невозможен... Это более относится к "старожилам". У нас в компании такие имеются, и им было до одного времени проще рисовать ПЛИС, но... 2. Не далее как месяц назад, один из них подошел ко мне и попросил потренировать его команду "мастодонтов" в вопросе HDL-проектирования. Причина - увеличение размера и сложности проектов... Статистика простая: до 10000 вентилей - можно и порисовать, свыше этого количества - трудно, и, чем больше, тем невозможнее... HDL-проектирование как раз и возникло, когда объем кристаллов (ASIC) стал превышать 10000 вентилей. Сейчас уже трудно кому-то объяснить, почему при проектировании больших ПЛИС (об ASIC и разговора нет) лучше делать на VHDL. Это уже не субъективное мнение, а реальность...

Не за что! Надеюсь, что помог чем-то. 1. Архитектура и поведенческое моделирование. Как правило, разработка архитектуры включает в себя моделирование будущего ASIC алгоритмически с целью выявления потенциальных проблем в идее самого проекта. Моделирование выполняется чаще всего на C++ и с библиотеками, упрощающими стыковку с "аппаратным миром" (SystemC). Алгоритмическая (поведенческая) модель может стать прототипом для написания верификационной поведенческой модели ASIC, на которой отлаживается набор тестовых программ (testcases), на которых в последствии будет регрессионно отлаживаться RTL-модель. В зависимости от назначения проекта (области применения ASIC), его алгоритмическое моделирование может существенно различаться. Поведенческое моделирование - это средство проверки правильности алгоритмов, реализуемых в последствии аппаратно. На этом этапе становятся понятны ограничения будущего проекта. Эта тема довольно обширна по наполнению. В проектировании FPGA она может возникнуть только при разработке системы на кристалле в старших и наисовременнейших семействах устройств. То есть там, где на одной подложке сосуществуют процессорные ядра, приемо-передатчики, пользовательская логика и т.п. Для связки и проверки всего этого хозяйства перед проектированием может быть полезно написать поведенческую модель. 2. RTL-кодирование / Синтез / Статический временнОй анализ. RTL-кодирование для ASIC и для FPGA в приницпе не отличаются друг от друга. Одно часто встречающееся отличие - использование Verilog для ASIC-проектов и VHDL/Verilog для FPGA. Дело в том, что Verilog - язык по своему синтаксису и функциональности ближе к синтезу ASIC-netlist'а. Он не имеет типизации, присущей VHDL. По сути, он как раз ближе к истинно RTL-описанию, а VHDL позволяет еще и поведенческий стиль. Дело в том, что синтез ASIC - это процедура получения вентильного описания, оптимального с точки зрения выбранной технологической библиотеки, содержащей примитивы логических функций. Чем ближе исходная RTL-модель будет к результирующей синтезированной структуре - тем проще отладка. Можно попрактиковаться в FPGA Compiler (Design Compiler). Статический временной анализ (STA) ASIC и FPGA отличаются в корне. ASIC - это несущетсвующая материя. Она создается из ничего. Все, что известно, это задержки между выводами примитивов и задержки распространения в линиях, которые зависят от размещения и трассировки ASIC-проекта. Именно поэтому статический временной анализ - это фактически основная фаза оптимизации проекта, при условии, что он функционально корректен. Если Вы хотите добиться паспортной производительности - придется итеративно оптимизировать RTL-модель, layout, переопределять ограничения и т.п. В общем, работы предостаточно. Поэтому STA для ASIC вынесен в отдельный пакет (PrimeTime). С FPGA ситуация проще, поскольку в Вашем распоряжении конечный и не многочисленный набор задержек. Ваша задача - определить ограничения по путям распространения сигналов и минимизировать критические пути с целью их сокращения. Это можно сделать либо перепроектированием RTL-кода, либо циклическим размещением и трассировкой с указанием желаемых задержек. Если Вы не переограничили проект - он разведется с 95% вероятностью. Я полагаю, проект не избыточен (RTL-код выверен и нет "лишних" затребованных ресурсов). Есть некоторая литература по Timing Analysis для ASIC. У меня есть в PDF книга Sachin Sapatnekar. Timing. Kluwer Academic Publishers, 2004. В ней на 307 страницах описывается эта тема для различных систем и ASIC-структур в частности. Теоретический труд. Полезно для разработчиков САПР. Есть текст диссертации A Hierarchical Timing Simulation Model for Digital Integrated Circuits and Systems. Тоже "наворочено".