Victor

Небольшое дополнение по Virtex 5 - будьте внимательны! Не во всех банках есть Bufr, в "центральных" нет. По поводу учета задержки тоже небольшое имхо - при наличии OFFSET IN - её будет учитывать любой ISE, но DCM/PLL по умолчанию корректирует так, как если бы тактовая была подключена к "клоковому" входу. Остальное надо допиливать вручную (задавая фазу DCM). Ну и действительно, для АЦП - лучшего решения, чем bufr/bufio - не придумали ) P.S. BorisTS, respect! P.P.S. Думаю автору не нужна точность до градуса ;) (если мои телепатические возможности не подводят, и 50МГц DDR с АЦП - это правда :) )

Пытался в 10.4, 12.3... может в 12.4 поправили что-то... попробую завтра :)

Это как-то много, давайте всё-таки однобитные попробуем :) у меня упорно получается 2 лута :(

Кое где Xilinx пишет, о том, что при использовании кристаллов с LUT6, можно получить Performance Advantages в виде компрессии сумматора трех переменных (документы типа Xilinx WP309 Targeting and Retargeting Guide for Spartan-6 FPGAs, ключевое слово ternary). В других приличных документах (xst.pdf, XST user guide) такая конструкция не встречается, и синтезатор не сжимает трехвходовый сумматор описанный как assign result = a + b + c; в один LUT6, (a,b,c - однобитные, result - 2 бита). Вместо этого получаются два сумматора на 2-х LUT2. Внимание, вопрос: Может быть у кого-то получилось написать так, чтобы xst самостоятельно сжал сумматор? Подскажите, пожалуйста, как :) З.Ы. Описать примитивами или логической функцией не предлагайте, понятно, что так можно. Хочется именно inference.

У jtag.com появилась бесплатная приблуда чтобы вручную "подергать" ногами. JtagLive называется. Может юзать стандартный кабель. Там есть какой-то дополнительный модуль, который позволяет на питоне писать скрипты управления пинами (за деньги, но немного вроде...)

Можно вручную вставить BSCAN, и вручную написать ПО для "передачи" данных туда через JTAG интерфейс. Если железка подключена к компу и есть драйвер, то, возможно, проще написать пару модулей. Если интерфейса кроме JTAG нет, то вручную.

Тогда чипскоп вам в руки :) Есть замечательное ядро - VIO :) пожно прямо руками потыкать что и куда нужно, синхронные сигналы не только руками - до 16 тактов последовательность задается.

Если вас не пугает "повисший" последний бит, то можете и локальный клок использовать. Цепочка такая: Clock capable pin (или дифф пара, которая приходит на CC-pin) -> IBUFDS -> BUFIO -> -> только IDDR. с того же IBUFDS берем и на BUFR: Clock capable pin (или дифф пара, которая приходит на CC-pin) -> IBUFDS -> BUFR -> -> логика съема данных с IDDR и десериалайзера. если клок введен не на Clock capable, то BUFIO и BUFR использовать не получится.

Вообще в таких ситуациях, когда тактовая есть только в момент передачи регистр (как этого не хотелось бы) на входе не поставить без дополнительного "геморроя" по вычитке из него последнего значения. Поэтому берем DPRAM на 32 или 64 бита (на SRL16) и не паримся. Такое решение предлагает и Xilinx. Т.о. на входе имеется 2 dpram (по одной на фронт), на выходе из нее на системной спокойно вычитываем и отпускаем ACK. Можно не на системной, если она меньше линковой тактовой, а на некой промежуточной, а потом десериалайзер.

Вот у вас, как вы говорите, все вручную. А примитив в IOB не положен. Если вдруг потеснее в кристалле станет, настройки синтезатора забудете поставить, чтобы в IOB регистры входные-выходные складывал, ну или настройка по умолчанию изменится в следующей версии ;) сдвинется вами вручную положенный примитив в сторону на пол-кристалла, и получите дополнительно пару нан... А если описать времянки, то синтезатор/PAR будет _обязан_ это учитывать. А если уж очень хочется вручную, тогда добавьте атрибут IOB = TRUE ну или в конце концов не FDDRRSE, а OFDDRRSE вставлять. Еще IOBDELAY надо не забыть, Его тоже синтезатор может сам подергать, а это как-никак около 3 нс... При STA по умолчанию подразумеваются самые худшие условия по температуре и напряжению питания. Очень рекомендую OFFSET посмотреть... Полезно.

В этом вы не правы... Их очень нужно описывать, иначе можно даже и не узнать, что не выполнены спецификации... Причем, как на вход, так и на выход. Внутри, обычно, достаточно описания тактовой. _Но_ если все синхронно и синтезатор/PAR "все" понимают. ЗЫ: Да, согласен с предыдущим оратором, если все однотактово, конечно.

Так это все таки был Clock1 или что-то другое? А проблемы остались? Еще можно пристально посмотреть на (spi_to_epc/Write)... он там ничем "нужным" не управляет?

Я бы посоветовал устранить подобные тактовые сигналы, где это возможно. Есть ли такие в проблемных модулях?

