Beby

С наскоку я могу только спросить: 1. А проверяли ли Вы, выполняются ли ограничения на входные сигналы (setup и hold) в живом стенде ? 2. Был ли использован constraint temperature для снижения предельной рабочей температуры ?

Точно также как и PACE'ом, ngd файл можно проглядеть FPGA Editor'ом. Просто запускаешь FPGA Editor отдельно, и указываешь ему файлы, которые он попросит.

Если Вам необходимо, чтобы схема работала как положено - без сбоев и проблем, то необходимо указывать ВСЕ конфигурационные constraint'ы. Для того, чтобы посмотреть какие у Вас получились настройки IOB, в Project Navigator'е в окне Design Summary выберите раздел IOB Properties и увидите текущую конфигурацию IOB. Или же можно запустить FPGA Editor и ознакомиться с разложенным проектом более детально (в т.ч. можно рассмотреть какие есть возможности по конфигурированию того или иного фрагмента ПЛИС, например IOB).

Очень поучительная картинка, если приглядеться внимательно: провод INIT лежит на плате... может и в воздухе висеть, от этого не легче. Был у меня очень нехороший случай: отлаживал PCI плату, Platform USB Cable воткнут в ту же машину. Всё работало хорошо... INIT аккуратненько лежал в корпусе машины. А вот спустя 3 месяца так случилось, что при включении машины, провод INIT сдвинулся (наверное под лёгким механическим напряжением лежал) и коснулся корпуса... а Flying Leads лежали так, что проводок +3.3V проходил по нижележащей плате, и изоляцией касался штырьков PLD (со стороны пайки этих штырьков)... При включении машины, блок питания ATX издал низкое злобное жужжание, а с провода +3.3 начал невесело подыматься дымок. Ну, реакция у меня не плохая, вырубил питание стенда не более чем за 1 секунду этого безобразия. В итоге пришлось заменить провод +3.3V Flying Leads, пропаять платку переходник Flying Leads и заменить пластмассовый корпус разъема самих Flying Leads. SB Audigy, чьего разъема и касался провод +3.3V никак не пострадал, PCI разъемы и все остальные компоненты машины тоже остались целы. Вот только теперь, когда я использую Flying leads на старых платах, а INIT не нужен, я вытаскиваю INIT из разъема на платке переходничке... А на новых платах применяю разъем BH2-14, на котором зарезервировано место и под INIT.

Вот в этом документе Platform Cable USB II (v1.2) фотографий - просто обсмотреться... А на Figure 14: Target Interface Connector Dimensions and Signal Assignments изображено именно то, что Вам надо.

Из названия видно, что Вы нарисовали схему с схемном редакторе... которым я не пользуюсь, а следовательно и могу сказать, что это за приписочка N033. В моих схемах (описанных на VHDL) названия компонентов несколько более осмысленные, например, в худшем случае, получаем что-то вроде DBUS_FRAME.US_DFRAME_CB_CY_L_I/CB_FD/FD_CORE[0].FDRE.FD_I. Где / - разделитель между entity, а . - разделитель между Block и instance name. Если вдуматься, конечно, получается кошмарное имя, но зато можно найти все концы - из чего это выросло. Зато могу подсказать, как найти (почти) все Slice в которых имеется XLXI_54: в окне List в окошке Name filter наберите *XLXI_54* - так найдется всё содержащее в середине XLXI_54. А обычно поиск устраивают по выходному сигналу... для этого необходимо в окне List в combo-box'е выставить All Nets.

