Subject: [sv-ac] Re: nonblocking assignment in clocking block.
From: Adam Krolnik (krolnik@lsil.com)
Date: Thu Sep 18 2003 - 09:08:48 PDT
Hi Surrendra.
On your proposal for nonblocking assignments inside clock domains.
This may need to be evaluated by sv-ec. We don't have much expertise
in verilog clocking domains.
I would not support such a limited proposal. Your examples demonstrate
how limited it is.
int in_progress;
clocking clk1 @(posedge clk);
output in_progress;
in_progress <= !sample_not_resetting ? 0
: ($rose(start_expr) && (in_progress == 0) && !(test_expr == 1'b1)
? 1 : (test_expr == 1'b1)
? 0 : (in_progress < max_cks) && (in_progress > 0)
? in_progress+1 : 0;
endclocking
clocking clk1 @(posedge clk);
output head_ptr; // Should this be ova_v_head_ptr, matching the values below?
head_ptr <= (reset) ? 0
: (s_deferred_deq.ended && (ova_v_q_size > 0) )
? ((ova_v_head_ptr < depth-1)
? (ova_v_head_ptr + 16'b1) :16'b0)
: ova_v_head_ptr;
endclocking
While this may actually work (this is too complex of an expression) it is
unnecessarily complicated because there are no other constructs to make
it simpler.
1. Use of case/if statements would go a long way toward readability and
maintainability!
2. Allowance of if() would provide for conditional update as possibly
seen in the second example - only updating (ova_v_) head_ptr if necessary.
3. Use of always blocks is better to model additional logic.
In analyzing the first example, it appears to be a translation from OVL or similar
definition for a time bounded window pattern. This brings up an interesting need.
The need to detect a property executing but not passing/failing.
It appears the first example wants to say something like:
property one_in_window
(start, test, max_clk, clk, rst)
($rose(start) & !one_in_window.running // Only allow one to start!
|-> ##[1:max_clk] test ##1 ! test)
endproperty
I would support a method call for this ability! It is a common occurrence that is
difficult otherwise to do. Maybe this method call should return the number of
currently executing threads of the property. This would provide double duty to
allow one to:
A. only allow one thread to start.
B. report an error when a thread is started and another start event occurrs.
C. report an error when too many threads are started.
I would only support an enhanced version of this proposal as it will create
assertion code that is as difficult to read and understand as the design code
it is trying to validate. When the code is difficult to understand it becomes
exponentially more difficult to make it correct.
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Thu Sep 18 2003 - 09:35:02 PDT