[RobFPGA 35]

5 minutes ago, dxp said:

Кстати, а вот тут может работа в 32-битных (интах) целых может оказаться эффективнее для симулятора - не надо эмулировать нестандартную ширину.

Может быть. Но для обычного logic это не сильно ускоряет, ведь  значений у каждого бита может быт 4.  Именно для этого и ввели bit и производный от него int. 

[Flip-fl0p 4]

Ругаться на разрядость нужно и правильно. Ибо ошибки при переполнениях разрядностей - одни из самых сложно обнаруживаемых. 

[dxp 65]

С чего это переполнение разрядности является ошибкой? Часто это штатное поведение - например, тот же банальный free-running counter.

[Flip-fl0p 4]

30 минут назад, dxp сказал:

С чего это переполнение разрядности является ошибкой? Часто это штатное поведение - например, тот же банальный free-running counter.

Когда это осознано переполняется - это не ошибка. Как Ваш пример с счетчиком. Когда происходит переполнение из-за того, что разрядность была неверно рассчитана - то это очень больно.

[dxp 65]

И как вы будете эти случаи различать?

 

А если по логике задания сигнал может быть только 5 и 10, а 7 и 2 быть не может, это ошибка, то как эту ситуацию обходить?

 

То, что вы хотите, на SV достигается с помощью SVA.

[RobFPGA 35]

22 minutes ago, Flip-fl0p said:

Когда это осознано переполняется - это не ошибка. Как Ваш пример с счетчиком. Когда происходит переполнение из-за того, что разрядность была неверно рассчитана - то это очень больно.

Очень  больно это будет если не верифицировать дизайн,  а надеется что "...и так сойдет" и язык не даст ошибиться.  И не только из за переполнения.  
В том то и проблема что формально синтезатору очень тяжело определить есть ли тут опасное переполнение или так и задумано дизайнером.
Отсюда разные подходы  - либо ошибкой считается все что явно не разрешено как в VHDL,  либо по умолчанию приведение разрядности как в V/SV (и максимум варнинг по желанию капризного тулза).
 
IMHO может подход VHDL и был оправдан в прошлом (или для очень ответственных применений со строгой формализацией), но в текущей действительности при развитии технологии и методик верификации дизайна и симуляторов как по мне получается лишняя работа и нагрузка разработчику. Которая перекрывается правильно организованной верификацией.

Популярность же обоих подходов среди разработчиков вы можете наблюдать по числу вакансий  для того или другого языка 

 

[Flip-fl0p 4]

44 минуты назад, RobFPGA сказал:

Очень  больно это будет если не верифицировать дизайн,  а надеется что "...и так сойдет" и язык не даст ошибиться.  И не только из за переполнения.  
В том то и проблема что формально синтезатору очень тяжело определить есть ли тут опасное переполнение или так и задумано дизайнером.
Отсюда разные подходы  - либо ошибкой считается все что явно не разрешено как в VHDL,  либо по умолчанию приведение разрядности как в V/SV (и максимум варнинг по желанию капризного тулза).
 
IMHO может подход VHDL и был оправдан в прошлом (или для очень ответственных применений со строгой формализацией), но в текущей действительности при развитии технологии и методик верификации дизайна и симуляторов как по мне получается лишняя работа и нагрузка разработчику. Которая перекрывается правильно организованной верификацией.

Популярность же обоих подходов среди разработчиков вы можете наблюдать по числу вакансий  для того или другого языка 

 

VHDL местами сильно утомляет. Особенно строчки вида :

 

if (TX_ena = '1') then 
    PHS_TX_o(to_integer(CH_cnt))  <= std_logic_vector(unsigned(PHS_TX(to_integer(CH_cnt))) + PHS_cnt);
end if;

Хотелось бы конечно в VHDL иметь более простую и компактную запись как в SV/V

if (TX_ena = '1') then 
    PHS_TX_o[CH_cnt]  <= PHS_TX[CH_cnt] + PHS_cnt;
end if;

[Nick_K 0]

3 hours ago, dxp said:

