[dxp 65]

Вот-вот, я и говорю костыль.

Вы можете написать:

 

reg slon;

 

assign slon = ...;

 

?

 

А:

 

logic mamont;

 

assign mamont = ...;

 

?

 

P.S. Внутри ПЛИС использую в основном bit по понятным причинам.

 

 

UPD.

 

А окрепшие умы вполне могут представить себе reg-провод, как постоянно открытую защелку.

Название reg объективно сбивает с толку тех, кто начинает изучать язык. Требуется некоторое время и усилия, чтобы в голове уложилось, что reg - это не регистр в контексте имплементации, а регистр в контексте конкретного поведенческого блока - он логически сохраняет значение между последовательными присвоениями (в т.ч. при циклическом выполнении блока), потому он и регистр. Понятно, что во времена создания языка автор вряд ли думал о том, что язык будет потом использоваться для синтеза цифровой логики, а в концепции симулятора у него получилось всё достаточно стройно. Т.ч. исторически сложилось так, но с позиции сегодняшнего дня это вряд ли можно признать красивым. Поэтому замена reg на logic выглядит вполне обоснованной. И если давать оценку в терминах "костыль", то костылём является как раз reg.

 

[SM 0]

А:

 

logic mamont;

 

assign mamont = ...;

 

А так могу, но в принципе не буду так делать, потому что для непрерывных присваиваний существует специальный wire, который, в случае ошибки - неправильного использования, мне просто не дадут использовать не там.

 

Насчет "почему он регистр", конечно, согласен, именно потому. Но я говорил пояснение именно с точки зрения пост-синтеза. А с точки зрения самого языка, да, конечно, Ваша правда. И, это вторая причина, не использовать там logic, кроме потенциальной путаницы.

[Golikov 0]

бороться с logic - это как бороться с типом auto в С. Сначала кажется что глупость придумали я так делать не буду, это все не правильно. А потом смотришь вокруг все используют, а ты сам уже старый и все про глупости рассказываешь:)

 

если что-то появляется, то это зачем то надо...

[SM 0]

бороться с типом auto в С

А в C такого типа и нет, чего с ним бороться-то ;)

Собственно, как и "logic" в верилоге.

[ViKo 1]

Отцы-основатели в SV ввели logic, чтобы не конфузить пользователей Verilog с его reg. И дополнительно ввели понятия variable types и data types.

Variable: var, wire

Data: 2-state - bit, byte, int, ... 4-state - logic, integer, time

Строго, задавать нужно оба типа. Но можно опустить один из них (извращение, идущее от Verilog)

var logic - var, logic

wire logic - wire

[dxp 65]

А так могу, но в принципе не буду так делать, потому что для непрерывных присваиваний существует специальный wire, который, в случае ошибки - неправильного использования, мне просто не дадут использовать не там.

Это ваша интерпретация, не более. logic (как и bit) вполне пригоден для непрерывного присваивания, он введён в том числе и для этого тоже. wire может оказаться несколько избыточным там, где не требуется его полный функционал (например, моделирование с учётом коллизий, когда сигналы борются), а это ведёт к повышению требований к вычислительным мощностям. Зачем вообще придумали разные типы для описания сигналов? Сделали бы один, который мог всё, и праздник. При условии, что вычислительный ресурс неограничен.

 

Удобство logic и bit в том, что не нужно переопределять тип, когда хочется перейти от assign к always_comb (или наоборот).

 

Про ошибки - покажите пример (желательно поближе к реальности), где возникает ошибка из-за использования logic и где такой ошибке нет, если использовать wire?

[Golikov 0]

где возникает ошибка из-за использования logic и где такой ошибке нет, если использовать wire?

это просто:) Возьмите verilog, а не SV и напишите логик, и будут у вас ошибки, напишите wire и ошибки пропадут:))))

 

А по жизни появился новый тип, с учетом опыта прошлых лет. И если его сделали автоопределяющимся то значит ситуации его контекстного определения однозначны.

 

 

кстати а если сделать logic и в начале его использовать как wire, а в середине программы начать использовать как reg ошибки будут?

[SM 0]

Про ошибки - покажите пример (желательно поближе к реальности), где возникает ошибка из-за использования logic и где такой ошибке нет, если использовать wire?

Я говорил про ошибку, если я случайно типу reg задумаю сделать непрерывное присваивание, и, наоборот, типу wire попытаюсь что-то присвоить в блоке always. Это выявит компилятор (или синтезатор). Как я такую ошибку могу привести в пример? Они тучу раз возникали по случайности, и я их исправлял.

[Opex 0]

Я говорил про ошибку, если я случайно типу reg задумаю сделать непрерывное присваивание, и, наоборот, типу wire попытаюсь что-то присвоить в блоке always. Это выявит компилятор (или синтезатор). Как я такую ошибку могу привести в пример? Они тучу раз возникали по случайности, и я их исправлял.

 

Так можно использовать always_ff и always_comb, они и гарантируют защиту от таких ошибок, да и от некоторых других.

[SM 0]

они и гарантируют защиту от таких ошибок

