Jump to content
    

Непрерывное присвоение на Verilog

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

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

 

reg slon;

 

assign slon = ...;

 

?

 

А:

 

logic mamont;

 

assign mamont = ...;

 

?

 

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

 

 

UPD.

 

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

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

 

Share this post


Link to post
Share on other sites

А:

 

logic mamont;

 

assign mamont = ...;

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

Отцы-основатели в 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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

 

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

см. two process fsm coding

 

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...