Временной анализ FPGA или как я осваивала Timequest

Автор оригинала: Altera support
  • Перевод
  • Tutorial
Доброго времени суток, уважаемые хабравчане.

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



Многие Надеюсь, хотя бы один из вас программировал под FPGA на уровне выше чем моргание светодиодом. Если такое было, то вы могли бы заметить, что иногда что-то работает не так. Возникают проблемы с таймингами подобного рода: с повышение частоты, система становится нестабильной, битики начинают залипать, данные пропадают и проект не работает.

Это перефраз статьи о том, откуда эти проблемы берутся и как с ними бороться. Автор поста использует ALTERA и софт для разработки той же фирмы(Quartus II).

Чтобы лучше понять суть проблемы, рассмотрим простейшую модель 8ми битной ячейки памяти.

module habr111(
    input [7:0] data,
    input clk,
    output[7:0] out
    );

reg [7:0] count;
always @ ( posedge clk  )
    count <= data;

    assign out = count;

endmodule


Запускаем симулятор и видим, что когда данные приходят на вход в определенной фазе относительно тактирующего сигнала, то на выходе появляются мусорные данные.



Все дело в том, что D-триггер цифровое устройство только в первом приближении. То есть по сути это набор аналоговых транзисторов, имеющих свое время нарастания фронтов. Бывает, что clock ловит момент, когда сигнал дорастает до напряжения перехода между 0 и 1. Это называется метастабильным состоянием и что будет сформировано на выходе не очевидно.

Так же каждый бит имеет свою задержку: какие-то биты приходят раньше, какие-то позже. Если переключение данных происходит в момент переключения clock, то из-за вышеописанного эффекта на выход идет мешанина старых и новых битов.

Чтобы проект работал корректно, необходимо избавиться от этих эффектов. Для этого надо самостоятельно считать те самые времена. В Quartus II этим занимается программа Timequest. Спрашивается: зачем нам это знать?

Схема, по которой timeqwest обсчитывает тайминги, состоит из двух регистров. Если все их параметры известны, она посчитает и сделает правильную разводку. Но если есть некий внешний регистр, о котором у Timequest никакой информации нет, то разработчику необходимо посчитать и ввести все самостоятельно. Как это делается — описывается в этой статье.

Мой вольный перевод.

Надеюсь кому-нибудь это поможет так же, как помогло и мне.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 7

    +7
    Можно было целиком всё статьёй оформить, а не перекидывать на другой документ.
      0
      Я понимаю, перевод и всё такое, но область всё же техническая — стоит писать D-триггер вместо «д-триггер», и не склонять clock («момент переключения clocka»), и Timequest писать с большой буквы хотя бы из уважения к Altera.
        –1
        Спасибо, за замечания. Исправила.
        +2
        Статья интересна, но МАЛО… читать внешний документ как-то не охота. Тем более открывать его надо будет в тяжелом офисе…
          0
          Может я чего-то не уловил, но если «есть некий внешний регистр», который тактируется от совершенно другого тактового сигнала (т.е. является асинхронным по отношению к регистру внутри FPGA), то путь между этими регистрами должен быть объявлен как false path — нет абсолютно никакого смысла задавать input delay. Input delay имеет смысл только тогда, когда тактовые сигналы для «внутреннего» и «внешнего» триггеров синхронные. В противном случае, как правильно написано в документе по ссылке, есть неиллюзорный шанс загнать «внутренний» триггер в метастабильное состояние. Вот только никакими SDC-констрэйнами избавиться от этого нельзя, от метастабильности избавляются путем добавления синхронизаторов.
            0
            Мы считаем, что внешний регистр тактируестя от того же синхросигнала, те синхронно. например DDR интерфейс. там имеются ножки C/K, которые есть клоки и DQ — данные. необходимо описать времена прохождения сигнала по внешним цепям, причем те тактируются синхронно.
            Твоя ошибка в том, что все написанное применимо только к синхронным схемам. Для асинхронных, действительно, можно только сказать таймквесту не анализировать данный путь и рассчитать вероятность появления метастабильности. Есть специальные формулы для расчета. Кстати в таймквесте встроены какие-то приблуды для этого, только я не совсем поняла, как ими пользоваться. Доп синхронизаторы просто уменьшают эту вероятность. На самом деле, если расчет говорит, что метастабильность возникает раз в миллиард лет, то значит на нее уже можно не обращать внимания :) и вообще это уже совсем другая история, не имеющая к данной статье отношения.
            Если интересно, можешь обращаться.
            0
            Я вас расстрою, уважаемый, но те симуляторы, которым вы пользуетесь, даже если там громко написано, что они «includes Altera library», по-сути, тоже цифровые и считают эти «клыки» весьма приблизительно. Что бы более-менее реальную картину увидеть — это либо моделирование в аналоговых PSpice-совместимых пакетах, либо, увы, эксперимент на живой плисине. Только так.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое