Genn

А зачем сразу проверять именно в "железе". Если проект нормально компилируется и выполняется физическая трансляция с порождением конфигурационного файла, что вам мещает выполнить моделирование временной (timesim) модели проекта с учётом задержек (sdf-файл). Если результат этого моделирования будет положительным, то с достаточно большой вероятностью этот проект заработает в "железе".

Я так понимаю, что проект вы ведете на VHDL или Verilog. В этом случае добавление элементов осуществляется средствами синтеза (те котрые вы используете из перечня XST, Sinplify, Pricision), компилирующими HDL код в список цепей. Для решения обозначенной проблемы обратитесь к документации на используемые средсва синтеза и поищите атрибут (фактически являющийся директивой при компиляции), который запрещает устанавливать тактовый буфер на конкретную цепь.

Если дружите с MathLab и ModelSIM рекомендую проверку по модели: 1. Формируете в MathLab тестовый сигнал с частотой дискретизации 600 кГц и записываете его в файл (например текстовый); 2. В тестовом окружении (testbench в VHDL или VERILOG) подключаете свой компонент фильтра и в качестве тестового воздействия подаете отсчеты сигнала сохраненные ранее в файле, а отклик регистрируете в другой файл; 3. Завершаете тест в ModelSI; 4. В пакете MathLab открываете файл отклика, сформированный в процессе моделирования, и выполняете спектральный анализ с помощью FFT. Проверку можно провести на разных частотах входного сигнала

Пакет ISE 10.1 последний, который поддерживает семейства Virtex, Virtex-E, Spartan-2, Spartan-2E. 11-я версия эти семейства уже не поддерживает.

Эта строка - всего лишь временное ограничение для транслятора, который будет просто стараться уложиться в определенный диапазон, а возможностью управлять задержками в IOB она не обладает. Найдите в каталоге XILINX файл "cgd.pdf" (очень полезный файл!) и просмотрите главу "Input Buffer Delay Value (IBUF_DELAY_VALUE)".

Прилагаю DataSheet Под таблицей "Absolute Maximum Ratings" есть примечание следующего содержания: 2. Maximum DC undershoot below GND must be limited to either 0.5V or 10 mA, whichever is easier to achieve. During transitions, the device pins may undershoot to –2.0 V or overshoot to +7.0V, provided this over- or undershoot lasts less than 10 ns and with the forcing current being limited to 200 mA. ds108_1.pdf

