Self-oscillation in simulating

[Altera_Forum]

Hi every one. 

I wrote a verilog fifo including the following line: always @(posedge read or posedge write or negedge rst) begin  if(!rst)usedw<=8'h0;  else if(read==1'b1)begin  usedw <= usedw - 8'h1;  end  else if(write==1'b1)  begin  usedw <= usedw +8'h1;  end end When siimulating with Modelsim some strange thing happend that all the element usedw[] of usedw ware like self-oscillaton. Is there any one who can tell me what's the reason? An Altera's supportor said to me that it can be solved by adding contraints to the project.But I got the same results when I addeed sdc files. Looking for help from you.

[Altera_Forum]

--- Quote Start ---  Hi every one. I wrote a verilog fifo including the following line: always @(posedge read or posedge write or negedge rst) begin if(!rst)usedw<=8'h0; else if(read==1'b1)begin usedw <= usedw - 8'h1; end else if(write==1'b1) begin usedw <= usedw +8'h1; end end When siimulating with Modelsim some strange thing happend that all the element usedw[] of usedw ware like self-oscillaton. Is there any one who can tell me what's the reason? An Altera's supportor said to me that it can be solved by adding contraints to the project.But I got the same results when I addeed sdc files. Looking for help from you.  --- Quote End ---     What you've posted is not a synchronous fifo. You should have a single clock... always @(posedge clock)   Then you use the read, write and reset in the logic.   You should also consider the condition when read and write are both true. In that situation, the correct operation is that usedw wouldn't change...in yours usedw will decrement by 1.   Kevin Jennings

[Altera_Forum]

Hi Kevin Jennings, 

Thank you for your help. Yes, my fifo is an asunc-fifo,there is no synchronous clk. When I added the the condition when read and write are both true the simulation result was the same as before.In fact in the test file in the attachment read and write will never be true at same time.Following is the rewritten one: begin  if(!rst)usedw<=8'h0;  else if(read==1'b1)begin  if(write==1'b1)begin usedw <= usedw; end  else begin usedw <= usedw- 8'h1;end  end  else if(write==1'b1)  begin  if(read==1'b1)begin usedw <= usedw;end  else begin usedw <= usedw +8'h1;end  end end

[Altera_Forum]

I assume, the purpose of your design is to be finally used in synthesized code? Even if you manage to get reasonable simulation results, it will never work in synthesis without a clock.

[Altera_Forum]

Of course there are clocks : read is read_clk,write is write_clk.They are different clock.

[Altera_Forum]

--- Quote Start ---  Of course there are clocks : read is read_clk,write is write_clk.They are different clock.  --- Quote End ---   And that will be a problem (i.e. more than one clock) when you get to trying to make this into a real device. Think about it a minute and ask yourself how is logic (in this case 'usedw') going to meet a setup or hold time requirement if it is clocked by different clocks unless those two clocks happen to maintain a specific phase relationship to each other (for example, maybe one is exactly half the clock speed and edges are aligned).   This may or may not explain what you are seeing with simulation as well but if you're trying to make a real device you'll have to confront this issue sooner (i.e. now) or later. That's why I suggested a single clock and FvM suggested 'a clock' (i.e. not more than one).   Kevin Jennings

[Altera_Forum]

Your design involves a counter (usedw), it can be only synthesized as synchronous logic, using FFs. FPGA FFs only have a single clock input and thus you can only synthesize synchronous logic with a single (edge sensitive) clock and an optional asynchronous reset condition. 

 These are the facts, you need to consider them for your design.