[TRILLER 0]

Следующий кусок кода вызывает непонятное мне поведение симулятора Vivado, которое отличается от поведение Modelsim:

module top (
    input  bit                  clk,
    input  bit                  i_uno[0:0],
    input  bit                  i_due[1:0]
);

bit     a[1:0], b[1:0]; 

always_ff @(posedge clk)
begin
    for (int i=0; i<2; i++) begin
        a[i] <= i_due[0];
        b[i] <= i_uno[0];
    end
end

Cимулятор Vivado(17.4, 18.3) для неупакованного массива присваивает в такой записи не нулевой элемент входного порта, а весь массив - как будто передаёт по адресу!

Т.е. в a[1] будет записано i_due[1], а b[1] и вовсе остаётся равным нулю! Я читал стандарт, но не нашёл подтверждение некорректности своей записи. Ведь согласно определению неупакованный массив отличается только тем, что весь массив нельзя использовать для арифметических операций. Тем более, моделсим данную запись моделирует корректно.

Может кто-нибудь сталкивался с подобным и может пояснить, кто в данном случае не прав? Одно дело, если sim Vivado ведёт себя не по стандарту и совсем другое, если и синтезатор позволяет себе вольности!

Поведение симуляторов:

Спойлер

файл и тестбенч:

top.sv

top_tb.sv

[one_eight_seven 3]

Написано так, чтобы работать непонятно как, результат соотвествует

Писатели вивадовского симулятора, кстати, тоже не смогли соответствовать стандарту, и меняют местами блокирующие присванивания на неблокирующие и наоборот как им заблагорассудится. Может быть и в синтезаторе они так же сделали. Поэтому, возьмите любое руководство по стилю кодирования от толковых компаний. Или прочитайте известнейшие в отрасли статьи, например, coding style that kills (http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA_rev1_2.pdf), и следуйте им.

[TRILLER 0]

Чтобы не плодить темы.. Столкнулся с совсему уж, на мой взгляд, непристойным поведением на этот раз синтезатора Vivado18.3.
Он игнорирует signed'()

bit  [2:0]  l_shift = 0;
bit  [1:0]  counter = 0;
bit  [3:0]  result[3];
bit signed [3:0] counter_sign;
 
always_ff @(posedge clk_100)
begin
if (rst) begin
    l_shift     <= 7;
    counter     <= 2;
end
end

always_comb
begin
    result[0] = signed'(counter) <<< l_shift[0];
    result[1] = (signed'(counter)) <<< l_shift[1];
    result[2] = counter_sign <<< l_shift[2];
end
      
assign counter_sign = signed'(counter);

По стандарту разницы между этими записями не должно быть никакой. Моделсим моделирует верно, но ошибка вылазит на железе!
Смотрю чипскопом. Очевидно, что знаковое расширение происходит только для counter_sign:
 

Спойлер

Поправьте, если ошибаюсь.
Это уже ни в какие ворота не лезет! Уж синтез-то должен работать.. Да, 18.3 версия старая, но ведь и не одна из первых - получается, эта жестокая ошибка присутствует там много лет. И ведь большинство разработчиков пользуется как раз-таки встроенным синтезатором! 🥴

[blackfin 16]

On 9/7/2023 at 7:21 PM, TRILLER said:

Он игнорирует signed'()

В Vivado пользуюсь $signed(). Вроде, работает.

[des00 25]

49 minutes ago, blackfin said:

В Vivado пользуюсь $signed(). Вроде, работает.

ну еще бы, функция с 1995го года не может не работать, это не модные свистопляски))

[TRILLER 0]

56 минут назад, blackfin сказал:

В Vivado пользуюсь $signed(). Вроде, работает.

Проверил - действительно работает! Аж полегчало, благодарю!
Осталось только нормально разобраться, в чём между ними разница, и можно жить дальше))

7 минут назад, des00 сказал:

ну еще бы, функция с 1995го года не может не работать, это не модные свистопляски))

Может можете сходу объяснить разницу?

[des00 25]

11 minutes ago, TRILLER said:

