Beby

Есть одно заподло, для Virtex-5 в ISE 9.2 (Вроде до SP2, но точно не помню) неправильно оценивалось временные требования к PCI-E Core. А в 10.1SP3 - это анализируется уже правильно. Поэтому не во всех случаях новая среда хуже. Как я заметил, основная причина проблем работы 10.1SP3 по сравнению с 9.2SP4 - это более коряво работающий XST, возможно, если использовать что-то другое проблем будет меньше.

Несмотря на то, что толком использовать двух ядерность процессора не удаётся, мною было замечено на ряде машин с WinXP 32 с E8x00 и AMD Athlon 1/Athlon 2/Phemon 2 иногда бывает небольшой выигрыш во времени компиляции проекта, если в ISE 10.1 за'lock'чить MAP/PAR на ядро №1 (ядро №0 остаётся для прочих нужд ОС).

Ну типа того, только желательно использовать и слово VALID (между IN(OUT) и BEFORE(AFTER)). На этой ПЛИС делал самопальное PCI ядро (33МГц 5В), все входы/выходы были с IFF и OFF. Проблемы были только с #Frame, когда захотелось сделать Fast Back-to-Back - пришлось его заводить без IFF прямо на логику и обкладывать OFFSET IN. Всё работает, но implementation стал требовать заметно больше времени.

Не совсем понятно, что Вам надо. В ISE10.1SP3 есть Coregen V5 EMAC Wrapper v1.5 делает почти всё, что надо; а в ISE11.1SP1 V5 EMAC Wrapper v1.6 (последний). Оба V5 EMAC Wrapper собственно и делают файло конфигурации TEMAC hardcore + еще генерируют некоторую кучку файлов-примеров, как это всё использовать. Почитайте AR #31860 - Virtex-4/-5 Embedded Tri-Mode Ethernet MAC - Problems switching from 10/100 Mb/s to 1G GMII operation, а вдруг поможет. Кстати, а какой версией ISE Вы пользуетесь ?

У Virtex-5 есть одна очень неприятная проблема, в более ранних ПЛИС не проявлявшаяся. По документации Virtex-5 переживает только 3 цикла "паятельного" прогрева, дальше действительно начинают VCCO на VCCINT закарачиваться,.. Посчитаем циклы прогрева: 1. Пайка. (предположим, что кривая). 2. Снятие BGA. 3. Reballing. 4. Повторная пайка.... - оп ля ля , а это уже 4 цикл => ПЛИС становиться трупом. Паяли наши на заводе пачку плат, а тут вдруг раз - часть ПЛИС (V5) - дохнут на глазах, превращаясь в трупы с КЗ по питанию. Наши к заводу: чё Вы делали с ПЛИС, что они так дохнут ???! Те - да ни фига не делали всё прекрасно, всё как обычно ! Тогда наши, применили технологию терморектального криптоанализа к представителям завода, и тут выяснилось, что проблемы только с теми V5, которые перепаивались... Выходит, что V5 стал одноразовый - как-то нехорошо получается... Кто еще какими наблюдениями поделится на тему повторного монтажа V5 ?

Жуть. Но ведь можно и гораздо проще подойти к этому вопросу: Sch преобразуются в HDL описание, для прохождения оптимизационных процедур при помощи синтезаторов... Вот по этим HDL описаниям и можно находить разницу,.. но, конечно, лучше сразу писать на HDL.

Уже не однократно писалось, что после Fit (или MAP + P&R) достаточно тяжело обнаружить исходные имена сигналов, что вызвано действиями оптимизаторов. В Ваше случае советую последовательно проглядеть: Synthesis Report, RTL Schematic, Technology Schematic, Fit Report. Есть шансы найти: где и что именно было заоптимизированно вусмерь. Теоретически можно из обломков типа sim:/m_m_sch_tb/UUT/\XLXI_1/DIVosc<n>_MC.Q собрать часть своего первородного сигнала и догадаться: что и почему отвалилось. Обычно, если все элементы шины благополучно пережили оптимизацию, то при моделировании эта шина присутствует и в списке линий.

Всем спасибо за ответы. Особо полезной оказалась ссылочка на соответствующую тему.

Есть фирма, на ней работает около 20 ПЛИС'овиков, работающих на Xilinx ISE. Каждая разрабатываемая плата содержит более 2 FPGA, а прошивку для каждой FPGA разрабатывает минимум 2 ПЛИС'овика. Ряд решений мигрируют с платы на плату, потихоньку развиваясь. В итоге очень легко получить месиво из исходных файлов, и, тем более, из прошивок. Может кто подскажет, какие есть программы, которые могут: 1. вести учёт изменений исходников (VHDL/Verilog). 2. вести учёт версий исходников, из которых собрана каждая конкретная прошивка. 3. работать на сервере, накапливая эти самые исходники и прошивки. Большинство ПЛИС'овиков работает под Windows XP, соответственно хочется, чтобы и клиентская часть такой программы работала под Win32. Если есть что-то очень хорошее, но Linux'овое, то тоже очень интересно. Если нету продукта, который может всё и сразу, то интересно, что вообще есть по этому направлению для ПЛИС. P.S. Было бы совсем замечательно, если бы такая программа могла работать и с Xilinx ISE schematic файлами.

