iCEstick + yosys - использование глобального набора / сброса (GSR)

Question

Вероятно, это скорее вопрос iCEstick, чем вопроса yosys, но он задается здесь, поскольку я использую цепочку инструментов Icestorm.

Я хочу указать поведение при запуске моего дизайна, которое, по-видимому, согласуется различными местами в Интернете, связано с обычно rst сигнал. Для меня не было очевидным, откуда поступает такой сигнал, поэтому я углубился в последовательность включения. Текущее понимание взято из рисунка 2 в этом документе.

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

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

Просматривая лист данных семейства ice40 и сайт Lattice, я нашел этот документ об использовании сигнала Global Set/Reset. Я это подтвердил GSR упоминается в листе данных семейства, указанном на стр. 2-3 в разделе "Сеть распределения часов и управления". Кажется, что сигнал глобального сброса может использоваться одним из глобальных буферов. GBUF[0-7] и могут быть направлены (до 4 из них) на все LUT с глобальной распределительной сетью с большим разветвлением.

Это похоже на то, что я делал после этого, но я не могу найти никакой другой информации о том, как использовать это в своих проектах. В документе об использовании GSR говорится, что вы можете создать экземпляр нативного компонента GSR следующим образом:

GSR GSR_INST (.GSR (<global reset sig>));

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

Answer 1

Я не уверен, что этот документ GSR на самом деле о iCE40. Инструмент Lattice iCEcube интересно принимает экземпляры ячеек GSR, но, похоже, просто рассматривает их как драйверы с постоянным нулем. Также нет имитационной модели для типа ячейки GSR в библиотеке sim iCE40 и нет описания ее в документации по технической библиотеке iCE40, предоставленной Lattice.

Кроме того, я построил следующие два проекта с помощью инструментов решетки, и, кроме метки времени в "поле комментария" сгенерированного файла битового потока, сгенерированные битовые потоки идентичны! (Этот тест был выполнен с использованием Lattice LSE в качестве инструмента синтеза, а не Synplify. У меня были проблемы с запуском Synplify на моей машине по какой-то причине, и я прекратил попытки сделать это более года назад...)

Это первый тестовый дизайн, который я использовал:

module top (
    input clk,
    output rst,
    output reg val
);
    always @(posedge clk, posedge rst)
        if (rst)
            val = 1;
        else
            val = 0;

    GSR GSR_INST (.GSR (rst));
endmodule

И это второй тестовый дизайн:

module top (
    input clk,
    output rst,
    output val
);
    assign val = 0, rst = 0;
endmodule

Учитывая эти результаты, я думаю, можно с уверенностью сказать, что инструменты решетки просто игнорируют ячейки GSR в конструкциях iCE40. (Может быть, для совместимости с другими семействами FPGA?)

Так как же тогда генерировать первый сигнал? Например, ниже приведен простой генератор сброса, который утверждает (тянет низко) resetn для первых 15 циклов:

input clk;
...

wire resetn;
reg [3:0] rststate = 0;
assign resetn = &rststate;
always @(posedge clk) rststate <= rststate + !resetn;

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

Если вы используете PLL, то это обычное использование PLL LOCK выход для привода resetn сигнал. К сожалению, в "Руководстве по проектированию и использованию iCE40 sysCLOCK PLL" не указано, LOCK Сигнал уже синхронизирован с генерируемыми часами, поэтому было бы неплохо синхронизировать его с часами, чтобы избежать проблем с метастабильностью:

wire clk, resetn, PLL_LOCKED;
reg [3:0] PLL_LOCKED_BUF;
...

SB_PLL40_PAD #( ... ) PLL_INST (
  ...
  .PLLOUTGLOBAL(clk),
  .LOCK(PLL_LOCKED)
);

always @(posedge clk)
    PLL_LOCKED_BUF <= {PLL_LOCKED_BUF, PLL_LOCKED};

assign resetn = PLL_LOCKED_BUF[3];

Относительно использования глобальных сетей: Вы можете явно направить сигнал сброса через глобальную сеть (используя SB_GB примитивно), но используя поток IceStorm, arachne-pnr автоматически направит сигнал установки / сброса (при использовании более чем несколькими FF) через глобальную сеть, если глобальная сеть доступна.