Обратите внимание на продукцию ОАО "МОРИОН" (http://morion.com.ru/rus/oscillators/), например модель ГК118-ТС для установки на плату. Требуемая частота получается путем умножения (с помощью дискретной логики) с последующей фильтрацией нужной гармоники, используя кварцевый фильтр. Получившийся сигнал остается привести в соответствие с требуемым уровнем. Вот и всё. Генератор будет, конечно, дороговат (порядка 10000 - 15000 руб), но результат будет положительным (не забываем про правильную организацию питания на плате). Вообще подобные генераторы отлично подходят на роль системных опорников, где от одного генератора запитываются несколько потребителей, а для одного потребителя его использование всё же несколько расточительно. Упоминание проблемы джиттера на частоте 100 МГц были бы уместно, если бы шло обсуждение формирования тактового сигнала для АЦП, а не для использования в обсуждаемом контексте. В нашем случае величина джиттера значительно меньше чем диапазон "setup...Hold" для триггеров внутри ПЛИС, а кроме того при разводке и проверке на выполнение временных ограничений, джиттер, порождаемый DCM и BUFG уже учтен в значениях "setup/hold".

Основное, что бросается в глаза - это используемый в схеме генератор тактового сигнала и путь, проходимый тактовым сигналом из АЦП к ПЛИС, регистрирующей отсчеты (Virtex 4). Если честно такое решение (прохождение тактового сигнала из АЦП) выглядит нелогичным ( должно быть АЦП - Virtex4 - Spartan3), но фатальным оно не является. Для стабильной повторяемости результатов разводки проектов для ПЛИС предлагаю следующий обратить внимание на следующие моменты: 1. Spartan3 1.1. Тактовый сигнал обязательно должен быть заведен на специальные контакты GCLK 1.2. Поскольку петли для выравнивания фазы с помощью DCM скорее всего нет, для стабильной повторяемости результатов трассировки тактовый сигнал на выходе Spartan3 рекомендую выполнить с использованием выходного DDR-регистра в IOB, и уже с выхода регистра сигнал будет поступать на выходные контакты. (К сведению: в Spartan3 для использования DDR - регистра придется подключать DCM для формирования сигналов clk0 и clk180, кстати здесь можно и поиграться с фазой тактового сигнала 0->(clk0,clk180), Pi/2->(clk90,clk270), Pi->(clk180,clk0), 3Pi/2->(clk270,clk90), где в скобках указано подключение тактовых к DDR-регистру ). 2. Virtex4 2.1. Тактовый сигнал обязательно должен быть заведен на специальные контакты (глобального или регионального тактового сигнала). Замечание: Если используются входы для регионального тактового сигнала, необходимо убедиться, что входные (данные из АЦП) контакты принадлежат одному из банков, имеющих подключение к контакту регионального тактового сигнала сигналу. 2.2. поскольку в промежуточной ПЛИС (Sprtan3) будет использована DCM, то для упрощения работы в Virtex4 желательно использовать просто глобальный буфер BUFG (при использовании DCM, а она будет 2-ой в цепочке, а поэтому, придется заниматься ее инициализацией). 2.3. еще раз повторюсь - обязательное использование входных регистров в блоках IOB для защелкивания данных из АЦП. Что касается используемого генератора GK-154. Подобные генераторы предназначены только для тактирования цифровых схем. Ожидать качественных характеристик от АЦП при его использовании не приходится: качество сигнала на его выходе как раз и может служить причиной той картины что представлена на 1-ом спектре (виден сигнал, 2-я гармоника, а наивысшая из ненужных палок - около -75 дБ, причем спектр не разваливается). Кстати, при понижении тактовой частоты какой генератор использовался? Конечно параметры и GK-154 можно улучшить: поставить на его выходе полосовой кварцевый фильтр, но относительная нестабильность этого генератора улучшена быть не может. Еще одной из причин появления подобных продуктов может быть непроработанная топология платы, отсутствие должной развязки по питанию между АЦП и другими функциональными узлами. При настройке рекомендую в качестве тактового генератора использовать внешний лабораторный (в качестве его можно не сомневаться, а заодно и исключите влияние GK-154 как непосредственно через тактовый сигнал, так и через питание).

Согласен, взглянуть бы на схему (достаточно функциональную) в части организации тактирования АЦП и ПЛИС и на спектр оцифрованного сигнала (какое значение SFDR получается?), потому как наличие спектральных составляющих, не относящихся к самому сигналу может быть вызвано некачественным тактовым сигналом на самом АЦП (либо по причине характеристик самого генератора, либо по причине каких-либо промахов в схемотехнике распределения тактовой частоты). Практически уверен, что ПЛИС здесь не причем (подбором настроек, указанных в ответе Boris_TS и выбором фронта вполне можно получить подходящие фазовые соотношения), если конечно отсчеты АЦП защелкиваются регистрами, расположенными в блоках IOB (обязательное условие стабильной работы). Есть ещё момент, который нужно иметь ввиду: Генераторы ВЧ - сигналов зачастую совместно с полезным сигналом на выходе имеют еще и гармоники этого сигнала, которые не являются признаком несоответствующей работы схемы.

Модули CompactPCI должны работать в системном блоке PXI, но для большей уверенности в этом я бы порекомендовал пообщаться с представительством "National Instruments" в России (скорее всего к системному блоку PXI, используемому Вами, эта компания имеет прямое отношение), где можно получить достаточно квалифицированные ответы.

Хочу обратить внимание на то, что указанный эффект увеличения эквивалентной разрядности при децимации оцифрованного на более высокой тактовой частоте связан с тем, что энергия шума на входе АЦП распределяется в более широкой полосе в соответствии с тактовой частотой АЦП. При децимации вместе с уменьшением тактовой частоты выполняется фильтрация (ФНЧ) и, таким образом, на выходе дециматора энергия шума уменьшается пропорционально снижению тактовой частоты (при вычислении спектра шумовая дорожка опускается). Однако уровень помех, присутствующих в полосе пропускания дециматора измениться не может. Использование фильтра скользящего среднего (CIC) действительно позволяет сэкономить вычислительные ресурсы, но требует последующей обработки КИХ-звеном. В качестве примера реализации децимирующего фильтра рекомендую посмотреть архитектуру микросхем AD6620, AD6624.

sanek78 пишет про период в 100 нс, а у Вас цифра - 100 мкс. Извиняюсь. В самом деле длительность сигнала внутреннего сигнала GSR 100 нс (так генерит по умолчанию модель ISE). Компонент "X_ROC" всегда находится в самом конце VHDL-описания модели. Ниже привожу фрагмент VHDL-модели: NlwBlockROC : X_ROC generic map (ROC_WIDTH => 100 ns) port map (O => GSR); NlwBlockTOC : X_TOC port map (O => GTS);

Похоже я сталкивался с этой же проблемой. 1. При создании Post-Route vhdl-модели (совместно с файлом *.sdf) ISE обязательно включает в состав этой модели внутренние (!!! для этой модели) сигналы глобального сброса GSR и сигнал управления Z-состоянием GTS (эти сигналы можно найти просматривая файл Post-Route vhdl-модели). Эти сгналы используются для инициализации тестируемого модуля (после "включения питания" все триггеры должны иметь начальное состояние). 2. Post-Route vhdl-модель содержит компонент, управляющий этими сигналами (компонент "X_ROC"), который формирует сигнал RST длительностью 100 мкс (по умолчанию). Т.о. в течение этих 100 мкс триггеры модуля не могут изменять свое начальное состояние. Это можно проверить, если вывести в окно временной диаграммы сигнал "<test>/uut/GSR": сигнал сразу взводится в "1" и удерживается в таком состоянии 100 мкс, после чего переводится в "0". Рекомендую учесть эту особенность при формировании тестовых воздействий, т.е. оттянуть первые тестовые воздействия, например, на 150 мкс. Надеюсь, что это Вам поможет.

Хотя уже года 4 я работаю только с VHDL, могу сказать что у Вас в коде логическая ошибка: в списке чувствительности процессов могут быть только те сигналы, которые используются внутри процесса. Есть 2 варианта решения этой проблемы: 1. с использованием процесса (конструкция "always"); 2. без использования процесса. ВАРИАНТ 1: reg is_done; wire GND; wire done; assign done=is_done; assign GND='b0; always @ (GND) begin is_done=GND; end ВАРИАНТ 2: wire is_done; wire done; assign done=is_done; assign is_done='b0;

Если Вы используете ПЛИС с поддержкой DDR в IOB-блоках (Virtex-II, Spartan-3...), то получить синфазные тактовые сигналы проще простого: 1. Используя DCM получаете "clk0" и "clk180" (необходимой частоты) 2. Инстсаллируете компонент "FDDRRSE" (подаете тактовые сигналы, а на входы данных - соответственно "0" и "1"). Никакой удвоенной частоты для этого не требуется. Этот метод подробно описан в "USER GUIDE" для Virtex-II.