Calvin Wong wrote:
> I know this is going to be a lot to ask, but have you thought
> about creating a threading methodology for synchronizing two
> ruby processes.
I've implemented this feature and checked it into the head of the
project's Darcs repository. Runtime performance is slightly reduced
(for now) but that's a small price to pay for such a phenomenal
advancement! :-)
> Essentially I want to do the following in ruby.
>
> module test;
> reg clk; initial clk = 0;
> dut dut_inst (.clk_input(clk));
>
> initial forever #5 clk = ~clk;
>
> initial
> begin
> repeat (5) @(posedge clk);
> $display("Five cycles have passed");
> repeat (5) @(posedge clk);
> $display("Another five cycles have passed");
> end
>
> endmoule
Here is how I tested your example:
1. Create a 'test.v' file with the following content:
module test;
reg clk; initial clk = 0;
endmodule
2. Generate a Ruby-VPI test for that file:
ruby-vpi gen test.v
3. Replace the 'test_spec.rb' file's content with:
Thread.new do
loop do
wait 5
Test.clk.intVal += 1
end
end
Thread.new do
5.times do |i|
wait until Test.clk.posedge?
puts "@#{simulation_time} got posedge #{i}"
end
puts("Five cycles have passed");
5.times do |i|
wait until Test.clk.posedge?
puts "@#{simulation_time} got posedge #{i}"
end
puts("Another five cycles have passed");
finish
end
Notice the two new methods in the above code: "wait" and "finish".
* "wait" is just an alias for the "advance_time" method.
* "finish" stops the whole simulation. Without it, the second
thread would exit after it finished and the first thread would
continue executing forever (since its body contains an infinite loop).
If you're not using any threads (like the default examples that come
with Ruby-VPI), then there's no need to put "finish" at the bottom
of the spec.rb file. Otherwise, you've got to make sure that your
code has a "finish" call somewhere.
Also, there is something to be said about the concurrency model.
During each time step, all threads are executed until they either
(1) finish executing and exit normally or (2) invoke the "wait" or
"advance_time" method -- which causes them to be re-executed at a
future time step.
Anyway, try this out and let me know how it works.
Cheers,
Suraj