Попробовал я разные варианты создания BlockROM для Spartan-3A, наиболее интересным оказался вариант от Core Generator – т.к. и для этого варианта выдаются все теже сообщения, что и у Вас. У Xilinx я не нашел рекомендуемого поведения на эти Warnings. Поэтому спросите у самого Xilinx, что делать, если ругается даже на код, рожденный Core Generator'ом. Удалось найти только аналогичные ошибки, но про выходные сигналы: http://www.xilinx.com/support/answers/24846.htm И я что-то не уловил: А зачем Вы используете attribute INIT (именно как атрибут) ? - Ведь у RAMB16_S18 есть Generic INIT - делает всё тоже самое, только без warnings при синтезе.

Если файлик L...dat сделан при помощи лекарства, то надо не забывать про ключик -exp - задающий дату окончания работы программы - тут сильно жадничать не надо, задаёте на год-другой. Я же правильно понял: денежку Вы не платили ?

С наскоку, могу предложить только тривиальный вариант. Предположим (ибо это не прозвучало явно), что: 1. Busy должен быть простробирован с некоей частотой, обзовём этот сигнал CLK_BUSY. 2. clk_link_out и CLK_BUSY имеют разные частоты, и частота CLK_BUSY выше раза в 2, чем у clk_link_out. Тогда, решение представляется таким образом: 1. clk_link_out последовательно проходит пару триггеров, тактируемых CLK_BUSY (примитивный вариант clock domain перехода), с последнего триггера выходит сигнал BUSY_CB_RST. 2. делаем маленький счетчик: синхронный сброс BUSY_CB_RST (active high), тактируется CLK_BUSY, перенос BUSY_CB_CY, разрешение счета not(BUSY_CB_CY). Как только clk_link_out замрёт в состонянии '0', то на счетчик перестанут подаваться сбросы, соответственно через некоторое время он досчитает до предельного значения, на выходе появиться перенос BUSY_CB_CY (блокирующий дальнейший счёт), который и можно использовать, как busy.

А вот пришлось мне делать этот самый multy function device - откровенно: на плате стоят 2 ПЛИС (XPLA3 и Spartan2 в PQ208 корпусах) точно напротив друг друга, по всем электрическим показателям в спецификацию укладываюсь. Естественно захотелось поиметь по прерыванию на каждую функцию... Тем более, что на PCI разъёме, INTA - со стороны CPLD, а INTB - FPGA; - вот думаю и переходных отверстий месить не понадобиться. Потом пришлось прерывание от FPGA (INTB) протаскивать сквозь CPLD (имеющего INTA) через конфигурационную ногу nINIT - работает, но ведь зная о такой грабельки не пришлось бы думать-выкручиваться и менять запланированную логику работы платы... Кстати, на Cross платах Advantech после intel PCI-PCI моста работали все 4 линии IRQ на каждый slot (Secondary PCI Slots), а вот до моста только по 1 линии (INTA) в Primary PCI Slots. Заодно проверил ряд бытовых мамок различных производителей (ASUS, MSI, EPOX, Gigabyte) и chipset’ов (VIA KT600, VIA M2V, nFroce 2, nForce 4, AMD 770) – тоже только INTA,.. о чём, собственно говоря, и написано в Mother board manuals (в таблице IRQ sharing). К сожаления, вот именно от этой грабли корка не защитит - ей всё равно, что мы укажем в конфигурационном поле Interrupt Pin, если у нас multy function device. Но есть же и нормальные (полноценные системы), где реализована полная функциональность PCI. PCI-корочка не знает же на насколько убогих машинах мы будем эксплуатировать её.

Для того, чтобы четко (с точки зрения потрохов ПЛИС) представлять, что такое PCI, в большинстве случает вполне достаточно детально ознакомиться с PCI Local Bus Specification Revision 2.3 (и, для полноты ощущений, обязательно и с 3.0). А т.к. Вы собираетесь делать свой PCI интерфейс, то "ознакамливаться детально" понадобиться непременно. Для того, чтобы уменьшить количество неприятных сюрпризов по применению PCI, настоятельно рекомендую прочитать книгу Addison-Wesley ShanleyAnderson PCI System Architecture (Fourth Edition). Имейте в виду, что: PCI, применяемый в desktop компьютерах, может несколько отличаться от того, что описан в PCI Local Bus Specification. Например, в спецификации указанно, что на разъёме есть 4 линии прерываний,.. а в реальности, на большинстве материнских плат, оказывается только одна линия INTA... Если же Вы попробуете в конфигурационном пространстве указать, что используете линию INTB, то при загрузке Windows увидите синий экран с очень интересным замечанием на эту тему. Вот чтобы в муках не исправлять своё устройство, из-за таких «мелочей», и рекомендую прочитать вышеозначенную книгу. А еще Вам понадобиться Ваш собственный Vendor ID...

