Here is a real world example where this scheme is important. In your ASIC, you might instantiate multiple Intellectual Properties (IP) RTL. Each of these IP has a source synchronous clock and each of these clocks are asynchronous to each other with jitters. You need these clocks as reference for data sampling. So, there might not be an accurate sampling point for each of these interfaces.
We have many of these cases in our designs. We currently use C++ for the full chip verification language and we implemented the posedge/negedge/wait in a similar fashion using threads. But I believe C++ is an overkill for unit level testing, Verilog doesn't have enough constructs, and SystemVerilog is still inconsistent between the different simulation vendors. But ... vpi and verilog 95/2001 seems to be the lowest common denominator. So ... writing my testbench in ruby will definitely be the ultimate time saver to verify my designs. Calvin -----Original Message----- From: [EMAIL PROTECTED] on behalf of Suraj N. Kurapati Sent: Wed 8/15/2007 8:33 PM To: Discussion list for the Ruby-VPI project Subject: Re: ncverilog/cver seg faults wheninvoking Vpi::__extension__relay_verilog Calvin Wong wrote: > This test program introduces another scheme to handle multiple > atPosEdge/atNegEdge/wait routines in multiple threads using > cbValueChange callbacks for edge triggering and cbAfterDelay for > fixed wait times. IMHO this example is reinventing the wheel by diving too deeply into the project internals. I know the current Handle#posedge? and Handle#negedge? methods aren't very precise (they check the current value when invoked) but that can be fixed. So I am wondering, is there any particular reason, other than increased accuracy of value change / edge detection, for reimplementing the entire threading model in this example?
