Beby

Ответы находятся в FPGA Editor'е, которым я настоятельно рекомендовал посмотреть Ваш кристалл, чтобы Вы не писали ахинею: Ну вот расскажите мне: где тут "второй вход сброса в триггер" ? Я его, почему-то в упор не вижу... Зато вижу тут атрибут RESET TYPE: SYNC/ASYNC, о котором и писал ренее.

Эээ... а вход-то в Slice - один... а способ его использования (синхронный/асинхронный) задаётся атрибутом - можете всё сами разглядеть при помощи FPGA Editor'a. А т.к. вход один на весь Slice, то он заходит на все триггеры в Slice. Соответственно, если в схеме нет триггеров, которым нужен такой набор управляющих сигналов (CLK, CE, RST), то тогда неиспользованные в этом Slice триггеры не смогут быть использованы. Поэтому уникальные наборы управляющих сигналов необходимо использовать с умом.

Да, а еще и именно на Ваш Spatran 6. Он же может быть какой-нибудь ES...Spartan-6 Documentation Просмотрите в errata (например en148) раздел Block RAM - может там есть Ваш случай. Также можно порыться в этих мусорниках: Design Advisory Master Answer Record for Spartan-6 FPGA Spartan-6 - 12.4 Software Known Issues related to the Spartan-6 FPGA Spartan-6 - 13.4 Known Issues Related to Spartan-6 FPGA ISE Design Suite 12 - Known Issues ISE Design Suite 13 - Known Issues ISE Design Suite 14 - Known Issues Может быть этот документ немного поможет: Block Memory Generator v6.3 - Release Notes and Known Issues for ISE Design Suite 13.4 Для Virtex-6 мы применяем 12.4, 13.2 и 13.4 - все имеют свои проблемы. 14.1 и 14.2 содержали бооольшие косяки и до выхода 14.3 нами было решено ими не пользоваться. P.S. Virtex-6 всегда был более любибмым продуктом, чем Spartan-6. И, возможно, еще не все глюки официально заявлены для Spartan-6. Для Virtex-6 официально заявлено больше проблем с RAMB: Design Advisory Master Answer Record for Virtex-6 FPGA

Есть мысли: в RAMB(FIFO) в Virtex-6/Spartan-6 что-то (ECC ?) перемудрили, поэтому они работают корректно не во всех возможных режимах, со временем в документации (UG) появились дополнения, описывающие эти проблемы, а в соответствующих Errata появились записи о кривизне. Ряд несуразностей латались программно в ISE/CoreGen'е (поэтому появлялась еще и зависимость от версии среды). Естественно, самые неприятные вещи выползают при независимых тактовых. Некоторые решения, которые у нас работали в Virtex-5 пришлось несколько переделать, чтобы они заработали в Virtex-6, но т.к. мы с этим долбались более 1.5 лет назад, то уже плохо помнится, где именно и какие были засады - помню только, что сначала они выползли в Errata, а затем и в соответствующие UG'и. P.S. Проверьте, что именно выставил на RAMB CoreGen, и какие есть замечания на эти настройки в UG/Errata. Если Вы пользуетесь старой версией ISE (<12.4), то потребуется её обновить. Также были косяки связанные с игнорированием "ранними" (до 13.2 ? 14.3 ???) версиями ISE некоторых временных путей для RAMB. Timing на RAMB Reset точно до каких-то версий ISE - игнорировался, а какие еще были глюки уже и не упомню.

Может потому, что не задан собственно constaint для Clk_input ? У Вас-то проанализировано на непонятно что: Default period analysis for Clock 'Clk_input' а не на конкретное ограничение... Вот когда у Вас в отчёте будет slack (а также clock path) - тогда можно будет о чём-либо более конкретном поговорить.

Сдаётся мне, что в этот раз к Вам пришли всё-таки не пустые ПЛИС. Попробуйте проверить на очередной плате (а еще лучше в программаторе) ПЛИС на пустоту: Blank Check – на XPLA3 такая проверка давала адекватный ответ, даже если прошивка была защищена от считывания, а с XC9500 мне не довелось поработать.

