Verilog LRM Недетерминизм - PullRequest
Новая
       49

Verilog LRM Недетерминизм

1 голос
/ 17 февраля 2020

У меня возникают некоторые сомнения относительно недетерминизма в семантике планирования Verilog, упомянутой в Verilog LRM. Ниже приводится выдержка, которую я не могу понять:

"Другой источник недетерминизма состоит в том, что операторы без конструкций контроля времени в поведенческих блоках не должны выполняться как одно событие. Время управляющими операторами являются конструкции # expression и @ expression (см. 9.7). В любой момент при оценке поведенческого оператора симулятор может приостановить выполнение и поместить частично завершенное событие как ожидающее активное событие в очередь событий. чтобы разрешить чередование выполнения процесса. Обратите внимание, что порядок чередующегося выполнения не определен c и не контролируется пользователем. "

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

Кроме того, я не понимаю строка «заявления без контроля времени» конструкции в поведенческих блоках не должны выполняться как одно событие ». Что означает LRM, говоря, что он не выполняется как одно событие, и что произойдет, если поведенческий блок будет содержать все контролируемые по времени операторы?

Может кто-нибудь объяснить это с помощью некоторых примеров? Заранее спасибо.

1 Ответ

2 голосов
/ 17 февраля 2020

Единственное, что гарантирует симуляция, это то, что все операторы в блоках всегда будут выполняться последовательно. Скажем, как в следующем блоке: 

always @(b,c,e,f) begin
   a = b | c;
   d = e & f;
   g = a ^ d ^ x;
   ...
end

Однако симулятор может принять решение выполнить первые 2 оператора подряд, но затем остановить выполнение этого блока перед последним оператором и позволить другим блокам продолжить. Затем он вернется к последнему утверждению. В этом смысле у вас есть неопределенный c порядок выполнения операторов.

Угадайте, что ?! Значение x может определенно измениться во время ожидания. a и d потенциально могут также измениться при выполнении других операторов. Таким образом, результат g может быть недетерминированным c. Хорошее программирование поможет устранить этот тип недетерминизма: перечислить все события в списке чувствительности, не использовать сигналы с несколькими приводами ... Затем симулятор сделает все возможное, чтобы избежать таких ситуаций.

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

Ответ на комментарий о контроле времени и событий

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

Контроль времени и задержки обеспечивает определение c остановок. Например, 

always @(b,c,e,f) begin
   a = b | c;
   d = e & f;
   #1 g = a ^ d ^ x;
   ...
end

В приведенном выше операторе с #1 вы на самом деле говорите симулятору прекратить выполнение операторов и дождаться следующего такта. 

always @(b,c,e,f) begin
   a = b | c;
   d = e & f;
   @(posedge clk)
   g = a ^ d ^ x;
   ...
end

Здесь он остановит выполнение и будет ждать события posedge clk.

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

...