DmitryR

Я бы скорее поставил на то, что вы пишете что-то не то или не туда, в результате чего PLL теряет работоспособность и обратно залочится уже не может.

Так после того, как PLL перенастроена, она вроде перестаёт что-либо генерировать. Её надо сбросить и дождаться, пока она залочится с новыми параметрами, или я не прав?

Это несомненно возможно, только мне не это надо. Надо, чтобы это зависело от parameter. А в верилоге условная компиляци работает только от define (ifdef/ifndef), параметр как аргумент эти директивы принимать не могут.

Я в итоге к этому решению и склоняюсь, но оно имеет массу недостатков: код получается совсем не такой уж и компактный, плюс непереносимость на другую архитектуру. Мы это переживём, так как работаем только с Альтерой, но чувство прекрасного это ранит.

Спасибо, мне это всё понятно. Но define - это устаревшая конструкция, а использование generate в данном случе приводит к удвоению объёма кода. Возьмите хотя бы SPI - там в зависимости от параметров CPHA и CPOL меняются фронты, по которым происходят захват и выдача данных. Другое дело, что в реальных реализациях клок там чаще всего так или иначе эмулируется, но с точки зрения теории это уже детали.

Пробовал, но это не важно, так как я хочу написать универсальный библиотечный код, который будет гарантированно правильно компилироваться везде. Никак, но этого и не требуется. Вы не поняли вопрос.

Почему все всегда подозревают в людях худшее, да ещё и хамят при этом? Я совершенно не собираюсь менять клок "на лету" (в данном случае), а хочу настраивать его константой времени компиляции. Проблема в том, что если я напишу wire real_clk = a ? clk:!clk; то скорее всего получу на самом деле инвертированный клок со всеми сопутствующими прелестями (в смысле инвертированный именно инвертором, на логике), а вовсе не переход на обратный фронт. И вот это уже совершенно нехорошо.

С этого постулата хорошо начинать учить людей основам цифрового дизайна, однако в общем случае он не верен. Если бы это было так - то в верилоге не появилось бы слово negedge, а в ПЛИС не появилось бы не то что DDR-триггеров - не стали бы делать даже поддержки negedge (потому что это стоит ресурсов, которые в ПЛИС по сей день не дёшевы). Однако вариантов, когда надо использовать задний фронт, в реальной жизни масса.

Решил я оптимизировать один простой контроллер, чтобы был кратким (как выстрел, ЛОЛ) и полностью конфигурируемым. В частности чтобы можно было ему задавать фронт, по которому работать. Ну и пишу: clocking get_edge @((posedge clk iff a) or (negedge clk iff !a)); И сразу же выясняется, что ни clocking, ни даже iff синтезатором (Квартус) не поддерживаются. У кого-нибудь есть идеи, как это сделать элегантно с помощью синтезируемых конструкций? Я понимаю, как это сделать с помощью условной компиляции, но это мне кажется как-то... Не совсем современно, что ли.

У меня там NIOS, и к нему есть библиотеки. Если вы хотите сделать иначе - то думаю, что самым быстрым способом будет изучить код этих библиотек. Там не очень много.

Я честно говоря даже мануал не читал, а просто пристегнул библиотечные функции. Они работают.

Так на самом деле может работать при каскадировании счётчиков (ранее я думал, что в Cyclone IV это ещё не поддреживается). Однако повторю, у меня визард при вводе параметров, которые вы хотите получить делает неправильную конфигурацию. Проверьте, что все параметры PLL, в первую очередь частота VCO, конфигурируется им правильно. А вот если у вас и на обычных настройках не работает - тогда остаётся только сравнивать тактовые сигналы.

Не вижу какая вам разница, просто там всё или нет. Факт, что так, как вы делаете, работать не будет.

Я сейчас проверил в последней версии Квартуса: визард при попытке получить такие параметры ошибки не выдаёт, но настройки делает неправильные.

Честно говоря не понимаю, как это может работать физически. У PLL Cyclone IV минимально допустимая частота VCO 600МГц и разрядность C-counter 512. Следовательно минимальная частота, которую можно получить - более мегагерца. Чтобы получить 80кГц - надо иметь частоту VCO всего 41МГц. Очевидно, что стабильно это работать не обязано.

Вот. Когда такт приходит от АЦП - всё работает криво. Когда такт приходит от генератора - всё работает нормально. Чем они отличаются? Первое, что мне приходит на ум - генератор стартует сразу, а АЦП - нет. То есть при работе от АЦП возможно надо через некоторое время после загрузки ПЛИС подать сброс на PLL.

Тогда наверное имеет смысл посмотреть осцилографом, что там происходит. Ну и может быть уже запостить схему.

Стандарты ввода-вывода совпадают, LVCMOS-LVCMOS?

Возможно вы младшие биты адреса меняете не вовремя.

Было бы здорово, если бы вы описали систему чуть боле подробно. Какие в ней компоненты, как взаимодействуют, чем тактируются (с какой частотой).

1% от 0.01 - это 0.0001, таким должно быть значение младшего бита. Чтобы от этого дотянуться до 27-ми - нужен динамический диапазон 270000, или 19 бит. Я пока не понимаю, как это можно покрыть с помощью указанного АЦП.

Убедитесь, что у вас в Device выбран способ конфигурирования With Memory Initialization.

Тогда сделайте на логике. Вы потратите впустую всего одну сеть GCLK, через которую сигнал с логики пройдёт на вход PLL.

Это как раз важно. Если они все имеют одну частоту (то есть не плывут один к дргому), то просто заведите один сигнал на PLL, и нужный фазовый сдвиг сделайте на ней.

В аналоговой схемотехнике ничего - это не шум (и тем более не ноль или не единица, как во многих цифровых схемах), это источник с бесконечным импедансом. Он установит своё значение на входе за бесконечное время. Что вы и наблюдаете: источник с конечным импедансом (2.5В) устанавливает свое значние за конечное время, остальные источники это значение просто не изменяют.