Я часто встречался с решениями, где ПЛИС (для очень малых решений CPLD-128, для решений побольше - небольшие FPGA) использовались как "расширители" ног ввода/вывода. Т.е. ПЛИС вешается на шину МС (или к DSP) и работает интерфейсным переходником к ряду различных устройств. Ну например, есть ЦАП, на который надо выбрасывать с малым периодом поток кодов - циклически (для реализации какой-либо компенсации при измерениях). Самих коэффициентов получается не много и они легко могу умещать в блочное ОЗУ ПЛИС, но может понадобиться выбрасывать их с очень большой частотой (25 - 50 - 100 МГц) и при этом, еще и считывать данные с АЦП. А потом при паузе между измерениями МС (DSP) может медленно выгребать собранные данные из ПЛИС и переваривать оные. Т.е. ПЛИС при любом раскладе может иметь значительно больше ног вводы/вывода (поддерживают тучу всяких разных электрических стандартов), и также может с колоссальной (для MC) скоростью ими шевелить - остальное зависит от умений и изворотливости разработчика.

Берите самый маленький Spartan-3AN - он дешевле, чем CoolRunner 1 на 128 MC, и чуточку дороже CoolRunner 2 на 128 MC. Spartan-3AN минимум требует 2 питания: 1.2В и 3.3В. Обойдется это удовольствие где-то в 10$ (хотя цены, они такие - плавают). В итоге вы получите корпус TQ144, 3 18KBit блока ОЗУ (и 3 аппаратных знаковых умножителя 18x18), где-то с 1400 триггеров и LUT'ов, кусок встроенного FlashROM под свои нужды и еще много полезных мелочей, характерных для FPGA (DCM, поддержку огромной кучи стандартов IO и п.т.). Естественно, у FPGA есть некоторое время конфигурации при старте - это надо учитывать, но ведь и почти все современные CPLD не без грешка - они тоже любят конфигурироваться. Надо отметить, что Spartan-3AN по 1.2В жрёт весьма мало (вопрос в несколько десятков мА,.. после конфигурации), поэтому можно обходиться LowDrop преобразователем. Можно, конечно, поискать более удобные аналоги у Lattice, Actel и, может быть, Alter’ы – наверняка что-нибудь более удачное встретиться у Lattice. Если Ваше издели не серийное, то наверное стоит подходить к выбору FPGA c FlashROM отталкиваясь от времени, которое Вы потратите на освоение выбранной микросхемы и CAD'ов для её использования.

Я так понял "вручную" Вы воспользовались constraint LOC = BANKx ? Раньше я пользовался Constrain Editor'ом... потом в нём отрезали функциональность... приходилось пользоваться FloorPlanner'ом. А теперь преимущественно вручную редактирую UCF. Уж слишком корявым оказался PlanAhead - его еще доделывать и доделывать.

Попроси MAKS'а переложить куда надо - он в курсе куда и периодически это делает.

Ну,.. вписываются серийные номера в единственном месте,.. но на этом форуме не обсуждаются вопросы медицины. А именно для 9.2 на закромах родины водилась ключегенерилочка...

Я так понимаю "без использования библиотечных триггеров" означает, что Вы хотите это описать на каком-либо языке. Если для синтеза с языка использовать HDL, то начальное состояние триггера (ОЗУ и п.т.) задается через начальное значение переменной (сигнала), которая после синтеза превратиться в выход триггера. Для VDHL это выглядит примерно так: library ieee; library ieee; use ieee.std_logic_1164.all; entity FDRE_0 is port( C, D, CE, PRE, RST: in std_logic; Q: out std_logic ); end entity FDRE_0; architecture FDRE_0_BODY of FDRE_0 is begin process (C) variable FF: std_logic := '1'; begin if rising_edge(C) then if PRE = '1' then FF := '1'; elsif RST = '1' then FF := '0'; elsif CE='1' then FF := D; end if; end if; Q <= FF; end process; end FDRE_0_BODY; В итоге получается триггер с начальным состоянием '1'. Т.к. начальное состояние '1', то наивысший приоритет должен имеет сброс в '1' (т.е. PRE) - поэтому в основном if он проверяется первым. Следующий по приоритету идёт "инверсный" сброс - в приведенном примере это RST. Последним по приоритету идет сигнал CE и входные данные D (выход LUT или прямой вход на триггер мимо LUT).