Эээ... что-то Вы странное говорите... тут надо добавить конкретики. Например тут мы уже обсуждали BUFT Xilinx и их проблемы. Прошу всех заинтересованных лиц ознакомиться с материалом. Вы не совсем четко описали проблему, поэтому мне видятся несколько причин: 1. Вы монтируете на плату ПЛИС с какими-то прошивками, соответственно, чтобы не было проблем с платой - стирайте ПЛИС до установки на плату. 2. У Вас есть ошибки в проекте, приводящие к тому ПЛИС конфликтует(ют), либо друг с другом, либо с внешними элементами. Есть, еще один момент: у XPLA3 (CoolRunner - симпатичная такая CLPD) была одна подляна - несмотря на то, что XPLA3 - CPLD, она имеет конфигурационное ОЗУ, и при старте ПЛИС в него переливается содержимое встроенной Flash ROM. Таким образом, в первый момент времени (до переливки содержимого Flash ROM) XPLA3 могла жрать заметно больше, чем положено. Вроде бы к XC9500 это не относится... но это следует проверить.

Ну коли речь зашла о неоднократно программируемых ПЗУ, то тоже поделюсь опытом. Мы сейчас применяем COM-Module'и, так вот из 600 приобретённых устройств где-то в 20 пришлось обновлять BIOS из-за частичного разрушения содержимого Flash ROM. Все COM-Module'и были сравнительно свежие на момент покупки (от 2 до 5 месяцев с момента производства), при производстве, естественно, прошли все тесты (в Германии, а бюгрегы пока не были уличены в выполнении работ с ненадлежащим качеством). Почему дохнут BIOS'ы при транспортировке - выяснить пока не удалось, но эта бодяга длится уже более года... А вот однократно программируемые конфигурационные ПЗУ типа XC17... у меня ни разу не отказывали (на протяжении 5-7 лет эксплуатации), но и применял я их мало - 12 - 15 штук.

Расклад приблизительно такой: SPARTAN (XCS20) своей встроенной ПЗУ не имеет, в нём есть только конфигурационное ОЗУ, в котором может храниться прошивка только при поданном питании. Обычно, прошивка в Spartan попадала через ножки DIN и CCLK. Посмотрите, куда они подключены. Для дальнейших советов необходимо знать подключение ножек: M, PROG, DONE, INIT, DIN, CCLK, JTAG (TDI, TDO, TMS, TCK).

Вот, пожалуйста: XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices (UG687 (v 14.1) April 24, 2012) страница 355 "The Save (S or SAVE) constraint". Для net лучше применять S, а XST и сам его истолкует правильно, и сконвертирует в подмножество необходимых MAP'у constraint'ов, навесив их на ссинтезированные instance. Т.к. при языковом описании описываются именно net, а не instance, то использование S получается более предпочтительным.

Чтобы с минимумом проблем - в любом Slave или JTAG режиме. Вы так и не написали (или я проглядел) что именно Вам необходимо запрограммировать. Есть у Xilinx пример Indirect Programming of BPI PROMs with Virtex-5 FPGAs, хоть тут пишется про V-5, для V-6 оно тоже справедливо. Для более детальной информации Вам необходимо в меню iMPACT выбрать Help->Software Mauals, затем выбрать iMPACT Help, после найти разделы indirect programming и ознакомиться с ними. В этих разделах есть информация о том, какие микросхемы ПЗУ и для какого семейства ПЛИС могут бытьзапрограммированы при помощи Вашей версии iMPACT.

Воспользуйтесь Sinthesys Constaint S. Его надо навешивать на net. Детали можно найти в XST User Guide.

