Асинхронка в verilog Опции

[Lutovid]

Всем привет!
Написал FSM разделив синхронку и асинхронку; то есть в одном always блоке синхронный процесс, во втором в списке чувствительности занесены все входные сигналы; Vivado 16.3 и 17.1 развели написанное мной ядро так, что сигналы из списка чувствительности воспринимаются как не законстрэйнченые клоки... Вопрос - это нормално и можно на это забить? Или где-то в коде косяк и такого не должно быть?
Что бы было понятнее про что я - я прикрепляю фотку (принсткрин сделать не могу сейчас, прошу прощения за качество)

[masics]

Скорее всего это latches.

[Lutovid]

Скорее всего это latches.

Вы праввы
Я посчитал, что вот это

Код

always @(*) begin
    if (header_formatter_ready)
        header_formatter_ready_latch <= 1'b1;
    else if (ascii_header_dataout_rd_en || reset_header_config)
        header_formatter_ready_latch <= 1'b0;
    else
        header_formatter_ready_latch <= header_formatter_ready_latch;
end

синтезируется как LDCE

Код

   LDCE #(
      .INIT(1'b0) // Initial value of latch (1'b0 or 1'b1)
   ) LDCE_inst (
      .Q(header_formatter_ready_latch),      // Data output
      .CLR(ascii_header_dataout_rd_en || reset_header_config),  // Asynchronous clear/reset input
      .D(1'b1),      // Data input
      .G(1'b1),      // Gate input
      .GE(header_formatter_ready)     // Gate enable input
   );

Мне было не очевидно, что на самом деле это не так
Сейчас уже вижу, что приоритеты ресета в двух кусках разные

[iosifk]

Код

always @(*) begin
    if (header_formatter_ready)
        header_formatter_ready_latch <= 1'b1;
    else if (ascii_header_dataout_rd_en || reset_header_config)
        header_formatter_ready_latch <= 1'b0;
    else
        header_formatter_ready_latch <= header_formatter_ready_latch;
end

синтезируется как LDCE

Мне было не очевидно, что на самом деле это не так
Сейчас уже вижу, что приоритеты ресета в двух кусках разные

На самом деле в любом case, если не определить все состояния, появятся латчи. Чтобы этого не произошло, надо определить состояние по "умолчанию"...

[Lutovid]

На самом деле в любом case, если не определить все состояния, появятся латчи. Чтобы этого не произошло, надо определить состояние по "умолчанию"...

В моем примере else разве не определяет состояния "по умолчанию"? Если речь идет об fsm, то там default поле, естественно, есть

[iosifk]

В моем примере else разве не определяет состояния "по умолчанию"? Если речь идет об fsm, то там default поле, естественно, есть

Я не внимательно вчитался в Ваш код, наверное потому и не понял...
Просто я так никогда не делаю:
always @(*) begin
if (header_formatter_ready)
header_formatter_ready_latch....

Если у Вас есть автомат, то зачем вот это always @(*) ? У Вас что, какие-то сигналы могут меняться "между фронтами клоков"? В любом случае, должен быть автомат, который определяет, кому и когда что можно делать. И должны быть регистры, счетчики и все прочее, которые получают от автомата сигналы на разрешение записи, сдвига, обнуления и т.д.

[Lutovid]

Я не внимательно вчитался в Ваш код, наверное потому и не понял...
Просто я так никогда не делаю:
always @(*) begin
if (header_formatter_ready)
header_formatter_ready_latch....

Если у Вас есть автомат, то зачем вот это always @(*) ? У Вас что, какие-то сигналы могут меняться "между фронтами клоков"? В любом случае, должен быть автомат, который определяет, кому и когда что можно делать. И должны быть регистры, счетчики и все прочее, которые получают от автомата сигналы на разрешение записи, сдвига, обнуления и т.д.

Просто пока автомат крутился в ряде начальных состояний мог прийти импульс, а информация о том приходил ли он понадобилась бы лишь в конце, я посчитал, что вместо вставляния этого детектирования во все начальные состояния, проще сделать отдельный латч. Можно было бы сделать синхронное детектирование по клоку, но разве это принципиально?