1
동일한 트리거가있는 2 개의 항상 블록에 대해서는 평가 순서가 완전히 예측할 수 없음을 이해합니다.Verilog에서 항상 블록 내에서 트리거되는 항상 블록에 대한 평가 순서는 무엇입니까?
그러나, 내가 가진 가정 :
always @(a) begin : blockX
c = 0;
d = a + 2;
if(c != 1) e = 2;
end
always @(a) begin : blockY
e = 3;
end
always @(d) begin : blockZ
c = 1;
e = 1;
end
한다고 가정 블록 X가 먼저 평가합니다. blockX에서 d를 변경하면 즉시 blockZ로 이동합니까? 그렇지 않다면 blockZ는 blockY와 관련하여 언제 평가됩니까?
프로그래머의 본능은 이벤트의 순서를 스택으로 생각합니다. 여기에서 blockX를 평가하는 것은 blockZ에 대한 함수 호출과 같으며 코드에서 바로 뛰어 오르고 blockX를 평가합니다.
그러나 우리는 활성 이벤트 대기열, 즉 대기열을 호출하기 때문에 이것은 활성 이벤트 대기열의 뒷쪽에 대기하는 blockZ을 제안하며 100 % 보장됩니다. 트리거 된 항상 블록).
중급 가능성도 있습니다. 처음부터 마지막까지는 아니지만 예측할 수없는 임의의 순서로 평가됩니다.
이 예제에서 컴파일러가 런타임에 느끼는 방식에 따라 e의 가능한 모든 최종 값은 1,2 또는 3입니까?
물론 나는 이것이 끔찍한 스타일을 나타내는 것을 알고 있지만, 이런 종류의 행동에 대한 사양을 어디에서 찾을 수 있습니까?
'always @ (a) : blockX begin' 유효한 구문입니까? 나는 항상'@ (a) begin : blockX' (verilog 2001에서 어쨌든) – Eric
으로 생각했다. 당신이 말한 것처럼, 이것은 끔찍한 스타일이다. 첫 번째 블록은 명시 적으로 또는 via를 통해 감도 목록에'c'를 포함해야한다. '*'- 그러면 질문이 문제가됩니다. – Eric
이 질문은 실제 코드를 만드는 것보다 시스템 동작을 완전히 이해하는 정신에 더 가깝다고 생각합니다. 학생들은 포인터에 대한 (더 유용한) 포인터로 코드를 추적하고 일부 표현식의 결과가 무엇인지 평가하는 입문 프로그래밍 클래스와 같습니다. 그것은 좀 더 적용되었지만, 그 운동은 의도적으로 엄격하게 교육적이라는 것을 분명하게 알 수있을 정도로 충분히 컸습니다. 또한 @Eric, 구문 catch 덕분에! – Dragonsheep