Видно, достаточно хорошо, что кристал пустой... Для этого случая обычно вреда нет, от 100% использования slice с related logic only. Два элемента в slice называются related logic в том случае, если у этих элементов есть хотя бы один общий вход. По мнению Xilinx это позволяет улучшить параметры работы ПЛИС (знать бы еще какие). На практике если есть 2 элемента с общим(и) входом, и их можно разместить в одном slice, то такое размещение позволяет уменьшить количество линий связи в ПЛИС, что может снизить загрузку разводочного ресурса и улучшить разводку других линий связи. Но часто PAR пытается разместить 2 related элемента в один slice тогда, тогда это вредно для быстродействии схемы. Например: может быть так, что эти 2 элемента надо положить в разные концы ПЛИС, а PAR сначала попробует их положить рядом... в итоге увеличение времени компиляции проекта. А вот другой, более неприятный, пример: может быть так, что радом с каким-то элементом для оптимальной работы схемы (быстро и с минимальным использованием разводочного ресурса, - собственно говоря, поэтому-то и быстро) необходимо разместит unrelated элемент, а PAR не захочет этого делать... потому, что эти элементы unrelated в его понимании. Тогда приходиться использовать constaint'ы либо RLOC, либо AREA_GROUP - COMPRESSION. Ну Slice - не LUT и не FF, поэтому в явном виде количество использованных LUT, FF и SLICE никак не связанно (в 1 used Slice могут быть одновременно заняты как 2 LUT и 2 FF, так и 1 LUT или 1 FF). Запустите FPGA_Editor и поглядите, как выглядит проект в FPGA изнутри - разок глянуть просто необходимо. По приведенным Вами данным можно лишь сказать, что в среднем у вас приходиться по 1 LUT и 1 FF на 1 использованный Slice. Думаю, что проблема совсем в другом. Т.к. если пошаманить и вручную поднять плотность проекта, то это может только отразиться на максимальной рабочей частоте проекта, а не на работоспособность его в целом. Кстати Вы не указали как именно проект не работает. А посему вознивают нехорошие вопросы: 1. Задавали ли Вы constraint: TIMESPEC PERIOD ? 2. Проводили ли Post PAR моделирование ? P.S. Кстати по поводу картинок, делайте их в gif с индексными цветами, так они и красиво выглядят и место очень мало жрутъ.

Приведите, пожалуйста, конкретные цифры (от Logic Utilization до Number of bonded I/O) и, конечно, используемую ПЛИС, так будет понятнее, на какие аспекты ralated logic стоит обратить Ваше внимание.

Пожалуйста, конкретизируйте Ваш вопрос: Вы хотите начать изучать CPLD или FPGA ? Эти семейства принципиально отличаются, и соответственно отличаются подходы их программирования. Я бы советовал начать изучать FPGA, причём со Spartan-3A, т.к. это семейство современно и относительно просто для освоения, в тоже время оно имеет модификацию Spartan-3AN (с внутренней загрузочной Flash ROM) позволяющую заменить средние и крупные CPLD.

Подумал-подумал и решил, что тут можно увековечить эту полезную информацию: Порой приходиться в один IO банк ПЛИС напихать очень много синхронно переключающихся выходов (simultaneous switching outputs - SSOs), да еще и с большой энегроёмкотью. И так частенько нехорошо выходит, что количество этих самых SSO превышает предельно допустимое, зависящее от количества пар ног питания в этом IO банке... Xilinx для своих FPGA уже давно дала ответ, откуда брать дополнительные пары ног питания: оказывается в них можно превратить обычные выходные ножки. Но вот, к сожалению, мне не удалось сохранить первородный XAPP в котором это было явно (с формулками) прописано, поэтому привожу ссылку на WP323 v1.0 - Signal Integrity: Tips and Tricks.

Конечно пошло уже с 10 месяцев,.. но вопрос-то достаточно важный, а было бы хорошо иметь точную ссылку на документ от производителя ПЛИС. Вот случайно наткнулся в WP323 v1.0 на перепевку конкретных рекомендаций, но только для более новых ПЛИС:

Собственно говоря присоединяюсь: для того, чтобы загружать FPGA (Spartan-2) с PCI мне пришлось поставить на другой стороне платы CPLD (CoolRunner 1), к которому можно было обращаться по PCI для программирования FPGA. Т.е. фактически одна ПЛИС программировала другую. Такое решение, кстати, достаточно грубо попирает спецификацию PCI - на каждую плату не более одного набора входных каскадов (кроме особо описанных случаев).

