Как я могу рассчитать задержку распространения через серию комбинационных схем с использованием Verilog и FPGA?

Я новичок в FPGA и HDL, но я пытаюсь учиться и не могу понять это. Как я могу рассчитать или оценить задержку распространения через несколько уровней комбинированной логики. Могу ли я определить это только эмпирически или я могу понять это во время разработки. В этой ситуации я использую и FPGA для реализации схемы установки и проверки четности. Схема будет выглядеть как древовидная сеть вентилей xor, как на картинках в примере, за исключением того, что я намерен использовать xor 16 регистров, поэтому будет больше уровней или операций xor. Я хотел бы иметь возможность рассчитать задержку распространения по каждой логике xor «уровня», чтобы я мог определить, сколько долей тактовых циклов или сколько наносекунд займет вся операция проверки и настройки четности. Надеюсь, я имею смысл.

параметр сети

сеть проверки четности

Большое спасибо за помощь.


person Frank Dejay    schedule 16.01.2012    source источник
comment
Задержка распространения возникает не только из-за логических элементов, но и из-за маршрутизации, которая, в свою очередь, зависит от того, где на устройстве вы разместили отдельные элементы.   -  person Oliver Charlesworth    schedule 16.01.2012
comment
Я думаю, что это место на electronics.se   -  person Ben Voigt    schedule 17.01.2012


Ответы (4)


Вам нужны «Знания», как я объясняю здесь, в «Искусстве проектирования высокопроизводительных ПЛИС». http://www.fpgacpu.org/log/aug02.html#art "Вы должны . ... включите свои инструменты и спроектируйте несколько тестовых схем, а затем откройте временной анализатор и редактор FPGA и изучите то, что получилось, каковы задержки (логика и маршрутизация) и т. д. ».

После того, как вы сделаете это некоторое время, вы будете смотреть на этот вопрос и просто знать (или иметь довольно хорошую идею).

В этом случае, например, я знаю, что в FPGA XOR на 16 входов будет строиться из дерева 4-х или 6-ти входных интерполяционных таблиц (4-LUT или 6-LUT) глубиной в две, и это не может быть реализована в схеме только одна LUT глубиной. Поэтому минимальная задержка для такой схемы в конвейерной реализации будет (в терминологии Xilinx):

  • tCKO -- синхронизация с выходной задержкой любого из 16 триггеров

  • tILO -- задержка через LUT первого уровня

  • tAS -- задержка до 2-го уровня LUTS + время настройки триггера при условии, что они реализованы в том же слайсе

  • плюс чистые задержки маршрутизации

и для скорости Virtex-6 -1 я ожидаю, что это будет ~ 1,5 нс.

Как уже говорили другие, данные о задержке переключения компонентов находятся в таблицах данных для рассматриваемого устройства, а задержки маршрутизации нет. Действительно, со временем вы можете даже начать запоминать ключевые задержки и развить понимание того, сколько примитивов FPGA, таких как LUT, вы можете использовать, и при этом по-прежнему устанавливать конкретный тактовый период / тактовую частоту.

Во всяком случае, я только что попробовал это с помощью какого-то одноразового Verilog, который я закодировал:

module t(clk, i, o);
  input clk;
  input [15:0] i;
  output reg o;

  reg [15:0] d;
  always @(posedge clk) begin
    d <= i;
    o <= ^d;
  end
endmodule

и простой файл UCF:

net clk period = 1.5 ns;

а общая задержка в моем устройстве была около 1,4 нс. Попробуйте сами и убедитесь!

Вот один путь из вывода статического временного анализатора:

Paths for end point o (SLICE_X3Y68.A5), 6 paths
--------------------------------------------------------------------------------
Slack (setup path):     0.198ns (requirement - (data path - clock path skew + uncertainty))
  Source:               d_13 (FF)
  Destination:          o (FF)
  Requirement:          1.500ns
  Data Path Delay:      1.248ns (Levels of Logic = 2)
  Clock Path Skew:      -0.019ns (0.089 - 0.108)
  Source Clock:         clk_BUFGP rising at 0.000ns
  Destination Clock:    clk_BUFGP rising at 1.500ns
  Clock Uncertainty:    0.035ns

  Clock Uncertainty:          0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter (TSJ):  0.070ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.000ns
    Phase Error (PE):           0.000ns

  Maximum Data Path at Slow Process Corner: d_13 to o
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X3Y67.BQ       Tcko                  0.337   d<15>
                                                       d_13
    SLICE_X2Y68.A2       net (fanout=1)        0.590   d<13>
    SLICE_X2Y68.A        Tilo                  0.068   d<11>
                                                       d[15]_reduce_xor_21_xo<0>1
    SLICE_X3Y68.A5       net (fanout=1)        0.180   d[15]_reduce_xor_21_xo<0>
    SLICE_X3Y68.CLK      Tas                   0.073   d<10>
                                                       d[15]_reduce_xor_21_xo<0>3
                                                       o
    -------------------------------------------------  ---------------------------
    Total                                      1.248ns (0.478ns logic, 0.770ns route)
                                                       (38.3% logic, 61.7% route)

Как вы можете видеть, логические задержки из таблиц данных составляют всего около 480 пс, в то время как задержки сетевой маршрутизации составляют 770 нс, а сдвиг часов и т. д. немного больше, всего менее 1,3 нс. На самом деле это быстрее, чем предел переключения компонентов / Fmax на глобальном дереве часов 700 МГц / 1,43 нс...

Таким образом, попробовав несколько тестовых схем и настроив их, вы получите опыт, который поможет вам оценить, насколько быстро ваша схема будет работать при реализации в примитивах FPGA, таких как LUT.

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

Удачного взлома!

person Jan Gray    schedule 19.01.2012
comment
Спасибо. Это намного больше ответа, чем я ожидал, но это очень полезная информация для новичка FGPA, такого как я! - person Frank Dejay; 22.01.2012

Вы можете оценить задержки распространения через несколько этапов логики, только если у вас есть временные модели, которые обеспечивают задержки в зависимости от температуры, напряжения питания и изменения производственного процесса для всех ваших компонентов. В мире ИС это делается автоматически с помощью инструментов статического временного анализа. Я не уверен в методологиях проектирования FPGA.

Как отмечает Оли Чарлсворт, общая задержка также зависит от задержек межблочных проводов. Другими факторами являются: мощность входного привода и выходная нагрузка.

person toolic    schedule 16.01.2012

Теоретически можно получить задержки распространения в FPGA и без кодирования, но это будет непросто.

самый простой способ сделать это — создать очень простой проект с нужными вам сигналами ввода-вывода, написать код на VHDL, Verilog или даже с помощью захвата схемы, синтезировать и развести проект, а затем просмотреть файл отчета, сгенерированный инструментом, чтобы увидеть фактические задержки.

Чтобы понять некоторые параметры в файле отчета, вы можете заглянуть в документ «Характеристики постоянного тока и переключения», предоставляемый всеми компаниями, производящими ПЛИС. Например, для устройств семейства Spartan 6 от Xilinx это: http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf

Надеюсь, это поможет, /Фархад

person FarhadA    schedule 16.01.2012

Это то, что вы чувствуете, когда больше кодируете на конкретной платформе, но это часть искусства быть хорошим RTL-инженером.

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

Затем вы меняете целевую ПЛИС или технологическую библиотеку, и вам приходится корректировать все свои ожидания.

person Paul S    schedule 17.01.2012