Menu
▾
▴
Re: [Iverilog-devel] Infinite loop on simulation
|
From: Patrick S. <pat...@gm...> - 2014-06-06 17:27:18
|
2014-04-08 22:39 GMT+01:00 Cary R. <cy...@ya...>: > 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. For me gate level was using only primitive gates that are built into the language. I am describing a CPU by writing each component with these primitives. This exercise is mostly for self-educational purposes and I felt that if I was using RTL, I wouldn't be close enough to the bare transistor to understand what is happening underneath my Verilog code. Essentially, I wanted to write the gate level code that the simulator would generate from the RTL description. > 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. Indeed, I had completely forgotten my digital systems basics and now I see why the D latch, which is not edge-triggered, implies that I would get an infinitely fast oscillator. I studied in France originally and I guess I also got confused in the translation :) With a D flip-flop, the system now behaves as expected. Of course, I had to express my test cases differently by introducing a delay to ensure that the input value is set before I enable writing on the register. The original code that I fixed is here: https://github.com/patrick-samy/ace/blob/master/data/program-counter.v > Verilog is fine for gate level modeling, though RTL is usually much fast to > simulate and allows the design to be synthesized. Now I understand why having the RTL abstraction is useful and how it helps solving some issues. Sorry for the response delay, I didn't have time to work much on this in the past few weeks. Thanks to everyone for your help. Patrick > 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 > > -- Patrick Samy |