Про LPT полностью согласен. Parallel Download Cable III делается достаточно просто - сам с него начинал,.. но тогда не было еще и в помине Xilinx USB Platform Cable, да и ПЛИС были с входами JTAG - 5В. Как-то уже не раз подымалось: "как сделать свой Xilinx JTAG шнурок..." но обычно всё заканчивалось тем что, если не жалко где-то 200$ (цены плаваю, поэтому точно сказать не могу), то лучше просто купить готовый Xilinx USB Platform Cable II (первую версию уже сняли с производства,.. но всё еще продают старые запасы) - так и быстрее, и дешевле.

Могу конечно и жестоко ошибаться, но в Windows аналогичный driver: XPC4DRVR.SYS используется только для работы с LPT кабелями (4 версии и более ранними). А для USB кабеля (а Windows конечно) используются совсем другая пачка driver’ов: xusb_emb.sys, xusb_xlp.sys, xusb_xpr.sys, xusb_xup.sys, xusbdfwu.sys. Кстати, отключение XPC4DRVR.SYS под Windows никак не мешает работе USB драйверов. Думаю, что под linux для USB тоже используются другие драйвера.

Я так понимаю "старую" PCI плату. Да даже если воткнут новую PCI плату удовлетворяющую PCI v2.3 (а все супостатские платы для PC - удовлетворяют этому стандарту или более раннемим, но не PCI v3.0), то тогда питание выходных каскадов должно браться с Vi/o ножек PCI разъемы, а во всех бытовых компьютерах для PCI v2.3 32bit 32Mhz - это только 5V, т.е. 5В уровни сигналов на входах CoolRunner - гарантированы. Конечно и этот вариант проверили - работает хорошо, устойчиво. Более того оказались, что из использованных, только chipset'ы VIA имеют CMOP (5V) выходы, остальные (Intel и nForce) уже выдают только 3.3В уровни сигналов, а далее, при освобождении сегмента PCI шины, все линии дотягиваются к 5В через резисторы подтяжки. Т.е. в плане 5V толерантности никаких проблем не возникало. Но опять-таки PCI - не ISA, первоначально PCI находиться в состоянии слабой подтяжки в 5В, именно в это время происходила загрузка (инициализация) CoolRunner 1. А после загрузки никаких проблем не выявлено. В тоже время, в тестовой плате CoolRunner наработал где-то около 1 часа в незапрограммированном состоянии, при полностью работающем PCI (с VIA KT600+VT8237 - т.е. при добротных CMOP 5V уровнях). Деградация CoolRunner 1 не замечена (эта плата в настоящее время устойчиво работает в лаборатории на стенде). При работе незапрограммированного CoolRunner на PCI, сам CoolRunner оставался холожным - что косвенно говорит, о нормальной работе 5V толерантности.

Э-хе-хе совсем забыл,.. на тему 5V толерантности: есть у меня старый проектик, в котором стоит XCR3256XL-10PQ208I подключенная напрямую к PCI 5V 33Mhz. Конечно, PCI - это не ISA, но несколько этих плат достаточно интенсивно работают (каждый день не менее 10 часов) уже около 2-3 лет с чипсетами VIA, Intel, nForce. Сбоев, как и проблем пока тоже нет. Питание ПЛИС берётся непосредственно с контактов PCI разъема (+3.3V). Надеюсь эта информация окажется полезной.

