Beby

Один из перечисленных сигналов TS_mod_dcm_CLK2X_BUF_14 или TS_MOD_CLK находиться до BUFGMX, второй - после. Естественно, анализировать оба сигнала бессмысленно, ибо они практически одно и тоже (с разницей в задержке в BUFGMX) Посмотрите FPGA Editor'ом где и как расположились эти линии. Затем руками вставьте BUFGMX и дайте человеческое имя линии с той стороны этого буфера, с которой сейчас находиться линия TS_mod_dcm_CLK2X_BUF_14.

ISE никакой отсебятины не добавляет. Если может затолкать триггеры в IOB, то заталкивает. Если ей что-то помешает запихнуть триггер в IOB, то может выдать предупреждение вида: "вот если бы не то-то, то этот триггер прекрасно бы залез в IOB". Рекомендую поглядывать FPGA Editor'ом на получившийся результат. И если чего не запихнулось в IOB - анализировать причины. Ну а чтобы у меня не было каких-либо проблем, то я еще в и HDL описании вставляют все на интересующие меня регистры (триггеры) атрибут IOB=true.

Заранее извиняюсь, если не в тему... Не даром же появился термин за бугром know how - типа знаю как и никому не скажу, и даже патентовать не буду, дабы конкурент не понял ход моих мыслей (а главное - моего уровня развития). Наиболее действенным способом получения денег от производства (на мой взгляд) является зажимание истинных прошивок ПЛИС, и продажа запрограммированных ПЛИС (как готовых уникальных изделий) для пайки на плату. Я знаю пару крупных Российских фирм, которые перешли на такой способ работы с заводами, и перестали мучиться головной болью: а не сделает ли завод что-то налево без мзды разработчику. Насколько мне известно, запрограммированные CPLD благополучно переживают пайку. В FPGA Xilinx (если ничего не путаю, то это все Spartan-3x и Virtex, начиная со второго) есть небольшая область памяти для хранения ключа, которым будет расшифровываться загружаемая прошивка - как раз для целей зашиты разработчика от несанкционированного производства. Ну а Spartan-3AN имеет вообще встроенную Flash ROM. Если бы дело с патентами обстояло хорошо, вряд ли бы супостат стал добавлять подобные добавки во все «новые» ПЛИС. А касательно Вашей проблемы с патентом, поддерживаю версию о проведении экспертизы (знать бы еще кто бы её смог провести) и далее, если завод не захочет по хорошему договориться - в суд. Также (теоретически) есть возможность закричать: "АААаа !!!! Найдена смертоносная ошибка в прошивке ПЛИС !!!!" и необходимо поправить прошивочку... ну и исправить ошибку: внести в прошивочку необходимость быть расшифрованной ключиком..... и потом продовать заводу FPGA с зашитым в них ключом.

При старте у ПЛИС все выходы подтягиваются к питанию (внутренними pullup), поэтому для того, чтобы до начала конфигурации был устойчивый '0', Вам понадобится добавить внешнюю подтяжку к земле (уверенно перетягивающую внутренний pullup). Если я не ошибаюсь, для S3E есть настройки на поведение ног на время программирования, но проблема в том, что до начала загрузки прошивки все равно остается подтяжка к '1'.

А можно поточнее где и какой именно Spartan повторили.

А что именно хотите исследовать ? Если Вы собираетесь изучать сами схемы (т.е. задержки в буферрах вводы/вывода Вас не волнуют, равно как и задержки в линиях связи от/до io pin до/от исследуемой схемы), то рекомендую поставить на вход и выход исследуемой схемы триггеры - и исследовать максимально возможную рабочуу частоту схемы.

Я использую конструкция просто регистр + счетчик, в такой задаче: есть некий подвижный объект, он перемещается с какой-то скоростью, необходимо генерировать импульсы (для запуска чего-то) через равные промежутки расстояния, скорость конечно же меняется... При моих физических ограничениях на возможные ускорения объекта (и !!! заданной минимальной частоты дискретизации) вполне достаточно досчета счетчика по старому значению и по переполнению загрузки нового. Я вот у Вас как-то до конца не разобрал этот момент... А вот наверное третий вариант... Но если Вам необходимо работать так: 1. Если новое значение меньше предыдущего (понижаем частоту) - то можно, чтобы счетчик досчитал до переноса. 2. Если новое значение больше предыдущего (повышаем частоту) - то необходимо, чтобы счетчик с момента обновления считал не дольше нового (свежезаданного периода ожидания). То тогда Вы можете откровенно поставить рядышком вычитатель, который будет сравнивать код в счетчике с находящемся в регистре (в т.ч. и всежезаписанным), и если счетчику считать дольше, то перезаписывать в него новое начальное значение. Надеюсь не слишком мутно объяснил