Не от таких, не от смысловых. А от "latch inferred" там, где он не хотелся. Вот это, действительно, полезно - не надо варнинги анализировать.

[dxp 65]

это просто:) Возьмите verilog, а не SV и напишите логик, и будут у вас ошибки, напишите wire и ошибки пропадут:))))

Так это ошибки компиляции. А речь об ошибках проектирования. Вопрос был: где тип logic провоцирует ошибки работы описываемого, а wire/reg позволяют этого избежать?

 

кстати а если сделать logic и в начале его использовать как wire, а в середине программы начать использовать как reg ошибки будут?

А разве позволяется использовать один и тот же объект в continuous и behavioral конекстах?

 

Я говорил про ошибку, если я случайно типу reg задумаю сделать непрерывное присваивание, и, наоборот, типу wire попытаюсь что-то присвоить в блоке always. Это выявит компилятор (или синтезатор). Как я такую ошибку могу привести в пример? Они тучу раз возникали по случайности, и я их исправлял.

Так это ошибки компиляции. Это и ошибками считать ни к чему. Ошибки - это когда спроектированное работает не так, как задумано. Вот про это и вопрос был - где reg/wire предупреждают такие ошибки, а logic нет?

[SM 0]

Ошибки - это когда спроектированное работает не так, как задумано. Вот про это и вопрос был - где reg/wire предупреждают такие ошибки, а logic нет?

 

Задумывая в схеме изначально сигнал как wire, что к нему буду подключать несложную комбинаторную функцию, я его и объявляю как wire. А потом, забыв об этом под конец тяжелого трудового дня, присваиваю в блоке always @(posedge. И получаю ошибку компиляции, которая быстро освежает память. И, наоборот, задумывая сигнал как FF, по той же случайности присваиваю ему что-то постоянно, в результате, он получился бы на такт раньше, чем надо... И опять компилятор сразу тыкает носом в ошибку. А, ведь, именно такие "описки" выедают весь мозг при отладке, что приходится аж до использования моделировщика доходить...

 

А сложная комбинаторика в always @*, это, скорее исключение... Такой комбинаторики в моих проектах обычно очень мало, и она со всех сторон обкомментирована, что это, зачем, и почему в always. Чаще всего в такие блоки попадает тяжелая, хитровыделанная арифметика с использованием блокирующих присваиваний.

[dxp 65]

Задумывая изначально сигнал как wire, что ему буду присваивать несложную комбинаторную функцию, я его и объявляю как wire. А потом, забыв об этом под конец тяжелого трудового дня, присваиваю в блоке always @(posedge. И получаю ошибку компиляции, которая быстро освежает память. И, наоборот, задумывая сигнал как FF, по той же случайности присваиваю ему что-то постоянно, в результате, он получился бы на такт раньше, чем надо... И опять компилятор сразу тыкает носом в ошибку. А, ведь, именно такие "описки" выедают весь мозг при отладке, что приходится аж до использования моделировщика доходить...

Что-то я не улавливаю проблемы. Если мне нужен FF, то я обязательно буду писать always_ff и использовать "<=" присваивание. Если мне нужна логика, то это будет либо assign, либо always_comb и "=" присваивания. Как тут можно что-то напутать? Это ведь осмысленные действия. И если я передумал и решил сигнал из триггера сделать комбинационным (или наоборот), то я просто беру и переписываю контекст его использования, и не возникает необходимости ещё и его объявление менять. Это не может быть случайной ошибкой по недосмотру.

 

 

А сложная комбинаторика в always @*, это, скорее исключение... Такой комбинаторики в моих проектах обычно очень мало, и она со всех сторон обкомментирована, что это, зачем, и почему в always. Чаще всего в такие блоки попадает тяжелая, хитровыделанная арифметика с использованием блокирующих присваиваний.

Хм, у меня как-то наоборот - в assign'ах живёт что попроще, а если логика какая-то более замороченная, то это уже always блок.

[SM 0]

Что-то я не улавливаю проблемы. Если мне нужен FF, то я обязательно буду писать always_ff и использовать "<=" присваивание.

Ага. Об этом помнишь, допустим, первые пятнадцать часов, после того, как всю схему продумал в общем. А потом, когда дело доходит до описания этого места, просто ошибаешься, по забывчивости, и делаешь не то, или просто путаешь с другим участком схемы. Поэтому я сначала описываю все необходимые в схеме основные сигналы, как wire и как reg, а потом это упрощает жизнь.

 

Хм, у меня как-то наоборот - в assign'ах живёт что попроще, а если логика какая-то более замороченная, то это уже always блок.

Чего наоборот то? У меня тоже в ассигнах что попроще. А сложная, тяжелая логика, описанная в always, это редкое исключение, такая логика без регистра на выходе - большая редкость.

[FatRobot 4]

см. two process fsm coding

 

А сложная комбинаторика в always @*, это, скорее исключение... Такой комбинаторики в моих проектах обычно очень мало, и она со всех сторон обкомментирована, что это, зачем, и почему в always. Чаще всего в такие блоки попадает тяжелая, хитровыделанная арифметика с использованием блокирующих присваиваний.