Если имеется ввиду Spartan-6, то боюсь в нем не будет никакого LUT6, ибо в Spartan-6 Family Overview сказанно: Each Spartan-6 CLB contains four LUTs and eight flip-flops. Странно это как-то... что-то мне подсказывает, что на 1 CLB приходиться 8 LUT5 (по количеству триггеров... в противном случае нафига нужны 4 триггера не обеспеченных логикой ??!) Ну и конечно же предусмотрены мультиплексоры, с каким-нибудь гордым названием MUXF6 - для эмуляции того самого LUT6 из 2 LUT5. А то как-то подозрительно выглядит отсутствие картинок в предварительном описании Spartan-6. Раньше-то на картинки не скупились, боюсь Xilinx опять мухлюет. Хотя, конечно, могу и ошибаться.

Поищите аналогичные не Philips буферы - вроде их будет попроще достать. Немного уточню... Вам необходимо проглядеть детально информацию о PC-104 с которыми Вы будете иметь дело. Про свои PC-104 я точно знал, что они не выдадут ток по шинам адреса и управления ISA достаточный для повреждения XPLA3. Если Вам заранее не известен набор PC-104 с которыми понадобиться работать, то на всякий случай, предусмотрите последовательные резисторы на все линии подходящие к XPLA3, в случае необходимости Вы всегда сможете запаять не 0Ом, а что-нибудь посущественней - нескольких XAPP были рекомендации на тему ограничения тока для улучшения выживания для различных семейств ПЛИС. При поданом питании +3.3В с XPLA3 проблем с 5В толерантностью у меня не возникало ниразу,.. а вот без питания я не пробовал подавать на ПЛИС 5 В сигналы, поэтому ничего не могу сказать об этом случае. А еще есть время конфигурирования ПЛИС... наверное желательно, чтобы в это время на ПЛИС не подовались 5В сигналы... Но вопросы на которые необходимо знать точные ответы, лучше адресовать к самому Xilinx, т.к. только они знают как они же сами втихоря меняют технолоический процес производства ПЛИС. На форуме мы может только посоветовать или сказать что 4 года назад работало хорошо. А вот в inline Group (официаный представитель Xilinx, вроде бы его зона ответственности распространяется и на Белорусию) есть специальный человечек, отвечающий именно на технические вопросы.

Работал именно с PC104, ставил две Philips 74AHC(T) в TSSOP корпусе по шине данных, остальные линии (входы для ПЛИС) заходили на XPLA3 напрямую. Питание на ПЛИС подавалось с IRU1207-33CS без задержек.

Задайте этот вопрос в официальное представительство Xilinx - Inline Group (если Вы у них приобретали микросхемы). У них есть специальный человек для подобных вопросов. Вижу 4 варианта: 1. ПЛИС сгорает. 2. ПЛИС засаживает ISA. 3. ПЛИС подсаживает ISA, и через себя питает цепь +3.3В. 4. Всё работает нормально. Чтобы не ломать голову, а что именно будет, в старых проектах с ISA использовал двунаправленные буфера 74AHC(T).

Мы покупали в России через Inline Group, но у нас был USB ключик (навязанный). В комплекте с ModelSim XE (или ключом ? - чего не знаю, того не знаю) шла бумага, на которой была описана процедура регистрации через и-нет: 1. Внимательно переписываем номер сетевухи и номер ключа, высылаем на определенный и-нет адрес. 2. Получаем оттуда ответ. 3. Если что-то указали неверно в п.1, то платим бабки и повторяем процедуру... Вот приблизительно такая инструкция, естественно не на руссом. Теоретически без USB ключа должно быть даже лучше - меньше простор для ошибки, возможно, удастся использовать license server (ограничивающий количество одновременно запущенных программ, вне зависимости от самих машин, на которых они запускаются). Полностью присоединяюсь. Эти ребята Вам продавали продукт, пусть объясняют процедуру ввода проданного ПО в работу - эту часть работы они обязаны сделать.

Если не секрет, то у кого купили ? На каких условия покупался ModelSim XE III 6.3c ? Предлагалось ли Вам приобрести USB ключик ?..

