TimeQuest для чайников. Часть 3 (Клоки как вас много)

Продолжаем наше погружение в мир TimeQuest-а. Как вы уже поняли, эта часть посвящена проектам, в которых клоков больше чем один. Задание ограничений для таких проектов не намного сложнее, чем для рассмотренного нами ранее одночастотного проекта. Рассмотрим основные случаи многочастотных проектов.

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

Клоки идущие снаружи ПЛИС

 Рассмотрим простой управляемый по SPI ШИМ модулятор. 

module spi (input clk, cs_n, sdi, sclk, output logic led ) ;

  //
  // spi clock domain
  //

  logic [15 : 0] sdata;

  always_ff @(posedge sclk) begin
    if (!cs_n) begin
      sdata <= (sdata << 1) | sdi;
    end
  end

  //
  // system clock domain
  //

  logic          latch;
  logic  [2 : 0] cs_reg;
  logic [15 : 0] level, cnt;

  always_ff @(posedge clk) begin  // simple synchronizer
    cs_reg <= (cs_reg << 1) | cs_n;
  end

  assign latch = ~cs_reg[2] & cs_reg[1]; // posedge

  always_ff @(posedge clk) begin  // spi controlled simple pwm modulator
    if (latch)
      level <= sdata;

    cnt <= cnt + 1'b1;
    led <= (cnt < level);
  end

endmodule

Начнем составлять sdc файл. Как мы видим, в этом проекте используется два клока clk и sclk. Значит, нам нужно их описать.

derive_clock_uncertainty
create_clock -period 100MHz -name {clk} [get_ports {clk}]
create_clock -period 10MHz  -name {sclk} [get_ports {sclk}]

Кроме того, как мы видим, в этом проекте данные передаются из тактового домена sclk в домен clk. Теперь внимательно посмотрим на код. Видно синхронизатор сигнала управления захвата новых данных, кроме того, видно что к моменту захвата данных в домене clk данные SPI будут неизменны в течении 2-х тактовых интервалов. Естественно если управляющий проц не начнет тут же новую транзакцию (даже в этом случае при отношении clk/sclk  в 10 раз ПЛИС успеет захватить данные). Следовательно, анализировать эти пути на выполнение времянок не нужно.

Можно описать это разными способами :

1. С помощью команды set_false_path, указав в качестве источника и приемника, биты регистров sdata и level.

set_false_path -from [get_registers {sdata[*]}] -to [get_registers {level[*]}]

2. С помощью команды set_false_path, указав в качестве источника и приемника, регистры, тактируемые частотами sclk и clk

set_false_path -from [get_clocks {sclk}] -to [get_clocks {clk}]

3. Описав группу клоков, которые асинхронны/эксклюзивны друг другу. Асинхронные клоки, в данном контексте понимаются как клоки, анализировать пути между которыми не нужно.

set_clock_groups -exclusive -group {clk} -group {sclk}

В команде используется ключ -exclusive, потому что эксклюзивность включает в себя свойство асинхронности клоков. У альтеры есть ключ -asynchronus, но он поддерживается только для совместимости со старыми версиями.

Собственно всё, мы прописали клоки проекта и указали их взаимосвязь друг с другом. Теперь квартус может оптимизировать логику доменов независимо друг от друга. И при анализе эти пути будут выброшены.

Вообще, по правде говоря, все эти 3 способа не эквивалентны друг другу. В 1ом способе не будет анализироваться конкретный путь от sdata до level. Во втором все пути из домена sclk в домен clk. А в третьем все пути из домена sclk в домен clk и наоброт. Какой именно метод определения false_path использовать определяется контекстом проекта.