Вот мне так тоже казалось, что если поставить на машинах с Windows 98 - XP протокол NetBEUI (и назначить копирование файлов через него), то копирование файлов происходит быстрее, чем через TCP/IP - а значить не может эмулироваться через IP. Но, к сожалению, это не даёт ответов на сформулированный мною выше вопрос: Кто-нибудь чего-нибудь может ответить на эти вопросы ???!!

Так это потому, что необходимо подругому считать коэфициенты в состоянии "ускорения" (например, как я и указал Ваше - при помощи делителя). Но лучше сделайте нормальный регулятор, который будет работать с обратными связями - тогда Вы получите минимальные погрешности и максимальную надежность работы системы. Если Вы воспользуетесь регуляторами полученными при использовании процедуры АКАР, то сможете задавать ряд желаемых аттракторов/репеллеров в системе, что придаст Вашей системе необходимые именно Вам свойства. Единственное с чем надо быть очень аккуратным, так это с параметрической чувствительностью регуляторов (любых регуляторов: и старых «классических», и свеженьких – полученных с помощью АКАР).

Soft - это вторично сначала физическая задача. Т.е. если Вы можете игнорировать динамические свойства двигателя и динамические свойства нагрузки на этот двигатель (т.е. работать с объектом управления без обратных связей !), то задача существенно упрощается. (пока что я встречался только с такими система управления, в которых игнорирование динамических свойств приводов/нагрузки - преступно). Ну если Вы можете позволить себе это проигнорировать, тогда пожалуйста, вот Вам несложное решение: 1. Делаете машину состояния, которая имеет всего 2 основных состояния: поддержание постоянной скорости и ускорение. 2. В состоянии "поддержание постоянной скорости" Вы либо ничего не делаете (записываете в управляемый делитель из раза в раз один и тот же код), либо как-то по измеренному иглу поворота компенсируете неточности задания скорости (как например работают ФАПЧ: подстраивают частоту измеряя фазу). 3. Для работы с состоянии "ускорение", Вам понадобится задавать 3 величины: период изменения коэффициентов для делителя частоты, "шаг изменения скорости" и количество периодов изменения коэффициентов для делителя частоты. 4. Работа в состоянии "ускорение": a] записать в регистр DIV_K_LOAD коэффициент, который будет некоторое время загружаться, как стартовой для управляемого делителя частоты. b] начать отсчет периода изменения скорости. c] пока идет периода изменения скорости, Вам необходимо подготовить новое значение коэффициента для регистра DIV_K_LOAD. d] по прошествии заданного количества периодов изменения коэффициентов для делителя частоты (периодов ускорения), перейти в состояние поддержание постоянной скорости (возможно с записью не вычисленного, а заранее заданного коэффициента для делителя частоты - так, возможно, будет точнее). Теперь поподробнее о вычислении коэффициента для делителя: У Вас система ооочень медленная, как и большинство систем управления - предельная частота всего-то 15кГц... Даже если учесть, что Ваш делитель управляемый частоты должен давать частоту в 3-6 раз большую, чем выходные 3 фазные импульсы, то всё равно получается очень большой период (по меркам ПЛИС), за который Вам необходимо вычислить новый коэффициент. Поэтому можно пользоваться компактным барабанным делителем. Ваш искомый коэффициент (назовём его DIV_K, разрядности n), можно достаточно просто найти: DIV_K = (2^n) - Alfa / (Cur_Freq + Delta_Freq) Delta_Freq - "щаг изменения скорости". Cur_Freq - текушая "скорость". Alfa - конструктивная константа Вашей системы. Если Ваш загружаемый счетчик во время загрузки не инкрементирует входные данные, то: DIV_K = (2^n - 1) - Alfa / (Cur_Freq + Delta_Freq) Это если Вам надо быстро и в первом приближении заставить двигатель шевелиться. А если всё делать надежно, то необходимо работать с обратными связями и использовать наработки Теории Автоматического Управления, для создания регуляторов. Можно воспользоваться и синергетической теорией управления – тогда результаты могут получиться лучше.

Есть версия, что этот "генератор" должен быть использован в системе создания импульсов для управления силовыми ключами некоего двигателя. Так ? Если оно так, то есть ли предельное значение погрешности ускорения, и нормировано ли отклонение реального ускорения от заданного ?

Без погрешностей, это реализовать невозможно. Поэтому поясните, какие именно виды ошибок генерируемых импульсов допустимы: 1. В случае, если после задания частоты импульсы генерируются одинаковыми (от периода к периоду), Какая максимальная допустима погрешность периода импульсов ? 2. Если по какой-то причине нельзя допускать долговременную ошибку частоты, то какая погрешность допустима на "дрожание" фронтов ?