Особенности логики, Вопросы по проектированию RTL Опции

[drozel]

Добрый день. Пытаюсь адаптировать свой verilog, проверенный на fpga, для реализации в кремнии.
Периодически возникают те или иные вопросы, ответ на которые хочется найти тут, у спецов.
Первый вопрос:

Представим 8-разрядный счетчик, считающий по клоку. По достижению им числа 100 нужно переключиться в режим 1, по достижению 200 - в режим 2 и остаться в нем до сброса.
Раньше, в ПЛИС (в связи с избыточностью ячеек), я бы сделал так:

Код

reg [7:0]cnt;
always @(posedge clk, negedge nrst)
begin
    if (~nrst) cnt <= 0;
    else begin
        if(cnt<200) cnt <=cnt + 1'b1;
    end
end

always @*
begin
    if(cnt<100) mode <= 0;
    else if(cnt <200) mode <= 1;
    else mode <= 2;
end

Теперь, представляю, во что выльется этот код: синтезатор реализует 3 компаратора (причем для определения диапазона) из простых элементов для декодирования значения счетчика. Думаю, как упростить схему. Рождается код:

Код

reg [7:0]cnt;
always @(posedge clk, negedge nrst)
begin
    if (~nrst) begin
        cnt <= 0;
        mode <= 0;
    end
    else begin
cnt <= cnt+1;
        if(cnt==100 || cnt==200) mode <= mode+1;
    end
end

Тут уже компарирование не диапазона, а конкретных значений, зато логика mode становится синхронной.
Проверил в DC - действительно, экономия по площади и кол-ву ячеек - почти в 2 раза.
Не имеет ли второй вариант каких-то подводных камней?

Сообщение отредактировал drozel - Dec 17 2015, 11:51

[iosifk]

always @*
begin
if(cnt<100) mode <= 0;
else if(cnt <200) mode <= 1;
else mode <= 2;
end[/code]



Не имеет ли второй вариант каких-то подводных камней?

Вот первый вариант - асинхронный. И он-то как раз "имеет", потому как "cnt" переключается далеко не одновременно. Да и еще компаратор свое добавит. А потому "mode" может переключаться как угодно из-за гонки фронтов... В зависимости от погоды и настроения...

[drozel]

Вот первый вариант - асинхронный. И он-то как раз "имеет", потому как "cnt" переключается далеко не одновременно. Да и еще компаратор свое добавит. А потому "mode" может переключаться как угодно из-за гонки фронтов... В зависимости от погоды и настроения...

Хорошее замечание, спасибо.
Кстати, отловил еще одно отличие: в синхронном примере нет насыщения счетчика. После того, как добавил, площадь второго варианта стала почти в 1.5 раза больше. Т.е. синхронный более накладный. Видимо, все таки синтезер очень сильно упрощает логику сравнения, даже если речь идет о диапазонах.
Еще, в синхронном отстал один critical path.

[masics]

Хорошее замечание, спасибо.
Кстати, отловил еще одно отличие: в синхронном примере нет насыщения счетчика. После того, как добавил, площадь второго варианта стала почти в 1.5 раза больше. Т.е. синхронный более накладный. Видимо, все таки синтезер очень сильно упрощает логику сравнения, даже если речь идет о диапазонах.
Еще, в синхронном отстал один critical path.

1. дайте посмотреть на код.
2. что значит "отстал один critical path"?

[drozel]

1. дайте посмотреть на код.
2. что значит "отстал один critical path"?

Код

module top (
    input clk,
    input nrst,
    output reg [1:0]mode
);

reg [7:0]cnt;
always @(posedge clk, negedge nrst)
begin
    if (~nrst) begin
        cnt <= 0;
        mode <= 0;
    end
    else begin
        if(cnt<200)    cnt <= cnt + 1;
        if(cnt==99 || cnt==199) mode <= mode+1;
    end
end

endmodule

Вы говорили про тайминги. Я не до конца понял, что Вы имели ввиду, посмотрел отчет по slack. У варианта 2 они чуть лучше, кроме одного пути: младший бит cnt - сумматор - старший бит через логику.

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

Вариант 2:

Вариант 1:


Сообщение отредактировал drozel - Dec 17 2015, 13:13

[masics]

1. А если поменять "if(cnt<200) cnt <= cnt + 1;" на "if(mode != 2) cnt <= cnt + 1'b1;"?
2. Для такого маленького дизайна не стоит обращать на critical path. В любом случае, это всё поменяется при placement.

На самом деле не все так однозначно... Вы пишите (cnt<100)... А что будет, если не 100, а 127? И не 200, а 255? Тогда компараторы могут просто сравнивать только старшие разряды и логика значительно сократится... Т.е. если старший разряд 0, то mode = 0, если 1, то и mode = 1, а если два старших разряда 1, то mode = 2...

Ага, давайте сделаем 128 итераций вместо 100. Какая разница? Ну результат шифрования будет неверный, зато гейты съэкономили.