Здравствуйте! Проблема такая. Есть проект в квартус 9,1 под Cyclone3. Проект простой.(Ядро ниос и небольшая логика). Есть два сигнала которые нужно выравнить. Для этого необходимо чтоб один из сигналов появился на выходе с небольшой задержкой(примерно 5-7 нс). Для этого использую элемент lcell (знаю что это не самый лучший способ, но все таки). Ставлю пару этих элементов - все работает и получается некоторая задержка... изменяю количество-сигнал вообще не генерится. Изменяю количество опять-работает. Возвращаю то же количество при которм сначала не работало-теперь уже работает. Никакой закономерности или логики отследить не могу. При всем при этом ядро и все остальное работает независимо от количества lcell. Пробовал вместо lcell ставить инверторы и элемент exp. Результат тот же самый... то работает то не работает. В чем может быть ошибка?

может синтезатор при оптимизации ваши lcell выкидвает? эти элементы посли implementation остаются?

Я в настройках отключил свойство ignore lcell... значит компилятор не может выкидывать их из проекта

Я бы поискал тактовую частоту 143-200 MHz, чтобы сделать строго синхронный дизайн и озаботился констрейнами.
Это единственный путь, известный мне, радикально снижающий количество иногда работающих схем.

немного не понятно, о чем ты?
причем тут тактовая частота?

Я о том, что сигнал, который вы пытаетесь задержать на 5-7 нс не нужно задерживать всякими шаманскими методами с нестабильным результатом.
Нужно подходящую тактовую частоту подать на регистр в выходной ножке, чтобы он выдавал сигнал вовремя прямо со своего выхода.
Если вы опишите задачу подробнее, то и решения будут качественнее.

PS: вопрос на понимание: по каким клокам и вообще как получаются сигналы, которые должны быть выравнены на выходе? С какой точностью?

Описываю проблему более подробно.
Имеется плата с двумя ПЛИС Cyclone III и двумя DDS AD9910. Первой DDS управляет первый циклон, а второй - второй :-) Нужно засинхронизировать эти DDS. Для этого у DDS имеется вход IO-UPDATE. Для синхронизации сигнал на эти ножки DDS должен дойти одновременно. IO_UPDATE служит для того, чтобы записать значения фазы, частоты, амплитуды и все другие данные в соответствующие регистры DDS. Т.е. если я поменял значение, например, частоты, то для того, чтобы DDS сгенерировал эту частоту нужно после записи данных через SPI в DDS, дернуть ножку IO-UPDATE. Но для синхронной работы обеих DDS нужно, чтоб этот сигнал дошел и до второй DDS. Т.к. каждая DDS связана с отдельной ПЛИС, то необходимо чтобы сигнал IO-UPDATE генерировался одной ПЛИС. Т.е. если нужно дернуть IO-UPDATE на DDS, то ПЛИС дергает на "свою" DDS напрямую, а вторую DDS - через вторую ПЛИС. Из-за этого и из-за того, что проводники на плате разной длины, сигнал IO-UPDATE доходит до каждой DDS с рассогласованием в 5 нс. Кроме того, сигнал IO-UPDATE дожен генериться синхронно с сигналом SYNC-CLK, который идет от DDS (с частотай 250MHz). Он заводится на ПЛИС (на вход Т-триггера inst15). Элемент ИЛИ нужен, чтоб строб-сигнал IO-UPDATE генерился как от одной ПЛИС, так и от второй. Но этот сигнал идет на обе DDS независимо от того, какая из ПЛИС его генерирует. Для того, чтобы сигнал IO-UPDATE доходил одновременно до обоих DDS пытаюсь сделать задержку с помощью LCELL. И тут начинаются непонятные глюки, описанные выше.

Есть вопросы: откуда клоки ходят и куда. какой клок питает логику в fpga ?
Откуда SYSCLK идет на DDS-ы ?

В общем, LCELL нужно исключить как возможный строительный материал.
Для выравнивания задержек только общий клок, PLL или изменение схемы.

DDS-ки и ПЛИС тактируются от одной опоры - термостабилизированный генератор.

Предлагаю сделать синхронный обмен между ПЛИС, чтобы они договаривались между собой что и когда слать, а потом независимо, но синхронно отправляли DDS-ам управляющие сигналы, прямо из регистров в выходных ножках. Интерфейс какой удобно, клок и данные туда, клок и данные сюда. Внутри синхронизаторы даже не нужны, если частота небольшая будет в интерфейсе.
Задержку можно будет корректировать настройкой PLL и я думаю, что это будет не 5-7ns, а меньше 1 ns.
Ошибка будет минимальной, если путь будет такой:
1) генератор
2) входная ножка fpga clock input
3) pll
4) глобальная сеть клока
5) выходная ножка
6) плата
7) dds

И все равно, такой способ синхронизации мне не нравится, так как PLL и сама FPGA будут шуметь.
Предусмотренный в DDS механизм синхронизации нескольких устройств может быть задействован на плате?

Здравствуйте
А если использовать Enable на DDS, есть ли там такой? И делать разрешение генерации чего то там , уже после того , как точно оба DDS запрограммируются.

Сообщение отредактировал Kirill_Good - Mar 20 2011, 05:46

IO_update и есть тот самый сигнал, который актуализирует новые значения.

Удерживать Enable на генерацию синуса в неактивном состоянии, и отпустить его одновременно на двух DDS, уверенно зная что данные через io_update загрузились.

Дело не в выборе сигнала, а в "одновременно", ведь если я правильно понял, DDS-ы подключены каждый к своей fpga.

я тоже понял, что проблема в "одновременно", чтобы сигналы которые генерируют два DDS были синхронны между собой, а сихронность их сбивается из за разности по времени прихода данных для конфигурации на ногу io_update, туда наверно приходят данные о фазе, амплитуде. После чего DDS начинает генерировать синус с новыми параметрами. вот я и предположил, что есть сигнал у DDS на разрешение генерации синуса, после update.