Dragon_Fly

По ссылке http://rghost.ru/65nnBMCFY - даташит одной такой PLL. Там есть Period Jitter (pk-pk), Cycle-to-Cycle Jitter (max), TIE Jitter (pk-pk), Long-term Jitter (pk-pk) в конце дока даны их определения. И всё бы ничего, но даже этого набора характеристик явно недостаточно для модели. Планирую написать производителю вопросы, но прежде решил проконсультироваться на форуме. Вдруг там всё просто как дважды два. Точнее, там вроде как действительно просто, но недостаточно для однозначного или хотя бы примерного понимания картины в целом. Даны лищь частные случаи, причём характеристика "long-term", как мне кажется, недоопределена. Обмерить девайс спектроанализатором возможности не имею. Анализаторов навалом. Девайса нет.. :( ps А что есть "PVT"?

Всем доброго времени суток. Имею вопрос по правильному пониманию характеристик джиттера в PLL. Интересуют PLL в виде IP для интеграции в микруху, но, полагаю, что можно и на примере отдельных готовых микросхем рассуждать. Итак, в даташитах от производителей указываются (либо не указываются) различные виды джиттеров, измеряемые в долях такта (например, peak to peak или cycle to cycle), а также в абсолютном времени (например, 100 psec). Мне нужно промоделировать такую PLL. По реализации модели, если понятно поведение симулируемого объекта, вопросов не имею. Вопрос именно по пониманию параметров. Ведь есть ещё фильтр, который по идее и определяет долговременный джиттер. Но он в ДШ на интегрируемые PLL не охарактеризован. А абсолютные единицы джиттера - они считаются в предположении о некой тактовой частоте? Кто бы пояснил эту кухню. То есть какие эффекты надо заложить в модель дрожания такта? По каким правилам двигать такт туда-сюда и на сколько?

Не трогал SystemC некоторое время. Теперь вот актуализировалось. Требуется сделать золотую модель по уже написанному верилоговскому коду. Имею следующий вопрос (схожий с корневым сообщением, но всё ж чуть иной). В верилоге имеем регистры-триггеры, работающие по клоку, и комбинационную логику, местами описанную через “wire”. В SystemC хочу сохранить и треггеры, и “ваиры” (провода). Казалось бы просто, но что-то я заглючил. Предположим следующую ситуацию. Есть триггер А, в который по клоку попадает выход триггера B: reg [2:0] A; reg [2:0] B; always @(posedge clk) A<=B; есть провод C, всегда равный A+1: wire C=A+1; и есть также процесс, обновляющий регистр B: always @(posedge clk) B<=C*3; Предположим также, что выходы A, B и C заводятся на ещё большое количество портов в других модулях. Вопрос: как все три указанные сущности отобразить в SystemC? Допустим, завожу три процесса. В первом чувствительность к клоку, во втором к изменению A. А какая тогда чувствительность у процесса с обновлением регистра B?

Если сравнивать аккустический модем и bluetooth, то последний в мильярд раз предпочтительней. Звуковые волны не проходят сквозь обычные предметы, в том числе через человеческое тело. Нужна полноценная прямая видимость. Второй момент - многолучовость, которая также будет повышенной в адуио. Третий момент - дуплексный или полудуплексный режим. А если множественный доступ? Наглядный пример: позициоинирование в помещении с использованием УЗ практически вытеснено блютусом. УЗ точнее, но для народа удобнее таки голубой зуб.

Jurenja, спасибо за анализ. На данном этапе проекта можем предполагать любую технологию. Пусть будет 28 нм. Уточните, 64 (степень двойки) критично для экономии, или годится любой константный коэффициент? Ещё вопросы: 1) насколько полученный таким образом клок шумнее клока с более энергопотребляющих но качественных PLL? Здесь "кольцевой VCO", а там какой? 2) если поставлю счётчик на входе и выходе PLL и буду мерить соотношение, - будет ли дополнительный фазовый шум кольцевого VCO приводить к появлению или недостаче целых выходных тактов? Если да, я, видимо, смогу их "отыграть" в цифровой части модулятора. Не думаю, что это большая проблема, главное понять её наличие. 3) если хочу экономичный дельта сигма ЦАП, до какой частоты смогу поднять частоту однобитного семплирования относительно исходных 1600 МГц? Как это скажется на потреблении? До какого значения частоты можно повышать практически безболезненно? Спасибо!

