Re: [Iverilog-devel] Infinite loop on simulation

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

What is gate level to you and why do you want to do this at the gate level? Verilog primitive gates are not the same as the gates provided by a cell library. A cell library almost certainly has flip-flops and other more complicated gates. Verilog has a very limited number of primitive gates. At the gate level latches and flip-flops are usually modeled in Verilog using UDPs. Generation of a high quality UDP is not a trivial task and often involves making tradeoffs.

Two series D latches make a D flip-flop if the clock is inverted, though without some delay you can have a data/clock race condition between the first and second latch.

Verilog is fine for gate level modeling, though RTL is usually much fast to simulate and allows the design to be synthesized.

Cary

On Tuesday, April 8, 2014 2:11 PM, Patrick Samy <pat...@gm...> wrote:

2014-04-08 19:37 GMT+02:00 Cary R. <cy...@ya...>:
> This is a problem in your design/test setup. I could tell you the problem
> and I will if you really want, but a better way is to learn some debugging
> techniques.

Definitely, it will be good to try and find out the issue by myself.

> Adding the following line to the register module will show you the state of
> the bits driving the latch element:
>
> always @(qi, not_qi) $display($time,, in,, set,, qi,, not_qi);
>
> If you don't know, in the Icarus run time (vvp) ^C followed by finish<CR>
> will stop the simulation. What pattern do you see? The key question here is
> why is "in" toggling? The answer to that is found by evaluating the
> connection of the gates at the test level when the top level "in" == 0
> (which is not the same as the register "in" signal).

Indeed, I can see that the value is oscillating and I understand why.

> If your gates had some delay the simulation would not lock up at a specific
> time step, but it will not stop either. You would need to end the test block
> with clock == 0 or add an explicit $finish.
>
> One significant point of clarification. Your register block is not a S/R
> flip-flop or even a S/R latch. It is a S/R latch with some extra control
> logic to make it act like a D latch. This latch is transparent when the
> enable (set pin) is high. It is not edge sensitive like a D flip-flop. I
> believe the problem you are experiencing is because you are using a latch
> like a flip-flop, which as you have discovered doesn't work very well.

I see the problem here.

My goal was to do everything at the gate-level for the whole CPU
design but it doesn't seem to be feasible since, in this case, you
would need a way to wire the latch so that the value is stored only on
the rising edge, which is essentially what the @(posedge clk)
statement does.

What if I add a second latch that keeps the previous value and when
the latches outputs are different, a signal acts as a feedback loop
and prevent first latch to be written again, until the next falling
edge ?

A good thing to ask, maybe: is Verilog the right tool for _gate-level
only_ modeling ?

> I hope that helps.

Very much, thank you for your time.
-- 
Patrick Samy

> On Tuesday, April 8, 2014 9:16 AM, Stephen Williams <st...@ic...>
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Just quickly looking at this...
>
> It appears that you've created an infinitely fast oscillator.
> I think you are trying to create an SR flip-flop with the last
> two nand gates in your register module, but instead you are getting
> meta-stability.
>
> Synchronous logic is not typically modeled in Verilog this way.
> This looks like an educational exercise, so you might try getting
> more realistic relative timings.
>
> What are you really trying to do?
>
> On 04/08/2014 03:50 AM, Patrick Samy wrote:
>> Hello,
>>
>> When I perform a simulation of my design with iverilog 0.9.7, it
>> seems to be stuck in an infinite loop.
>>
>> The original design is a program counter adder with the following
>> prototype:
>>
>> module program_counter(input enable_count, input enable_overwrite,
>> input[31:0] overwrite_value, output[31:0] out);
>>
>> I managed to simplify the verilog testbench code with a D flip flop
>> as a 1-bit register and reproduce the issue:
>>
>> module register(input in, input set, output out);
>>
>> wire not_in; wire qi; wire not_qi; wire not_q;
>>
>> nand (qi, in, set);
>>
>> not  (not_in, in); nand (not_qi, not_in, set);
>>
>> nand (out, qi, not_q); nand (not_q, not_qi, out);
>>
>> endmodule
>>
>> module test;
>>
>> reg  clock; reg  in; wire out; wire not_out;
>>
>> // add 'x_out <- out + 1' xor (x_out, out, 1);
>>
>> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
>> x_out, in);
>>
>> register r(muxed_out, clock, out);
>>
>> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
>>
>> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
>> in, out);
>>
>> // erase internal register #0 in = 1; #0 clock = 1;
>>
>> #1 in = 0; #1 clock = 0;
>>
>> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
>>
>> endmodule
>>
>>
>> The VCD output does not show any change of state after the #2
>> tick: in== 0 clock == 1
>>
>> Therefore, the register is continuously feeded with the result of
>> the adder and my guess is that icarus is waiting for the values to
>> stabilize for this tick and gets stuck.
>>
>> Can you spot a potential issue with this design ?
>>
>> I also posted the issue on StackOverflow to make sure that code is
>> correct:
>>
>> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>>
>>  Thanks and apologies in advance if this is a stupid mistake on my
>> side, I spent a week trying to figure it out by myself without
>> success.
>>
>> Regards,
>>
>
>
> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com          But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
> gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
> =p4NY
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

>

-- 
Patrick Samy