From: Patrick S. <pat...@gm...> - 2014-04-08 21:11:35
|
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 |