Синтезатор правильно видит здесь какой-то клок. Это как раз та конструкция которую я вам приводил в первом посте. Вы под одним клоком формируете сигнал (имеется ввиду строб Clock1), который подается на вход тактовой другого регистра (имеются ввиду Second,Microsecond ). Вот собственно и источник надписи в отчете синтезатора. :) Предполагая, что строб Clock1 сформирован под тактовой SysWrite я бы предложил сделать так: always @(posedge SysWrite ...) ... if ((Load == 1'b1) && (Clock1 == 1'b1) && ... ) Second[31:0]<=LoadSecond[31:0]; ... Тогда многоуважаемый синтезатор будет "понимать", что от изменения Clock1 до его "использования" один такт SysWrite. А сейчас этого "не видно".

Теперь ясно, что по вход :) Да, именно так. Просто примитив IBUF - на обычных пинах, а IBUFG на специальных. Т.е. в вашем случае - IBUF -> BUFG -> всё остальное. В случае если клок подведен на специальный вход: IBUFG -> BUFG -> всё остальное.

Да, я поправил, не в этом суть моего поста. А откуда берется 1 Mhz pulse? (Clock1 то есть)

Меня очень смущают такие конструкции: (continuous assignment) always @(posedge SysWrite or negedge Reset) begin LoadSecond[31:0]=SysDin[31:0]; end Я бы рекомендовал писать (procedural assignment) always @(posedge SysWrite or negedge Reset) begin LoadSecond[31:0]<=SysDin[31:0]; end

OFF: я обычно пользуюсь (* IOB = "TRUE" *) перед регистром, который нужно в IOB положить :) А проблема с внешними шинами или внутренними? Если с внешними, то их нужно OFFSET IN'ить с одной стороны и OFFSET OUT'ить с другой. Иначе действительно от разводки к разводке результат "пляшет", особенно когда времянки подзажаты... Посмотрите здесь и в Constraints guide в PDF Bookcase в ISE. С внутренними - должно хватать PERIOD... Действительно смущает (*) These 10 clock signal(s) are generated by combinatorial logic... Такое обычно случается, если есть что-то типа reg reg1, reg2; always @(posedge CLK) begin reg1 <= something; end always @(posedge reg1) begin reg2 <= something2 end тогда reg1 будет подан на вход тактовой reg2 и выведен ISE в качестве "неопознанного" клока в отчет. Я лично стараюсь так не делать, тогда в отчете нет лишнего. Возможно бывают ситуации когда так проще - но пока удавалось избегать :)

Точно не знаю как в Спартане 2, это про Виртексы. Но должно быть похоже ;) Если кратко - выводить можно куда хочется. Только для этого не нужно BUFG вставлять. Схема обычно такая: Входной пин(специальный клоковый) -> IBUFG (IBUFGDS) -> BUFG ( или DCM -> BUFG ) -> Логика и выходы. У вас же, видимо, на _выходе_ стоит примитив IBUFG, который на выходе стоять не должен. Вводить на этот BUFG можно и с внутренних линий, но тогда не гарантируется фаза полученной тактовой относительно исходной.

Однозначно нужны данные о загрузке кристалла. Используемая логика, ff-ы, умножители, память, dcm-ы и т.д. и на какой тактовой это все работает. У меня совпадение с xilinx power estimator было очень точное. Заметно влияет DCI. Вообще крупные кристаллы могут реально выжирать около 6-10А только по ядру.

Может немного не в тему - иногда в симуляторе _очень_ долго получается. Особенно если тестируется что-то длинное с обратными связями. Проще получается откомпилить целиком проект и завести сигнал, чем симулировать те же полдня, а потом выяснить что воздействие не то. Но отмечу, что такая ситуация возникает обычно на этапе "сборки" проекта целиком, а не тестирования отдельных модулей... Мне, например, тоже приходила в голову мысль так использовать чипскоп, но до реализации все руки не доходят :(. Хотя, AFAIK, по BS-цепочке получится не очень быстро, если надо симулировать _всю_ периферию + разные тактовые и пр... все-таки синхронно там все и медленно. А вот одну шину, мне кажется, можно и нужно :)

Я звонил скайпом, не так и дорого :) Цены задевал куда-то... не нашел. Порядок цен похож на Jtag.com, у которых "представительство" в Питере есть - можно по русски пообщаться. У jtag-а основная софтина стоит около 25 евро + от 5 до 20 евро за аддоны, еще железяка от не помню скольки за маленькую и медленную до 12 евро за быструю и большую. У ассета насколько понимаю цены надо умножить на 1,5 - 2 - 3. ага, но даже у "дешевых" решений цена не очень маленькая, так что подумать можно...

В Corelis я просто позвонил, мне ответили и прислали предложение. С Asset не связывался, потому как пообщавшись с Леонидом Куриланом понял, что цены не очень вкусные.

Раньше пользовались 6.3.0х. Пока из относительно новых версий рабочей была признана 8.2.03, 9.2.03 не собирает некоторые проекты без кувалды и гайковерта... 9.1.0х вообще иногда сворачивалась при синтезе... Времени разбираться не было и нет, поэтому пока живем на 8.2.

Так он вроде сам и отслеживает - при открытии проекта изменившееся перекомпилирует... Только как-то встречал глюк, что мсим "не увидел", что файл изменился и не перекомпилировал - с тех пор ручками удаляю папку work, просто на всякий случай ;-)