Beby

Эх, как же выродились аппаратчики... - до уровня средненьких программистов. Для принудительного использования линий в качестве GSR, GTS и т.п - есть 2 пути: 1. читаем cgd.pdf про constraint BUFG. 2. читаем cpld_all_scm.pdf (название дано для ISE10.1) про примитивы BUFG, BUFGSR и BUFGTS. В обоих случаях, для предотвращения недоразумений, на все входы и выходы растыкиваем IBUF/OBUF - по необходимости.

Может, конечно, и не угадаю (знакомый телепат всё еще не вышел из зимней спячки) но, было у меня подобное с моделированием (правда железячка работала безотказно,.. да и сейчас всё еще работает) - при Post-Route Simulation уже учитываются Setup и Hold задержки в триггерах, поэтому тактовые частоты должны правильно подаваться на модель: так, чтобы фронты не попали в зону Setup и Hold относительно falling edge сигналов GSR, GTS.

К сказанному Gothard могу добавить вот такой тонкий моментик: в Xilinx FPGA c большими корпусами (1000 и более шаров), банки несколько неравнозначные по длине соединительных линий от самого кристалла к шарикам (причем разброс длин этих линий в пределах банка может быть более 100пс) - если Вы используете умеренно шустрый интерфейс и с тренировками (как у DDR) вам возиться неохота, то эти задержечки тоже надо учитывать... или брать банк поближе к центру корпуса. Если мне не изменяет память, то вроде в ISE 10.3 можно было посмотреть эти задержки при помощи PACE.

Я тоже проверял "на размер кеша" в ISE 9.x (еще года с 1.5-2 назад) - у меня получилось что: прирост от объёма кеша больше всего влиял на скорость работы XST, а на MAP и P&R влияние почти никак не оказал.

Ну как это не предвидится: Xilinx обещал многопроцессорную поддержку для новых кристаллов, причём много, по их словам это больше 2. А такой поворот событий может сильно повлиять на подбор "правильной" конфигурации PC для ISE; - вот и джусъ ISE 12.x с нетерпением !

Конечные требования к блокировочным конденсаторам сильно зависят от Вашей прошивки. Если у Вас будет дрыгаться триггеров эдак с 10, то может вообще заработает и на 1 блокировочном конденсаторе 0.1мкФ. В этом месте лучше не экономить на блохах, а натыкать побольше CC0402 X7R, чтобы не погореть на переразводке платы. А вот после запуска задачи, поглядите осциллографом (лучше с активным диф. щупом) что же именно твориться на каждом блокировочном конденсаторе - тогда Вам и станет понятно: в каких цепях питания надобно еще добавить конденсаторы, а где можно их и упразднить...

Что-то не очень разумел, что же именно Вам надо, но если моё предположение верно то: Если у Вас не высокая частота clock'а, то тогда Вы можете безболезненно разделить логические функции и триггеры (для этого на логику навешиваете constraint keep - могу несколько ошибаться, но вроде keep и на CPLD работает). Попробуйте скомпилировать. Если не пошло, то тогда надо попробовать за'LOC'чить (при помощи loc) вашу логику в FB не содержащим выходных триггеров. К сожалению, я уже 2 года как не работаю с CPLD, поэтому могу несколько ошибаться с названиями constraint’ов - но суть решения проблемы описана верно.

Может, конечно, несколько банальное предложение: посмотрите FPGA Editor'ом, что же именно у Вас получается в обоих случаях - обычно эта процедура помогала.

Совсем прямой ссылки нет. Но если поставить ихний Download Manager, начать закачку, оборвать её и при выходе записать link на рабочий стол, то сходив по этому link можно получить временную прямую ссылку, с которой у меня смог работать ReGet. Полученная таким путём ссылка живёт от 2 до 5 суток.

RLOC используют когда что-то заводят на предельные для кристалла частоты; или когда собирают из примитивов что-то очень извращенное (т.е. сильно запереоптимизированное), т.к. оно выше понимая ISE, то оно (ISE) не может это правильно (с точки зрения разработчика) расположить в CLB. Расплатой же за применение RLOC являются дополнительные затраты при перемещении проекта на новое семейство кристаллов.

