( ESNUG 468 Item 4 ) -------------------------------------------- [09/13/07]
Subject: ( ESNUG 467 #5 ) Janick caught this gotcha in his book last year
> In Section 2.8 of Stu & Don's paper, the following code as a gotcha:
>
> always @(a or b) begin
> for (i=0; i<15; i=i+1) // this process uses i
> ...
> end
>
> always @(c or d) begin
> for (i=0; i<15; i=i+1) // this process also uses i
> ...
> end
>
> However this is not uncommon at all, and I have never seen this causes any
> simulation or synthesis problems. Although in theory it is bad.
>
> Can anyone give an example that this type of coding causes real problems?
From: Janick Bergeron <janick.bergeron=user domain=synopsys not calm>
Hi, John,
It is not a problem in RTL code as the body of the "always" block cannot
contain any blocking statements. Thus the entire for-loop runs as an
atomic operation and the fact that the variable "i" is shared is hidden
as a side-effect.
But in transaction-level models or testbenches, where there can be a
blocking statement in the body of the for-loops, this will cause the each
loop to interfere with each other, each incrementing the same index in
competition with the other.
The RTL coding style saves a lot of headache but hiding a lot of the
Verilog simulation intricacies that get exposed when coding testbenches
or reference models.
That very gotcha was covered in Sample 4-9,10 in my "WTB using SV" book
and was actually in the first edition.
- Janick Bergeron
Synopsys, Inc. Ottawa, Canada
Index
Next->Item
|
|