Вот как раз с Virtex-6 уже загрузился, а надо залить другую (отладочную) прошивку и была проблема. Возможно глюг более тонкий, и, в большей степени, каcается ISE iMPACT 13.x (может он коряво настраивает внутренний блок старта и загрузки - кто его знает ?). Но факт имел (имеет) место быть: при начале загрузки через JTAG подаётся внутренний Program, после успешного стирания конфигурационной памяти Init переходит в '1', и ПЛИС фиксирует состояние M[2:0], если на них выставлен любой Master Mode, то ПЛИС начинает себя конфигурировать - тут-то и начитается тот самый "interference" JTAG с процессом самозагрузки ПЛИС. Но, повторюсь, для ловли проблем от этого эффекта скорость самозагрузки ПЛИС должна быть весьма большая: мы поймали при Master SelectMap 16-bit (а вот какую скорость ставили колеги в BitGen'е - не помню; зато помню, что при 2 сеё заподло себя никак не проявляет). А для какого именно семейства ПЛИС ?

Вы жестоко ошибаетесь. Для ПЛИС не всё-равно в каком состоянии находятся ножки M[2:0] для работы с JTAG. Суть мерзкого явления приблизительно такова: после окончания сброса (поданного с JTAG) ПЛИС проверяет ножки M[2:0] и начинает грузиться с того, что указано. Если JTAG успевает вклиниться в загрузку до того как будет всосано "достаточное" количесво данных с ПЗУ, то всё пройдёт успешно... Если JTAG не успеет - значит получится хрен знает что. Естественно, чтобы такая бякость возникла, необходимо иметь достаточно шуструю ПЗУ. Мы с этим эффектом столкнулись на Virtex-6 c Platform Flash XL и относительно "большой" скоростью загрузки. P.S. В Virtex-6 FPGA Configuration User Guide есть такое замечание: "The FPGA mode (M[2:0]) pins are shown set to Master BPI-Up mode (010). The implementation of a board-level option that enables the user to change the FPGA mode pins to JTAG mode (101) is recommended to enable JTAG-based debug capability for the FPGA during design. This is not required, but the JTAG mode setting ensures that there is no interference from the Master BPI-Up configuration during debug." Несмотря на то, что тут говориться про Master BPI-Up, мы смогли на это напороться при Master SelectMAP.

Я скажу по другому - он не может выдавать чистый сигнал. Если входной сигнал совсем поганый - то DCM его хорошенько почистит,.. а если входной сигнал чистый, то, соответственно, несколько испоганит. Но тут вопрос не столько в DCM, сколько в жёстких требованиях 88E1111 - у них, похоже, система чувствительна в jitter'у определённой частоты, т.е. во времена разработки 88E1111 явно предполагалось, что к ней будет подвешен кварц, а частоту будут брать уже с 88E1111 для своих целей - и нога для этого есть специальная. И я её даже пользовал в проекте со Spartan-3A: 88E1111 из 25МГц делал весьма чистенькие 125МГц. Да, ModelSim. На самом деле всё у меня работает тоже по положительному фронту... просто GTX_CLK выдаётся инверсным (на ODDR 1 и 0 на D местами поменяны). Это хорошо. Но на будущее, моя практика показала, что лучше такие constaint'ы добавлять прямо в код - тогда код лучше (грамотнее) XST синтезируется.

1. Попробуйте сделать вот такие времянки для TX GMII интерфейса: Этот вариант должен помочь со стабильность передачи данных в Eth Phy. В Вашем исходнике я не заметил constaint'ов IOB для GM_TxD, GM_TxEn, если этих constaint'ов нет где-то в другом месте, то их необходимо добавить. 2. 88E1111 имеет очень жесткие требования к XTAL1, и меня берут жестокие сомнения, что после пропускания CLK через DCM получится что-то подходящее. Поэтому предлагаю 2 выхода: 1) завести на XTAL1 первородный входной Clock, который вы сейчас подаёте на DCM - в этом случае 88E1111 получит наиболее чистый clock. Правда для этого прийдётся ногу SEL_FREQ посадить на землю. 2) поделить входной Clock (не прошедший DCM) на триггерах и через ODDR (тактируемую первородным входным Clock'ом) выдать наружу. На всякий случай посоветую еще раз внимательно просмотреть раздел XTAL1 Input Clock Timing 88E1111 Datasheet - особенно с три сноски внизу. 3. Для работы с 88E1111 GMII/RGMII я использовал Spartan-3A/Virtex-5/Virtex-6, и во всех случаях для всех сигналов использовал LVCMOS25, Drive=8,12, Slew=slow - так меньше звона стоит в линиях.

По какому фронту TX_CLK, изменяются TX_EN и TX_D<*> ? Через какие триггера выдаются TX_CLK, TX_EN, TX_D<*> ? (можно кусок кода привести – глядишь еще чего заметим) И что-то я запамятовал: Какую ПЛИС используете

Угу, а еще иногда полезно читать Xilinx Design Tools: Release Notes Guide раздел Compatible Third‐Party Tools. Например, ISE 13.x хотел ModelSim 6.6, а у меня был 6.5,.. 6.5 не компилировал библиотеки, пришлось перейти на 6.6.

Так это - того, тут же ошибка в кодировании: Попробуйте так: process(clk) begin if rising_edge(clk) then if updown = '0' then summ <= summ + "0001"; else -- updown = '1' summ <= summ - "0001"; end if; end if; end process; Почитайте более детально, что такое Rising_edge и 'Event.

Что-то я не могу припоминить, чтобы у меня были проблемы с MDIO от непрерывного тактирования... Другое дело, что MDIO интерфейс просыпается с заметной задержкой (вроде в милисекундах измерялась) от снятия Reset. А вот пока он не проснулся, то действительно будут читаться '1'.

1. А какие проблемы ? 2. Зачем конвертировать std_logic_vector в integer ? 3. Что Вам мешает "просто" сложить два std_logic_vector ? 4. Какие именно задержки Вы собрались уменьшать, проиллюстрируйте, пожалуйста, на картинках (можно на кривых, косых, от руки рисованных и отсканированных/сфотографированных) ? 5. Коли зашла речь о частоте, задержках, то хотя бы укажите семейство ПЛИС. P.S. И приведите код, который у Вас не синтезируется - так будет легче общаться.

Исключительно в описании на конкретный кристалл-"Ethernet контроллер". Там же можно обнаружить, что этот конкретный кристалл достаточно жёстко поддерживает спецификацию Ethernet, и нарушать её не собирается, хотя для отладочных целей кое-что можно и заблокировать. Но, что-то Вы хотите совсем нездоровое, и, я бы даже сказал, противоестественное. Поэтому лучше зайти с другой стороны: опишите задачу (и свои возможности), тогда, возможно, Вам подскажут, как её решить проще и дешевле.

Угу. Есть такое дело. Поэтому супостат и говорит: сначала подключайте головку программатора к Вашему устройству, а только потом через USB к PC.

Мы замеряли... правда на Virtex-5/6. Т.к. оно у нас горело по разным причинам, то и сопротивления были разные, от глухого 0 до где-то 3-4 Ом. Во входах обычно прогорали на к/з VCCO clamp diod'ы, так что можете еще и к VCCO прозвонить - может станет чуть яснее что и как сдохло.

Проверьте TMS и TDI, обычно такое из-за этих сигналов бывает. Есть, конечно, и более мерзкий вариант, хоть на него не сильно похоже, но всё равно изложу: у нас в Virtex-6 была конкуренция между 2 процессами загрузки JTAG и Master Select MAP: 1. JTAG посылал команду #Program. 2. ПЛИС сбрасывалась, и считывала состояние ножек M[2:0]. 3. согласно состоянию M[2:0] ПЛИС начинала грузиться с Platform Flash XL. 4. а тут, как раз, и JTAG созревал до загрузки. Вылечили добавлением перемычки на одну из M[2:0] ножек для выбора режима загрузки: JTAG / Master Select MAP.