Может мой ответ будет несколько не по делу,.. но мне кажется, что необходимо, на всякий случай, прояснить несколько моментов: 1. RLOC не даёт абсолютную "привязку", он задаёт только относительное расположение элементов в наборе (U_SET и т.п.). Может я чего-то пропустил, но я ни разу не видел, чтобы FloorPlanner отображал RLOC. Вот LOC - этот, да, хорошо виден. 2. Необходимо помнить, что в Virtex-E точка R0C0 была сверху слева, а в Virtex-4 точка X0Y0 - снизу слева.

Слушай умного человека, внимательно слушай. В большинстве случаев умным людям хватит и 66 МГц. Разве свет клином сошелся только на одном из двух фронтов тактовых импульсов ? Да, да ! Долбись головой об стену ! Только когда прийдёт другая партия ПЛИС, немного измениться питание (из-за другой серии источников питания) не удивляйся почему задержки резко изменились.

XPLA3 - как раз 5В толерантны... Выдать, конечно, смогут только 3.3В, так что выходы желательно пропустить через буфера. CoolRunner 2 - не 5В толерантны. Да, опечатался. XC3S50AN-xTQ144x. Официальный дистрибьютор уже с пол года торгует ими в розницу - сами у них покупали.

Сам делал периферийные устройства ISA на XPLA3 - они мне больше понравились, чем XC9500xx. Но сейчас уже вовсю продаётся Spartan-3AN - он тоже с Flash ROM на борту, но при его использовании, конечно, понадобится поставить внешние преобразователи уровней. Если бы мне сейчас понадобилось делать ISA устройство, то с большой вероятностью я бы выбрал XC3SAN50-xTQ144x.

Насколько я помню, по стандарту оговаривалось 100м для кабеля Cat5 UTP (Unshielded Twisted Pairs, а не протокола UDP). Некоторые производители сетевого оборудования выпускали спец. версии своего оборудования для работы на бОльшие, чем положено, расстояние (т.е. с увеличенной выходной мощностью - никак со стандартом не согласующейся). В телефонии из подобной проблемы выходят использованием кабеля с большим сечением проводников, например 1.2мм. По сравнению с кабелем сечением 0.5, на кабеле с сечением 1.2 омические потери меньше в 5.76 раза... это конечно не значит, что дальность возрастёт ровно в 5.76 раз, т.к. есть и другие факторы мешающие прохождению сигнала. Но, в тоже время, при описанном выше увеличении сечения проводников дальность всё-таки увеличивается в 3-5 раз. И конечно, при указанных расстояниях необходимо использовать экранированный кабель (STP - Shielded Twisted Pairs).

В готовом виде взять негде... но возможно подойдёт такой подход: В Floor Planer (или Plan Ahead) + FPGA Editor'е смотрите соответствие банков ввода-вывода - клоковым регионам. Ну а затем по ug075.pdf (Packaging and Pinout Specification) определяете конкретные ножки для интересующих Вас банков. Конечно прийдётся по пухнуть... но вешаться точно не понадобится - всё таки таблицы соответствия ножек - банкам за Вас уже сделаны, осталось только состряпать таблицу соответствия банков - clock domain'ам. Тока недавно сам такое делал для Virtex-5.

Смотрел на код минут с 10,.. так и не смог понять, что же такое у Вас получилось. Но уж точно: сдвиговый регистр описывается по иному. Если Вы работаете с Xilinx ISE, то почитайте XST.pdf, в нём есть раздел Shift Registers HDL Coding Techniques. Обратите внимание на то, что в приведённом примере используется C'Event - что позволяет синтезировать триггер. Тогда у Вас получиться нормальный сдвиговый регистр. C'Event and C = '1' эквивалентно rising_edge©. Сейчас же у Вас (если я правильно понял) получилось нечто асинхронное, поведение которого при временном моделировании (у Вас же картинка временного моделирования ?) определяются задержками логических элементов и разводки.