Необходимо получить клок с одним и только одним значением в точности равным или чуть большим 1600 МГц. 1620 МГц годится. И даже 1640 - лишь бы работало. Опорная частота может быть любой. К примеру, если для экономии удобно повышать в 64 раза, - берём кристалл на 25 МГц, подаём на PLL с коэффициентом 64 и получаем желаемые 1600 МГц. Фазовые шумы значение имеют. Но чтобы не растекаться, давайте пока ими пренебрежём.

Jurenja, мне сложно оценить фазовые шумы. Вариация Алана понятнее. Если по ней комментировать, то хочется, чтобы в интервале несколько десятков миллисекунд она сильно не деградировала. На более короткой выборке можно гробить существенно. Исходим также из стабильного питалова от батарейки. Если надо, поставим отдельную запитку специально для PLL. Такая возможность существует. По остальному - прошу дать оценку исходя из идеализированной ситуации. Только укажите, чем именно пренебрегли? И насколько будет чреват отказ от допущений. всё те же фазовые шумы? есть ли сравнительные таблицы для качественной и ултра экономичной пиэльэльки? Я правильно понял, что схема рабочая, но шумная? что низкочастотная цифровая часть может тактироваться таким клоком, а проблема в радиочастотном (гигагерцовом) модуле? Делитель и пр. необязательно. Зачем, если можно подобрать идеальную пару, когда формируемый клок получается из исходного простым помножением?

Друзья! Хочется понять, какое энергопотребление PLL можно заложить в общий бюджет микросхемы, если требуется длительная работа от батарейки? Интересует предельно возможная оптимизация. На design-reuse вижу цифирь 12 мВт. Но там универсальный модуль с папаметрами. А если без параметров? Любой удобный кристалл/TCXO в 1600 МГц? Какова связь с техпроцессом? Прямая или не очень? Еще: в статье по ссыле http://airccse.org/journal/vlsi/papers/0610vlsics1 говорят, что в САПР-е получили 50 мкВт. Но с рядом оговорок. Процесс 45lp. Почему такие PLL редко используют на практике?

Прошу прощения, но я бы хотел чуть более разжеванный ответ :) Про C++ не спрашиваю. С ним понятно.

Сорри за FAQ.. :)

Стандартное назначение через операторы сводится к read/write, то есть работает с задержкой в дельта такт. Если я правильно понимаю, схемы с портами без задержки в SystemC не предусмотрено.

В verilog для комбинационной логики применяют присвоение с директивой "assign". Для триггеров завели альтернативный вариант "<=". Он вносит задержку. В SystemC присвоение с задержкой реализуется через сигналы, которые затем можно развести через порты по адресатам и сделать событийными. А как организовать средствами SystemC аналогичную "сигнальную" взаимосвязь, но без дельта задержки?

Дело не в кубической интерполяции или алгоритмах CORDIC. В оригинале правильно пишут, зачем придумали SystemC: "Abstract: SystemC® is defined in this standard. SystemC is an ANSI standard C++ class library for system and hardware design for use by designers and architects who need to address complex systems that are a hybrid between hardware and software" Имея в своих руках System C или нечто пусть даже совсем рукотворное и несинтезируемое, типа симуляции на Си процессов, как я выше описал, вы не железо отлаживаете, вы можете отладить всю систему, в которой и процессорный софт зубодробителен, и всякие там акселераторы, на которые вынесена куча функций. Чтобы после отладки и кодирования на верилог никаких сюрпризов не было. То есть сишная модель (на system ли Си или совсем простенькая, без циклоаккуратностей и детализации шин) все равно будет. На ней отлаживается алгоритм, она - как золотая модель, плюс структурно и алгоритмически содержит все, как в будущем чипе. Основной RTL-щик, с которым взаимодействую, относится к systemC враждебно, говорит, что полноценных синтезов начиная сверху и до самого кремния на этом SystemC по всей Америке дай бог парочка будет. А для понимания исходников слишком дотошное прописывание в СистемСи каждой шины только во вред. То есть он сторонник полуфабриката на обычном Си (со всей документацией есессно).

yes, благодарю за содержательный ответ! стало быть, если верилогер шарит в СистемСи, ему давать задание в виде готового проекта (помимо документации) самое милое дело?

Torpeda, так ведь и в "Word-е" циклоаккуратными схемами не морочатся..