Verilog: использование регистра: когда значения на самом деле обновляются? - PullRequest
0 голосов
/ 02 мая 2020

Когда именно обновляются переменные внутри всегда блока в Verilog? Например, если reg C изменяется многократно в блоке всегда: значение всегда меняется? Или значение только «физически записано» в регистр в конце блока всегда?

Было бы лучше использовать дополнительный промежуточный регистр, который актуализируется только в конце блока всегда? Будет ли это иметь какое-то значение?

reg C;

always @(*)
C = 0;
C = A;
C = 1;
C = B;
end

Другой пример: если у меня есть модуль с блоком всегда, как показано ниже, могут ли множественные назначения вывода проявлять своего рода сбой, когда вывод быстро переходит к 0 до получения значения B? Имеет ли значение, если я использую блокирующие (=) или неблокирующие (<=) назначения? </p>

module example1 (output C, input A, input B);

always @(*)
begin
 C = 1’b0;
 if (A==1)
   C = B ;
end
endmodule

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

module example1 (output C, input A, input B);

reg intermediateReg;

always @(*)
begin
 intermediateReg = 1’b0;
 if (A==1)
   intermediateReg = B ;
end
   C <= intermediateReg;
endmodule

Ответы [ 2 ]

0 голосов
/ 02 мая 2020

В приведенных вами примерах код ведет себя идентично коду c. Переменная получает переназначенные новые значения и последнее выигрывает. В verilog это верно для блокирующих (=) или неблокирующих (<=) назначений, но не для их сочетания. </p>

Как и в 'c', это зависит от техники оптимизации компилятора. Это может устранить ненужные назначения, поэтому релевантным является только последнее.

В вашем первом примере значение 'C' будет равно 'B' в конце блока. Значение 'C' во втором примере будет либо 0, либо B, в зависимости от A.

Теперь, для простоты объяснения, смешивание блокировки и неблокирующие назначения вызовут последний выигрыш «неблокирующих» назначений. Причина в том, что все nba выполняются после завершения блока.

always @(*) begin
   C <= A;
   C = B;
end

Значение C будет A в конце цикла моделирования.

Что касается вопроса об использовании промежуточных значений, то здесь нет разницы. Вы используете их по мере необходимости. Компилятор симуляции или синтез оптимизирует ваш код в любом случае. Последний пример абсолютно нормален, за исключением того, что он вообще ничего не меняет. Он ведет себя так же, как и этот, который, на мой взгляд, более явный и более читаемый. Единственная проблема заключается в том, что вы неправильно используете назначения nba в комбинационной логике c (что я исправил).

always @(*)
begin
 if (A==1)
   C = B ;
 else
   C = 1'b0;

Полагаю, в вашем посте есть еще один немой вопрос, будет ли промежуточное значение вызывать события на ' C ', ответ в этом случае нет . События не будут производиться блоком Always до тех пор, пока он не завершит свое выполнение (или пока он не достигнет задержки или не начнет ожидать события). Итак, релевантно только последнее значение.

В коде тестового стенда вы можете увидеть такую ​​ситуацию:

always @* begin
   C = A;
   C = B;
   #5 C = D;
end

В приведенном выше случае значение C станет B. Выполнение блока Always будет остановлено из-за задержек # 5. В течение этого времени другие блоки будут видеть значение B. В тиках # 5 значение будет изменено на D.

0 голосов
/ 02 мая 2020

Если вы хотите знать, что делают блокирующие и неблокирующие назначения в стандартном Verilog (как это было бы при моделировании), вы можете легко это найти.

Если вы говорите об оборудовании, Тип получаемого оборудования будет зависеть от того, что находится в списке чувствительности, а не от типа используемых вами назначений. Тип назначения будет влиять на комбинационную логику c, которая синтезируется из вашего кода. Предполагая, что вы не делаете ничего несинтезируемого, логика c, которую вы получаете, должна быть эквивалентна той, что указан в стандарте Verilog, но не будет прямым отображением вашего кода 1: 1.

Так что нет, добавление промежуточных соединений не обязательно поможет с глюками в оборудовании. Будут другие спецификации кода и синхронизации, и т. Д. c. для того, чтобы иметь дело с такими вещами.

...