Как я понимаю, у Вас получается регистр (хранящий код, с которого начинает считать счетчик) и непосредственно сам счетчик. Если это так, то счетчик можно доукомплектовать входом предустановки (во все единицы). Тогда на следующем после предустановки такте, счетчик загрузит новое значение. Если я правильно понял Вашу проблему, то это Вам должно подойти.

Это мультиплексор, может пропускать сигнел без инверсии, а может и проинвертироват. Т.к. снизу к нему не подходит управляющий сигнал, то управление задается на стадии конфигурирования.

Использую AHDL7.3 (без SP1). Такаяже ошибка. До этого работал с AHDL 7.1 поблем не было. Как решить эту троблему - не знаю, но т.к. я со схемным вводом не работаю, то и не сильно-то и мешает...

Для modelsim пользы не будет, т.к. ModelSim поддерживает 64 битность только на Solaris 64-bit и Linux 64-bit.

Залазеете сюды http://support.aldec.com/UpdateCenter/Default.asp, и тут задаете: AHDL8.1 Library Xilinx ISE (а можно еще и EDK) версию Xilinx, которую Вы используете (и поленились указать)... Но для ISE 10.1 удалось найти только для SP3 VHDL и Verilog библиотеки.

Укажыте пожалуйста поточнее с каким кристалом этот эффект у Вас наблюдался. А то какой-то уж очень мерзкий слючай Вы описали - народ должен знать корявые кристалы в "лицо" !

А почему не Spartan-3A ? Вы не указали какой выходной стандарт вы будете использовать... и если Вы планируете использовать DVI, то полагаю, что Spartan-3A может оказаться более подходящим, т.к. его IOBUF поддерживает TMDS (используемый в DVI).

Может лучше тогда использовать CoolRunner II - он и меньше жрет (если я не ошибаюсь) и дешевле, чем XPLA3 (точнее XPLA3 дороже, чем CoolRunner II - дабы последний лучше продавался) + к нему что-то вроде Philips 74AHCT24x (отказавшись от резисторов подтяжки к 5В Вы снизите энергопотребление). Рассмотрите этот вариант... Сам использую 74AHCT244 / 74AHCT245 для преобразования LVTTL/LVCMOS 3.3 -> CMOS (5V). Второй и очень важный момент: в большинстве случает достаточно и 3.3В, чтобы устойчиво работали входы TTL (5В). Т.к. Вы не указали на кокой именно 5В стандарт Вы работаете, то приходится строить различные версии.

Очень хорошо, что вы приложили исходник (схему). Ошибка такая - в XPLA3 нет варианта конфигурации выхода - OpenDrain. В пределах одного FunctionalBlock может быть только 4 ControlTerm использовано для управления выходами с тремя состояниями. Еще может быть использован Universal Control Term 2 (всего один на ПЛИС) выход которого может подойти к входам управления BUFT в любом FunctionalBlock. Я насчитал 17 различных управлений для BUFT - теоретически это можно разместить в XCR3064XL. Вам потребуется ручное расположение ножек. Можете попробовать уменьшить количество различных управлений входами T у BUFT. Есть еще два радикальных варианта – перейти на аналогичную Alter’ку или на CoolRunner II – в обоих вариантах есть возможность сконфигурировать выход, как OpenDrain.

Использую ActiveHDL -> ISE -> ModelSim. Раньше моделировал в ActiveHDL, но когда потребовалось промоделировать совместно работу нескольких PostPAR проектов (c sdf описаниями конечно), я не смог это сделать в ActiveHDL. А вот в ModelSim удалось. Была одна заморочка с ActiveHDL и ModelSim: обе эти программы в PATH включают свои пути... и может так случиться, что ModelSim запускает exe'шники у AHDL вместо своих - вылечил это удалением из PATH пути к AHDL, побочный эффектов не обнаружил.