Может можете сходу объяснить разницу?

да нет между ними разницы, просто $signed это системная функция появилась в ревизии стандарта 1995 года (тут я ошибся), в 2001 году. IEEE Std 1364-2001, а signed'() квалификатор приведения типов это SystemVerilog IEEE-1800-2009 (хотя сам SV пошел с 2005 года)

Quote

NOTE—The $signed() and $unsigned() system functions (see 11.7) return the same results as signed'() and unsigned'(), respectively. 

с учетом того что вивада идет с 2014 года, скорее просто программисты забили на новые фенечки, а вот старые должны работать) Но вообще как бы 2018 вивада в 2023 году это уже очень старо. 

[TRILLER 0]

2 часа назад, des00 сказал:

да нет между ними разницы, просто $signed это системная функция появилась в ревизии стандарта 1995 года (тут я ошибся), в 2001 году. IEEE Std 1364-2001, а signed'() квалификатор приведения типов это SystemVerilog IEEE-1800-2009 (хотя сам SV пошел с 2005 года)

Ну "квалификатор приведения типов" очевидно /= понятию "системная функция". Да и в ряд ли бы вводили сущность с теми же функциями, но немного другим названием и синтаксисом.. 🤔  Ладно, придётся "покурить."

2 часа назад, des00 сказал:

Но вообще как бы 2018 вивада в 2023 году это уже очень старо. 

Я её не использую для работы. Так, только поэкспериментировать.. Такие вещи должны работать и там. А уж если с 14-го года до 18 не исправились, то и дальше скорей всего ситуация не изменится.

[RobFPGA 27]

10 hours ago, TRILLER said:

По стандарту разницы между этими записями не должно быть никакой. Моделсим моделирует верно, но ошибка вылазит на железе!
Смотрю чипскопом. Очевидно, что знаковое расширение происходит только для counter_sign:

Кажется мне что  вы смотрите что то не то.  Ну или это действительно глюк в 18-й Vivado. Так как  в v2022.2  все прекрасно и правильно синтезируется:

input  wire       shift,
input  wire [2:0] din  ,
output logc [7:0] dou0 ,
output logc [7:0] dou1 ,
...
  dou0 <= signed'(din)<<<shift ; // в страших битах dou0  получается  расширенный знак из din[2]  
  dou1 <=         din <<<shift ; // в страших битах dou1  нули   

 

[des00 25]

6 hours ago, TRILLER said:

Ну "квалификатор приведения типов" очевидно /= понятию "системная функция". Да и в ряд ли бы вводили сущность с теми же функциями, но немного другим названием и синтаксисом.. 

появилась типизация, появились к ней инструменты, коммитет по 1800 довольно гибок в этом вопросе)

[TRILLER 0]

4 часа назад, RobFPGA сказал:

Кажется мне что  вы смотрите что то не то.  Ну или это действительно глюк в 18-й Vivado. Так как  в v2022.2  все прекрасно и правильно синтезируется:

Не-не, точно то смотрю. В логике проекта вылезла ошибка, потом проверял тестом - приложил же скрин чипскопа..
Хм, 14 -> 18 - ошибка есть, 18 -> 22 - исчезла? Надо действительно скачать последнюю версию тогда уж.

[des00 25]

5 hours ago, RobFPGA said:

Кажется мне что  вы смотрите что то не то.  Ну или это действительно глюк в 18-й Vivado. Так как  в v2022.2  все прекрасно и правильно синтезируется:

2016.4

КосяГГ сэр)

[Alex77 4]

2018.3 / 2019.2 -хрень

2020.2 / 2021.2.1 / 2022.2 / 2023.1 - ОК

module buss (
    input  wire       shift,
    input  wire [2:0] din,
    output logic [7:0] dou0,
    output logic [7:0] dou1
);

always_comb
  begin
  dou0 <= signed'(din)<<<shift ; // в страших битах dou0  получается  расширенный знак из din[2]  
  dou1 <=         din <<<shift ; // в страших битах dou1  нули  
  end
endmodule 

Изменено 8 сентября, 2023 пользователем Alex77