А Quartus вполне приличный тул, и поддержка того же SV в нём началась раньше и была лучше, чем в Synplify

Так как я не сильно пользовался Квартусом, не могу предъявить сильные аргументы против него (но могу сказать, что Sinplify и вправду хорош).

Но ребята пользуются Альтеровскими чипами и говорят, что там даже банальное always_comb не работает как нужно (есть подозрение, что это про какие-то вложенные конструкции).

Из-за чего во всём коде после прототипинга стоят always@*, которые потом синтезируются трудноуловимыми Латчами.

Вот такие дела)

[des00 25]

11 minutes ago, Nick_K said:

Но ребята пользуются Альтеровскими чипами и говорят, что там даже банальное always_comb не работает как нужно (есть подозрение, что это про какие-то вложенные конструкции).

Из-за чего во всём коде после прототипинга стоят always@*, которые потом синтезируются трудноуловимыми Латчами.

99% понаделают структур, с разными присваиваниями полей, вот и не проходят проверку. 

[Самурай 12]

50 минут назад, Flip-fl0p сказал:

VHDL местами сильно утомляет. Особенно строчки вида :

 

if (TX_ena = '1') then 
    PHS_TX_o(to_integer(CH_cnt))  <= std_logic_vector(unsigned(PHS_TX(to_integer(CH_cnt))) + PHS_cnt);
end if;

Просто интереса для: а что мешает сразу сделать CH_cnt типом integer, а PHS_TX типом unsigned?:)

[Jackov 1]

10.02.2022 в 14:17, МАСТЕР LO сказал:

По-скольку я начинающий, мне просто не хватает знаний, что бы понять код элементарного двоичного счётчика.

Рекомендую навернуть этот плейлист

https://www.youtube.com/playlist?list=PL4UMfOeGYsvblwrP3VYKHq11xgkxVqoUj

 

[Flip-fl0p 4]

16 минут назад, Самурай сказал:

Просто интереса для: а что мешает сразу сделать CH_cnt типом integer, а PHS_TX типом unsigned?:)

PHS_TX - формируется IP ядром virtual_IO. Тип данных std_logic_vector.

CH_cnt = это полный счетчик от 0 до 7. Описание такого счетчика через integer требует обязательного условия обнуления, иначе на моделировании будут выходить ошибки о том, что превышен диапазон:

CH_cnt <= CH_cnt + 1; -- Будет ошибка ухода за диапазон значений 0 to 7

 

Просто так писать нельзя, потому-что мы добавляем доп. условие сброса, которое синтезатор не выкинет, а оно по сути не нужно

if (CH_cnt = 7) then  -- Ошибки не будет. Но будет лишнее условие сброса, которое синтезатором не оптимизируется
    CH_cnt <= 0;
else
    CH_cnt <= CH_cnt + 1;
end if;

 

 

[new123 0]

1 hour ago, des00 said:

99% понаделают структур, с разными присваиваниями полей, вот и не проходят проверку. 

а чем грозит такой подход? у меня как раз в одном месте такое. Поля типа logic. Какие то поля делаю always (clk)  .field <= value_1, а какие то поля assign .field = value_2

Изменено 11 февраля, 2022 пользователем new123

[Самурай 12]

1 час назад, Flip-fl0p сказал:

PHS_TX - формируется IP ядром virtual_IO. Тип данных std_logic_vector.

CH_cnt = это полный счетчик от 0 до 7. Описание такого счетчика через integer требует обязательного условия обнуления, иначе на моделировании будут выходить ошибки о том, что превышен диапазон

Понятно, спасибо! С integer-ом известная проблема, но как по мне, лучше добавить проверку и сброс в самом счетчике, да и кратность степени двойки это частный случай, особенно если потом максимальное значение может быть изменено...

[Flip-fl0p 4]

9 минут назад, Самурай сказал:

Понятно, спасибо! С integer-ом известная проблема, но как по мне, лучше добавить проверку и сброс в самом счетчике, да и кратность степени двойки это частный случай, особенно если потом максимальное значение может быть изменено...

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