TimeQuest для чайников. Часть 4 (Как много интерфейсов разных)
- altera |
- constrains |
- TimeQuest |
- ПЛИС
System-Synchronus Output
Рассмотрим вывод пилы на синхронный параллельный ЦАП.
module dac (input iclk, output oclk, output logic [7 : 0] data);
logic [7 : 0] cnt;
always_ff @(posedge iclk) begin
cnt <= cnt + 1'b1;
data <= cnt;
end
assign oclk = iclk;
endmodule
Положим параметры ЦАП tsu/th = 5ns/5ns, частота 10МГц, все настройки стоят по default. sdc файл для данного проекта будет таким.
set_time_format -unit ns -decimal_places 3
derive_clock_uncertainty
create_clock -period 10MHz -name {iclk} [get_ports {iclk}]
create_generated_clock -name {oclk} -source [get_ports {iclk}] [get_ports {oclk}]
set_output_delay -clock [get_clocks {oclk}] -max 5.0 [get_ports {data[*]}]
set_output_delay -clock [get_clocks {oclk}] -min -5.0 [get_ports {data[*]}]
Поясним, что означают незнакомые/непонятные для нас строки
set_time_format -unit ns -decimal_places 3
Мы задаем единицы измерения времени, что бы не писать их по месту.
create_generated_clock -name {oclk} -source [get_ports {iclk}] [get_ports {oclk}]
Это описание клока, на котором работает приемник нашего интерфейса (ЦАП). Как видно из кода, никаких преобразований с клоком не было, поэтому он назначен один в один.
set_output_delay -clock [get_clocks {oclk}] -max 5.0 [get_ports {data[*]}]
set_output_delay -clock [get_clocks {oclk}] -min -5.0 [get_ports {data[*]}]
Это описание констрейна связанное с tsu и th ЦАПа соответственно. По идее эти задержки должны задаваться как
Output maximum delay value = maximum trace delay for data + tSU of external register - minimum trace delay for clock
Output minimum delay = minimum trace delay for data - tH of external register – maximum trace delay for clock
Но в данном случае мы ими пренебрегаем. Положим, что задержки выровнены на плате. Всё, мы задали констрейны для нашего проекта. Собираем, запускаем анализ и видим в логах квартуса
Critical Warning: Timing requirements not met
Казалось бы всего 10МГц, как же так. Давайте разбираться подробно. Запускаем TimeQuest, выполняем анализ и видим результат
Нда, действительно не укладываемся во времянку. Давайте выясним почему. С помощью Report Worst Case Path смотрим что же происходит в интерфейсе.
По началу кажется, что на вейвформе изображен сплошной бред. Но не будем торопиться.
Смотрим внимательно, видно Launch Clock = iclk и Latch Clock = oclk. Они совпадают. Неужели TimeQuest забыл про задержку? А вот и нет, просто оба эти клока идут от входного порта ПЛИС iclk и временной анализ начинается с этой точки.
Смотрим далее. Видим Clock Delay = 2.394нс и Data Delay = 2.985нс. Clock Delay это задержка от порта ПЛИС iclk, до тактового входа триггера data[0]. А Data Delay это задержка от выхода триггера data[0] до порта плис data[0]. Сумма этих величин дает Data Arrival, т.е. задержку прибытия данных на порт плис.
Теперь смотрим, что происходит с клоком oclk. Чуть ниже видим Clock Delay = 3.766нс. Это и есть задержка клока oclk относительно клока iclk. Прибавляем к этому времени требуемое нам th (мы же не проходим по холду) и получаем Data Required. Как мы видим, а ведь действительно условие по th не выполняется.
А может быть TimeQuest врет, проверим задержку между портами iclk и oclk. Выполним task Report Path...
Действительно, не врет
Первое что приходит в голову, надо задержать данные, а задержка есть в I/O буферах. Посмотрим, используется ли она. С помощью Locate смотрим Resourse Property Editor
Упс, а триггер то не в IO буфере вообще, а без этого триггера сыклон 3 не умеет использовать задержку в I/O буфере. Назначаем на data[*] Fast Output Register. Проверяем и ...
Опять облом. Как же так, проверим ка квартус.
Он сделал все что мог, поставил триггер в I/О буфер, и даже использовал задержку (Output Pin Delay == 1). Но, "ну не шмогла я не шмогла" (с) Старый анекдот.
И тут мы вспоминаем, что, подав инверсный клок, мы поставим фронт как раз в середину данных, тогда tsu/th должны вылезти как бы автоматом. Пишем в коде
assign oclk = ~iclk;
В sdc файле
create_generated_clock -name {oclk} -invert -source [get_ports {iclk}] [get_ports {oclk}]
Вуаля, ошибок нет. И еще больше 40нс в запасе
Вот в принципе и все про данный вид интерфейсов. От себя хочу добавить, что метод инверсии клока не является универсальным. И использовать его везде не следует.
- блог пользователя des00
- 65430 просмотров
Новые записи в блогах
- Устранение дребезга контактов на основе вертикальных счетчиков
- Диагностика Imprecise Bus Faults в микроконтроллерах Cortex-M3/M4/M4F
- Self-powered камера
- Фоновый модулятор: беспроводная связь из ничего (перевод)
- Texas Instruments Analog Applications Journal SLYT612 "Снижение искажений в аналоговых КМОП ключах" (перевод)
- USB MSD. Часть 6. Команды SCSI (перевод)
- USB MSD. Часть 3. USB класс накопителей данных (перевод)
- Texas Instruments Application Report SBAA042 "Кодовые схемы, используемые в аналогово-цифровых преобразователях" (перевод)
- 10 принципов правильного интерфейса
- Релиз SDK на русский микропроцессор КРОЛИК
Комментарии
Спасибо Автору! Всё очень
Спасибо, поправил
Спасибо, поправил
Самоя первая картинка не
Самоя первая картинка не соответствует превью.(я так понимаю превью правильнее)
(уточнение) Самая первая
(уточнение)
Самая первая картинка на 3й странице не соответствует превью.(я так понимаю превью правильнее)
set_output_delay -clock
set_output_delay -clock [get_clocks {oclk}] -min -5.0 [get_ports {data[*]}]
как получается что мин делай отрицательная, как понять это физически????
я понимаю она вычислялась по формуле OmD = min tD (EXT) – tH (EXT) – max tCS (EXT),
Физически это понимается
Отправить комментарий