Beby

Что-то мне подсказывает, что для такого АЦП, jitter Spartan3 DLL просто убьёт всё измерение. И да, в этом случае о нём будет крайне уместно говорить ! Так я же про всё вместе говорил... если что. А т.к. в Virtex-4 нет PLL, а есть только аналогичной корявости DLL, то в худшем случае (т.е. нашем) jitter обоих DLL может складываться и составлять уже весьма заметную величину. Также, туда же в кучу необходимо накинуть будет статическое отклонение фазы, вызванное разбросами тех. параметров элементов Spartan-3 (да, эти разбросы наносят заметно больше вреда, чем jitter Spartan-3 DLL, но и jitter тоже имеет место быть). Думаю, что наверное, работать всё-таки будет, но без детального описания и расчетов гарантировать работу будет затруднительно.

Да, собственно говоря, наверное, никак не рассчитать этот ток*время - ибо такой подход, по сути не правильный - CPLD не рассчитывалась на такое жестокое обращение. Косвенно, можно прикинуть так: вы можете снять осциллограмму разряда конденсатора, из неё сможете оценить сопротивление транзистора в CPLD, потом посчитать выделяющуюся энергию на этом транзисторе. Далее, самое весёлое начинается: надо откуда-то добыть ненормируемый коэффициент теплопроводности в районе транзистора, через который бежит разрядный ток, и теперь можно будет прикинуть – прогреется ли этот транзистор до предельных/запредельных температур. Эти параметры немного не для транзистора даны... а для защитного диода. Но из них с ооочень большой натяжкой, можно выжать предельные значения того самого ненормированного коэффициент теплопроводности в районе транзистора. Поэтому поставьте внешний транзистор - вот на тот внешний транзистор Вы найдёте всю необходимую документацию, и, исходя из неё, всё рассчитаете и выберите. P.S. Ну что тут можно еще сказать (?): микроскопом тоже можно гвозди забивать,.. а вопрос о том, сколько гвоздей им можно забить в час, так, чтобы он окончательно не испортился, наверное, каким-то странным будет, а ?

Вот вам подходящий документик I/V Curves for Xilinx FPGA and CPLD FamiliesВыход из строя элементов (равно как и их преждевременное старение) происходит, преимущественно, от локального перегрева. Дальше прикидывайте сами... Но то, что Вы делаете - это жестокое насилие над CPLD. Если хотите сжечь CPLD - то да: 180mA в первый момент открытия транзистора - это как-то многовато !

Если мне не изменяет память, то в Spartan3 есть DLL, который может криво/коряво (с точки зрения jitter'а) заниматься компенсацией фазы. Даже если петля обратной связи не была предусмотрена, то, по идеи, её можно сделать на любой подходящей свободной ножке, использовав и OBUF, и IBUF оной. В этом случае схема более или менее нормальной компенсации может выглядеть следующим образом: IN_CLK -> IBUF -> BUFG* -> DLL.CLKIN IO_BF_CLK -> IBUF -> BUFG* -> DLL.CLKBF DLL.CLK0/DLL.CLK180 -> BUFG -> ODDR -> OBUF -> IO_BF_CLK DLL.CLK0/DLL.CLK180 -> BUFG -> ODDR -> OBUF -> OUT_V4_CLK * - Если возможно отказаться от этих BUFG, то от них обязательно необходимо отказаться (именно со Spartan3 не работал - поэтому не знаю надо ли их использовать в этом месте или нет) - чем меньше лишних элементов, тем значительно меньше jitter и отклонение фазы выходного clock'а относительно входного.

Т.к. телепаты после летних отпусков сразу впали в зимнюю спячку, то прийдётся задать ряд вопросов: 1. И главное: какая ПЛИС используется ? 2. С какой точностью необходимо обеспечить совпадение фронтов ? 3. Какая частота сигнала ? 4. Сколько и каких линий данных привязано к этому тактовому сигналу ? 5. На какой частоте передаются данные (т.е. есть там DDR/QDR и пр. заморочи) ? 6. Какая среда используется ?

Для начала Вам необходимо прочитать о constraint'ах (см. Constraint Guide) OFFSET, IOBDELAY и IOB. При помощи OFFSET IN можно задать необходимое соотношение между данными и clock'ом, а при компиляции среда сможет проверить выполняются ли эти соотношения или нет. IOBDELAY определяет использование элементов задержки в IOB. Именно для V-4 – не помню, но в ряде FPGA можно задерживать как Data, так и Clock. Кстати, обращаю Ваше внимание, иногда этот Delay втыкается автоматически (когда не нужен), поэтому его лучше всегда задавать вручную. Также помогает FPGA Editor, чтобы понять, какие ресурсы использованы и как расположены триггера (легли в IOB или нет - от этого очень сильно зависит времянка)... Constraint IOB задаёт: укладывать триггер в IOB или нет. Если не поможет, то тогда почитайте про DCM. Вроде как им можно покрутить фазу непрерывного clock'а.

Да вот только недавно была такая фигня. Мой случай: есть некое устройство (с ethernet'ом на борту) которое должно связываться с персональным компьютером. Нашелся такой хитрый компьютер, с котором передача от компьютера к устройству резко падает (раз эдак в 10-20 !). Выяснилось, что у этого хитрого компьютера (с индустриальной мамкой) есть заводской недостаток. Мост фирмы Intel (семейства Sandy Bridge), в котором находится встроенная сетевуха, питается от кварцевого генератора с сильно (по меркам Ethernet) завышенной частотой. Отклонение частоты в где-то 2000ppm для PCI-E - приемлемо... а для Ethernet – нет (а мамке встроенная сетевуха питается от PCI-E clock’а). При соединении точка-точка - всё работало нормально, т.к. встроенный Ethernet справлялся с таким отклонением частоты (даже при предельно плотном потоке длинных пакетов), а вот при проходе через switch большое количество пакетов от этой хитрой машины - терялось. При детальном исследовании выяснилось, что копирование файлов через TCP/IP с хитрой машины при работе через switch (а их мы перепробовали с пяток) тоже работает отвратно. Но вот ping (WinXP <-> WinXP) ходил без сбоев. Вот такой печалный опят - может чем поможет. P.S. Мы использовали 1000Base-T. Для эксперимента, на хитрой машине ставили принудительно 100Base-TX (а вдруг хоть на 100 Мбит начнёт нормально работать ?) - нет, не начала. Снижение быстродействия было таким же: 10-20 раз,.. но только теперь от 100 Мбит - что было совсем тоскливо. По прежнему, выпадал каждый 4-15 пакет – как повезёт.

Что-то как-то непонятно... PCI-E оно очень быстрое, а I2C SROM - очень медленное, да еще и с ограниченным количеством перезаписей. Соответственно, пока PCI-E успеет прокачать несколько пакетов, байт эдак по 128, I2C SROM вряд ли даже успеет один такой блок в себя записать... - так что его применимость для меня - загадка... однако, и проект не мой. Может проще сделать PCI-E Master, который будет худо-бедно (зато примитивно и ресурсоэкономично) наталкивать данные в ОЗУ машины ? Yx32 что-то хреново получается в Spartan-3. А вот 2048x64 можно реализовать на 7 RAM и 466 LUT (210 - на логику и 256 - на саму память) - итого: 6.5% LUT (7.1% SliceM) + 43.7% RAMB (осталось 9 RAMB).. 2048x128 можно реализовать на 14 RAM и 792 LUT (280 - на логику и 512 - на саму память) - итого: 11.0% LUT (14.2% SliceM) + 87.5% RAMB (осталось 2 RAMB). В обоих случаях прийдётся немного потратить логики на схему, которая будет производить запись в ОЗУ (собирать 2/4 группы по 32 в единую порцию 64/128 бит) и аналогично добавить дополнительный выходной мультиплексор. Оставшиеся RAMB и SliceM можно использовать в каких-либо более мелких местах - сдаётся мне они тоже должны быть. Для тех, кто хочет сам что-то ручками повертеть, прикинуть так и эдак: library IEEE; use IEEE.Std_Logic_1164.all; use IEEE.Std_Logic_unsigned.all; entity qwe is generic ( constant cnRAM_W: positive := 11 ); port ( WR_A: in std_logic_vector(cnRAM_W-1 downto 0); -- WR_D: in std_logic_vector(31 downto 0); -- WR_D: in std_logic_vector(63 downto 0); WR_D: in std_logic_vector(127 downto 0); WR_C: in std_logic; RD_A: in std_logic_vector(cnRAM_W-1 downto 0); -- RD_D: out std_logic_vector(31 downto 0); -- RD_D: out std_logic_vector(63 downto 0); RD_D: out std_logic_vector(127 downto 0); RD_C: in std_logic ); end entity; architecture Tushka of qwe is constant cnRAM_D: positive := 2**cnRAM_W; -- alias RAMB_WR_D: std_logic_vector(26 downto 0) is WR_D(26 downto 0); -- alias RAMD_WR_D: std_logic_vector(31 downto 27) is WR_D(31 downto 27); -- alias RAMB_WR_D: std_logic_vector(62 downto 0) is WR_D(62 downto 0); -- alias RAMD_WR_D: std_logic_vector(63 downto 63) is WR_D(63 downto 63); alias RAMB_WR_D: std_logic_vector(125 downto 0) is WR_D(125 downto 0); alias RAMD_WR_D: std_logic_vector(127 downto 126) is WR_D(127 downto 126); alias RAMB_RD_D: std_logic_vector(RAMB_WR_D'Range) is RD_D(RAMB_WR_D'Range); alias RAMD_RD_D: std_logic_vector(RAMD_WR_D'Range) is RD_D(RAMD_WR_D'Range); type taRAMB is array (0 to cnRAM_D-1) of std_logic_vector(RAMB_WR_D'Range); type taRAMD is array (0 to cnRAM_D-1) of std_logic_vector(RAMD_WR_D'Range); signal aRAMB: taRAMB; signal aRAMD: taRAMD; attribute RAM_Style: string; attribute RAM_Style of aRAMD: signal is "distributed"; begin process(WR_C) begin if rising_edge(WR_C) then aRAMB(conv_integer(WR_A)) <= RAMB_WR_D; aRAMD(conv_integer(WR_A)) <= RAMD_WR_D; end if; end process; process(RD_C) begin if rising_edge(RD_C) then RAMB_RD_D <= aRAMB(conv_integer(RD_A)); RAMD_RD_D <= aRAMD(conv_integer(RD_A)); end if; end process; end architecture; P.S. компилировал на ISE 10.1 SP3.

Хреново дело, может почти вся ПЛИС уйти на организацию ОЗУ... Очень хреново дело, т.к. 288K - это если все 9 бит задействовать в каждом блоке - а получается такое далеко не во всех случаях... в добавок, в Spartan-3 нет BUFT, которые могли бы неплохо помочь в этой ситуации... От «Сколько на сколько», очень много зависит - без этой информации я не смогу что-либо более конкретное посоветовать.

Можно, тут на выбор: либо городить кучу мультиплексоров (можно на логике быстрого переноса) - если частота большая; или можно воспользоваться BUFT, которые, пока еще есть в Spartan-2. Для более точных ответов необходимо знать: 1. какой именно кристалл Вы используете. 2. какой надо сделать массив ОЗУ (сколько на сколько). 3. частота, на которой это всё должно работать.

Когда не хватает документации, тем более по возможностям разводочного ресурса - тогда надо смотреть потроха ПЛИС при помощи FPGA Editor'а - он всё покажет, про всё расскажет... порой показывает даже то, что не описано в документации... Для ответа необходимо знать: 1. Точное название ПЛИС - без него, невозможно оценить наличие или отсутствие необходимого разводочного ресурса. 2. Цель: а зачем это надо - тогда можно будет сказать, что из ресурсов ПЛИС можно использовать, чтобы достичь цели (а может надо какую-нибудь переменную окружения задать). P.S. Если я правильно глянул (тем самым FPGA Editor'ом), то даже в самой маленькой Spartan-3E возможно задействовать оба DCM (DCM_X0Y0 - нижний и DCM_X0Y1 - верхний) от одного источника сигнала: чтобы сигнал смог дойти на оба входа более или менее синхронно, необходимо использовать BUFG.

Насколько я понимаю, основная причина (хоть и не афишируемая) весьма проста: чтобы не горели ПЛИС, когда буферы входят в конфликт, а в конфликт они будут входить обязательно, из-за асинхронной работы управляющих линий. Из опыта работы с I/O pin - при продолжительных конфликтах очень хорошо поганятся ножки ПЛИС. Согласен, что-нибудь можно было бы придумать (привинтить какие-нибудь ограничивающие резисторы на выходы или еще чего-нибудь), особенно, для "медленных" ПЛИС. Ведь частенько возникает желание на медленную шину навесить кучу медленных клиентов (нихай все они тормозят в одной куче) - вот тут как раз бы эти аля BUFT были бы в самый раз ! С другой стороны, если взять Sparnat-6 или Xilinx-7 семейства - то тут уже правит балом LUT6 - а на нём гораздо приятнее собирать мультиплексор, чем не LUT4. Кстати, за XST было подмечено, что он большие мультиплексоры делает аналогично Wired AND'ам (BUFT) - только на логике быстрого переноса (эдакое Wired OR получается). Возможно, в этом как раз и кроется настоящая причина отмирания пресловутых BUFT.

Так никто ж и не говорит, что BUFT (даже в виде Wired AND) - это плохо ! BUFT - это очень даже хорошо и удобно - надо только использовать с умом. Но с умом надо вообще всю ПЛИС использовать. В тоже время необходимо учитывать, что в FPGA значительно увеличились плотность, количество элементов и предельная рабочая частота. Т.к. в пределах семейства ПЛИС дешевле иметь однородную структуру и одну предельную рабочую частоту для всех элементов, то все технологические ограничения определяются самыми большими ПЛИС в семействе. А вот эти самые большие ПЛИС перешагнули ту черту, где возможно было эффективно создать BUFT элементы. Поэтому BUFT и покинули FPGA Xilinx.

Сам долго голову ломал: такая клёвая штука внутренний BUFT, и на тебе, в Spartan-3/3e/3a исчезли ! - а потом пришло и осознание, почему и зачем это всё исчезло: Вообще-то никаких BUFT и не было никогда... а был WAND (Wired AND). А если быть еще более точным, то была груда внутренних Open Drain элементов (гордо названных) BUFT, а с обоих концов кристалла (Spartan-2E или Virtex-E) были Pull-up резисторы. Обычно использовался только один Pull-up на группу "BUFT", соответственно, на одной горизонтальной группе long lines можно было организовать не более 2 груп "BUFT". Вот тут всё самое интересное и вылезло: оказывается если привесить много "BUFT" и, тем самым, сделать длинную линию, то скорость нарастания фронта получалась - отвратительной (слишком большая распределённая ёмкость, и слишком слабая подтяжка). Чтобы хоть как-то это компенсировать для Spartan-2E или Virtex-E был рождён специальный constraint Double, который принудительно заставлял использовать оба Pull-up (при этом использовалась вся горизонтальная группа long lines, вне зависимости от количества реально подключенных "BUFT"). Но даже при всех этих ухищрениях, временные параметры такой линии были слабыми и достаточно тяжело предсказуемыми. Поэтому, при росте размеров кристаллов (в CLB) пришлось отказаться от этих элементов. В виде компенсации мы получили бОльшее количество RAMB, значительно лучшие частотные параметры LUT и FF, аппаратные умножители, а в случае Virtex-4 и Spartan-3A DSP, еще и DSP блоки. P.S. На Spartan-2/2E и Virtex-E работал с BUFT на 33.(3) МГц (шина PCI) - проблем не было. Не-е-е, тут не в цене дело, Xilinx мотивировала отказ от внутренних BUFT, невозможностью их использования при "больших" частотах. Конкретную границу я там и не нашел, но вроде до 50 МГц еще можно было что-то сделать, а далее - уже проблематично. Поэтому, начина со Spartan-3 возникло разбиение Slice на SliceM (там, где LUT может быть RAM или Shift Register) и SliceL (в которых LUT - это только LUT). В современных ПЛИС Xilinx на один SliceM приходится где-то от 3 до 7 SliceL.

Поправлю: оби были в Virtex-2. Начиная с Virtex-4 / Spartan-3 внутренних BUTF не стало ! to SIA: А вместо MAX-II посмотрите на Spartan-3AN - он тоже имеет внутреннюю конфигурационную память - может он подойдёт лучше.

Неиспользуемые ноги нужно не описывать. Тогда они будут в Z состоянии. Вот потому, что ноги будут в Z состоянии, очень важно какое будет состояние у подтяжки. Z-состояние... - это конечно хорошо, но никто не отменял защитные диоды. Внимательно см. UG331 Spartan-3 Generation FPGA User Guide: SelectIO Signal Standards -> Overview of I/O Standards -> Clamp Diodes Да и вообще, было бы очень полезно прочесть полностью UG331 и UG332.

Тогда странно... Так, мелкое замечание: PROGB, PUDC_B, VS[2:0] имеют Dedicated pull-up resistors - которые от 5 кОм до 24 кОм... -> обычно, внешние резисторы - не нужны. Тут же возникает вопрос, а чем Вы делаете '0' на VS[1] (не подтягивающим ли резистором в 10 кОм) - и действительно ли там '0' ? И главное: а нужен ли там ‘0’ ? (я работал с VS[2:0] = 1-1-1 – работало хорошо). Какую Вы выставили частоту CCLK в BitGen для программирования ПЛИС ? (при VS[2:0] = 1-0-1 есть ограничение в 33 МГц). И совсем неприличные вопросы - а кз нету по DONE на землю (или не было ли кз (не сразу обнаруженного), которое могло спалить "верхний" транзистор в ноге DONE) ? Помогает ли удаление R=510 Ом с ноги Done ? P.S. Когда я прошивал Spartan-3AN-50 при помощи ISE 10.1SP3 и Xilinx USB Platform Cable (первый - чёрный), что не припоминаю, чтобы у меня писалось что-то подобное:

Хм... что же это за зверь такой... конфигуратор XSF16F... (сами придумали оный термин или надоумил кто ?) - может это Xilinx Configuration PROM XCF16P-FS48 ? 1. Есть зацикленное чтение Device ID - пробовали ? Если да, то на сколько стабильно считывается ? 2. А было ли опробовано снижение JTAG частоты до минимума ? 3. А пробовали ли Вы устроить стирание этой конфигурационной ПЗУхи и последующую проверку на пустоту ? Если эти наводки не помогли, то нужны более детальные сведенья: 1. А при помощи чего, собственно, программируете этот "конфигуратор" ? 2. Какие ПЛИС стоят в цепочке ? 3. Нужна схема, отражающая, как именно разведены линии JTAG'а в цепочке (а также информация о том, что и каким напряжением питается).

Нет, с лицензией всё в порядке, просто надо внимательно читать ISE Design Suite 11: Installation, Licensing, and Release Notes. Chapter 3: Operating Systems, Architecture Support, and System Requirements -> Architectures -> Device Obsolescence гласит, что: The following devices are not supported in ISE Design Suite 11: • Virtex • Virtex-E • Virtex-II • Virtex-II Pro • Spartan-II • Spartan-IIE • 9500XV All families, except 9500XV, are still being manufactured with no plans to discontinue. ISE Design Suite 10.1 SP3 is available for download to support the discontinued devices.

Несколько непонятно что именно и как должна делать FPGA. Но при любом раскладе, Spartan-3 уже не жилец - он снимается с производства (а может уже и снят, на сайте он уже находится в категории старья), поэтому я бы порекомендовал Spartan-3A(N) либо уже Spartan-6. Spartan-3AN может оказаться интереснее Spartan-6, из-за встроенной в Spartan-3AN Configuration SPI Flash ROM.

А чем Вас не устраивают LVDS Drivers & Receivers и им подобные микросхемы ?

Тут Product Discontinuation Notice For Spartan-IIE, Virtex-E, Virtex-EM, Virtex-II and EasyPath Virtex-II FPGA Products говорится о том, что последние заказы принимаются до 18 апреля 2012. Так что в долгосрочном плане необходимо чётко ответить на вопрос: "а оно такое старьё действительно необходимо ??!" или всё-таки надо продавить через военных другие микросхемы (может даже и не ногатые...). Есть ли штатный JTAG разъём для Virtex-E ? Изделия лаком уже залиты ? (т.е. можно ли припаять на ножки Virtex-E нештатный JTAG ?) Какой режим конфигурирования Virtex-E выбран ? Чем и как управляется нога program у Virtex-E ?

XCV100E в процессе снятия с производства, да и среды современные разработки их не поддерживают. Если есть возможность замените это всё на единственный Spartan-3AN. Буковка N говорит о встроенной SPI ROM, соответственно, ПЛИС сможет сама с неё загрузиться. В той же SPI ROM хватит места минимум на еще одну прошивку, или какие-либо данные пользователя. Посмотрите на XC3S50AN-4TQ144, если будет мало ног, то тогда XC3S200AN-4FT256. P.S. А зачем Вам загрузчик для такой древноты (Virtex-E) на такой ископаемости (XC9500) ?

Ответ на этот вопрос даёт Timing Analyzer (запущенный после P&R). Им можно поглядеть какие места в разведённом проекте оказались самыми тяжелыми, а также, сколько и на что именно будет затрачено времени в самых худших случаях. Естественно, достигнутая частота при разводке сильно зависит от той, которую просили в constraint'е.

Предлагаю повнимательней взглянуть на Spartan-3AN. Spartan-3AN - это FPGA (Spartan-3A) со встроенным SPI ROM. У Spartan-3A(N) есть ряд опций по проверке своей прошивки уже после окончания процесса конфигурации. Возможно, они как раз Вам и подойдут. Опции можно посмотреть в Spartan-3 Generation Configuration User Guide в разделе Chapter 16 Configuration CRC.