Точно. Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п. Но архитектура уже более или менее определилась: две груды LVPECL линий заходят на Spartan-3AN (благо, хоть это и не документированно для этой ПЛИС, но при желании, можно собрать LVPECL выходы аналогичные "Virtex-E LVPECL"), благополучно преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные. Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни). Также не может не радовать и то, что выступившим удалось передать более 100МБайт/с по Gigabit Ethernet, мне же всего-то требуется только 15МБайт/с (или, если очень захочется заказчику увеличить количество датчиков - ну никак не более 30МБайт/с - только для меня остается загадной: нафига ставить еще больше датчиков - их и так в полноценной системе их дофига, а обычно заказывают с 50%-60% каналов сбора данных).

Просмотрев Virtex-5 FPGA Embedded Tri-Mode Ethernet MAC User Guide я пришел к выводу, что если необходимо работать с медными проводами, то необходима внешняя PHY, а RocketIO (без HPY) может использоваться только для работы с оптическим приемопередатчиком (1000BASE-X). Надеюсь я всё правильно понял ? Ну а коли в режиме GMII частоты более 125МГц не используются, то можно брать практически любую недорогую ПЛИС. Если я в чём заблуждаюсь, то прошу меня поправлять (сейчас приходится много чего читать, а после детального прочтения задень более 150 страниц на нерусском, ум за разум заходит к вечеру...)

Если внимательно разуть глаза, то можно заметить, что "Проблемы" не просто в PC, а в отмирании PCI 32bit 5V (PCI v2.3) в этих самых персональных компьютерах (т.е. именно в железе)... Ну а в какай области проблема - в такой естественно и решается. Читаем внимательно: Нетрудно догадаться, что применение самопальной PCI платы и непрерывное гладкое графическое полноэкранное отображение врятли будут сдруживаться с какими-либо стандартными программами, а посему логично предположить, что используется какая-то своя специализированная программа. Для исчезновения дискуссий не связанных с темой обсуждения сразу скажу, что данные этой программой успешно накапливаются сотнями гигабайт в своей "базе данных" (если это так можно назвать). Да и не просто накапливаются, но и достаточно хорошо компрессируются, и с выборкой данных из этой груды тоже никаких проблем нет. Выражу своё резкое несогласие: 1. Поток в 15МБайт/с для HiperTransport/PCI-E (основных коммуникационных артерий современного PC) - это просто смех. 2. Если правильно подбирать железо, то пишет на HDD хорошо (почую, что будет зашиваться один серверный винчестер - поставлю два... и в RAID их). 3. Программы тоже надо уметь писать, если пользовать DirectX и (или) OpenGL (а у нас есть варианты программы для обоих), то даже под Windows графика не тормозит, да и грамотно организованная многопоточность хорошо помогает на современных процессорах (2 и более ядерных). В ПЛИС страшно посчитать количество "так сказать" параллельных потоков, почему же тогда параллельное программирование для CPU считается чем-то из ряда вон выходящим ??! Я не собираюсь хранить, а уже храню: Ну да, с увеличением потока понадобится поставить не 500ГБ винчестер, а наверное пару то 1ТБ (и в RAID их), ну а если заказчик захочет ещё и надежности побольше (чего, к моему удивлению, за 10 лет работы с оным ну никак не отмечалось), то поставлю 4 HDD по 1-2ТБ. Вот чтобы не было всех этих проблем: Для того, чтобы не возникало ненужных вопросов - комплекс специализированный. На территории Российской Федерации их требуется всего около 100 шт, естественно конкуренты не дадут занять всю нишу. Железо, в т.ч. и для PC, работающего на объекте подбирается только производителем комплекса. P.S. Ваши замечания могу считать справедливыми только если Вы по ошибке приняли 120Мбитный поток, за 120БМайтный поток. Но 120БМайтный поток данных через одиночную Gigabit Ethernet линию никак прокачать не удастся. Вопрос ведь стоял не "в куда" залить данные, а какбы это так поудобнее их выпихнуть из железяки, чтобы уж очень сильно не напрягаться.