Да действительно всё правильно написано... надо только читать да конца: In Spartan-II, Spartan-IIE, Spartan-3, Virtex, Virtex-E, Virtex-II, Virtex-II Pro, and Virtex-II Pro X, BUF is usually not necessary and is removed by the partitioning software (MAP). In XC9500/XV/XL, CoolRunner XPLA3, and CoolRunner-II, BUF is usually removed, unless you inhibit optimization by applying the OPT=OFF attribute to the BUF symbol. А чтобы не задавать глупых вопросов, рисуете схему (лучше, конечно, писать на языке - тогда отпадает ряд вопросов... и появляются новые) с интересующим Вас элементом, компилируете прошивочку и запускаете FPGA Editor ! И, о чудо, в нём всё видно: какие опции и у каких элементов стоят, как и куда разведены трассы, во что превратилась Ваша схема. Для полноценного самообучения лучше метода посоветовать не могу, если, конечно, Вы не хотите быть серой посредственностью. А зря. Опять таки, возникает вопрос: а Вы действительно хотите научиться работать с ПЛИС ? Или просто надо сделать несколько лаб. и забыть, как страшный сон. Суда по количеству страниц в lib.pdf Вы пользуете ISE от 8.1 до 9.2 (у них одинаковый Lib Guide), а же надеялся, что Вы пользуете более современную среду, в них Lib Guide'ы разделены по конкретным семействам ПЛИС, и соответственно не содержат лишних элементов, а значит заметно меньше. При нормальном процессе, люди сначала думают, потом читают (в т.ч. и Manual’ы), и потом еще раз думают, а только после этого спрашивают. Несоблюдения этого процесса наводит на нехорошие мысли. Обычно (т.е. не на начало семестра), на этом форуме серьёзные люди обсуждают методы и принципы построения серьезных схем. Не менее 10% этих схем отвечает за обороноспособность наших стран (России, Белоруссии, Украины и пр.). А Вы отвлекаете серьёзных людей от их тяжких дум... (хорошо, что я сейчас разрабатываю системы безопасности всего лишь для железной дороги, а не для АЭС (как раньше) - вот и выкроил время ответить). Полностью согласен. Наверное, студиозы добрались до лабораторных работ. Запустите FPGA Editor и всё увидите сами... Конечно, прийдётся немного подумать.

Э-хе-хе... Да когда же Вы думать начнёте ??? (а главное писать на языке, тогда и станет понятно почему и что именно нельзя делать). Первый случай - английским по синему написано, что: ну никак нельзя сделать IO маркер - фрагмент (!) шины - это не ляжет в языковое описание. Лечится очень просто: D(7) заводиться на BUF (просто BUF, не I и не O) и подключается к нему другой маркер, например D7. Второй случай: ну как Вы себе представляете описание в текстовом виде - сигнал FRef зашел и тут же вышел, с тем же самым названием (FRef) - бред... А если сигнал надо вывесит с другим названием, то тогда имеет место присвоение FRef_Out <= FRef - что на схеме изображается в виде элемента BUF, на входе которого FRef, а на выходе FRef_Out. И вообще прочитайте сначала Library Guide (весь !), сделайте Quick Start...

А всё это потому, уважаемый, что Вы поленились вставить IBUF (BUFG) и OBUF.

У Xilinx FPGA (Spartan-3x/6 и Virtex-4/5/6) возможно отключение Clobal Clock при помощи BUFGx (буфера, заводящего сигнал в Clobal Clock Domain). Так же предусмотрен режим Sleep (всего кристалла) - но я им не пользовался, и поэтому не могу сказать насколько коряво они реализованы.

Вот только в пятницу долбался с V5LX85T: что-то мой микроскопический проект, синтезирующийся обычно около 30 секунд вдруг стал синтезироваться более 10 минут... в результате получил следующее - XST от ISE 10.1SP3 крайне плохо реагирует на память, описанную как двойной массив Std_Logic_vector (без разницы, описать «это» как одномерный массив одномерных массивов, или описать как двухмерный массив). 1. Как оказалось правильно надо описывать так: работу с внешними индексами описывать через for - generate, тогда можно обойтись внутри этого for уже одномерными массивами. 2. Уход от прямой двухмерной адресации (к for-generate с груде одномерных массивчиков) уменьшил объём потребляемой памяти на 40Мб, на каждом двухмерном массиве (и соответственно время синтеза). 3. Если приписать начальные значения регистру (который должен быть при синтезе воспринят как выходной регистр блочного ОЗУ) при двухмерной адресации, то на каждый двухмерный массив, XST сожрёт еще по 200Бм ОЗУ (и кучу времени). В то же время, если использовать for-generate и кучку одномерных массивов (в которых присутствуют начальные значения выходных триггеров), то на XST это никак не отражается (и ОЗУ он жрёт столько же, как и без начальных условий, и синтезирует такое же время).

Есть одно заподло, для 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 стал требовать заметно больше времени.