Я имел ввиду именно IBUF/OBUF, а не IOB целиком: Если верить таблицам 10-10: Available Single-Ended I/O Standards и 10-11: Available Differential I/O Standards из UG331 "Spartan-3 Generation FPGA User Guide", то получается, что Spartan-3A банками 1 и 3 может давать больше току по Single-Ended I/O Standards. И еще поддерживает TMDS, PPDS... + К тому еще и поддерживается RSDS, LVDS, MINILVDS - все это для 3.3V и входы LVPECL для 2.5 и 3.3V. Остальную разницу по поддерживаемым стандартам передачи данных перечислять не буду. Да и вроде как входной задержкой можно управлять из проекта, а не на стадии конфигурации, как в Spartan-3E... правда пока не пользовал - за ненадобностью. Встроенная DIFF_TERM приблизилась к 100 Ом - для меня это удобнее, чем в S-3E (120 Ом) - легче придерживаться требованиям дифференциальных стандартов делать всю линию передачи 100 Ом.

-Spartan/XL - под него последняя среда Xilinx Foundation 4.x (еще не ISE) - забудьте как страшный сон. -Spartan-2/2E - отмирают... но Spartan-2 имеет 5V толерантность, а Spartan-2E может работать в аля LVPECL 3.3В. Больше пожалуй в Spartan-2/2E ничего интересного нет. -Spartan-3A - имеет более навороченные I/O буфера, чем Spartan-3E. Также есть версия с внутренней Flash ROM - Spartan-3AN. Думаю именно она может оказаться наиболее интересной. -Spartan-3E - тоже может подойти. В остальном присоединяюсь к совету makc'а.

Насколько я понял Вы пытаетесь посмотреть сигнал именно на IO PIN - в явном виде это невозможно, т.к. этот inout сигнал находиться МЕЖДУ OBUFT и IBUF. Вам надо дорисовать ручками IBUF (если Вы этого еще не сделали) и смотреть сигнал на его выходе.

ПЛИС'а - она конечно "умная" но не настолько, чтобы самой понимать: где заголовок, а где нет. Конфигурационная последовательность начинается со слов синхронизвции, вот после получения этих слов и начинается обработка команд в BitStream. Но кто гарантирует, что в заголовке (случайно) не сложатся байтики в эти самые "словеса синхронизации" ??? Поэму, во избежания проблем конфигурирования, Xilinx предлагает для непосредственной загрузки "чистый" BitStream, записываемый в *.bin файл.

Правильно, только нужный файл прошивки. Теоретически еще надо добавить около 8 CCLK для процедуры Startup (по умолчанию DONE появляется на 4 CCLK при Startup), но обычно в конце файла прошивки есть "данные" (пустышки), при передачи которых и происходит Startup (если Вы Startup не перевели на USER Clock - опции BitGen) Да использовать надо *.bin. Bit - это заголовок (формат которого можно найти в одной из тем этой конференции, если чего могу выложить заново) + содержимое bin файла. Да где-то так и надо делать (иногда работает и без задержки в 100 мкс). ПЛИС фиксирует данные (DIN) по rising edge CCLK. Есть еще одни саперские грабли на которые периодически наступают: у последней загружаемой в цепочке ПЛИС в опциях BitGen надо поставить Done_Drive_High. У вас, я так понял, ПЛИС в цепочке единственная - проверьте наличие этой галочки.

Для аналогичной цели (только на VHDL и для силуляции), я использую keep - попробуйте - а вдруг поможет ? Ну а применение к Virilog XST вы найдете в %Xilinx%\doc\usenglish\books\docs\cgd\cgd.pdf

Ну, как я понимаю, задача сформулирована так: неудается использовать dedicated clk pin. И сейчас ветка 'CLK' идет от обычного IBUFDS к DCM, вот и вопрос, как бы скомпенсировать эту непредвиденную задержку... А DCM'ичиков вроде хватает... Просто так разведена плата. Я думаю, что если сейчас от IBUFGS до DCM трасса проходит через 2 local lines, то можно оттащить в ветке 'Data' первый триггер от своего IBUFDS так, чтобы путь к нему занимал 2 local lines. Если надо больше Local lines, то уже могут понадобиться прыжки с бубном. Если IBUFDS и обоих веток находятся "недалеко" друг от друга, то и термокомпенсация будет не плоха...Хотя опять таки повторюсь с чего начал: "это очень корявый вариант".

Есть очень корявый путь: вручную назначить LOC для первого элемента, на который приходят данные с IBUFDS по ветке 'Data'. Так, чтобы задержки линий 'Data' и 'CLK' (от IBUFDS до DCM) были очень близкими - это позволит сделать менее температурнозависимой компенсацию...