Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | fsm coding question

There are 3 messages in this thread.

You are currently looking at messages 0 to 3.

fsm coding question - John Butler - 2009-12-29 02:27:00

This is in Altera cylone-3.

I have this code which seems to run OK in RTL and gatelevel
simulation  but I m getting glitches in signaltap and in oscilloscope.

The clock is running at 100 MHz but data is being written and read
from a Ram every 5 us or so.


I am getting glitches in State 2 and 3.

The STATE is getting assigned in separate sequential process.

Also do I need to put all the signals being checked in the always
block ( e.g counter and  count_down_cnt  etc).

always @(STATE or counter)
begin: FSM_COMBO1_I

case(STATE)
	ST0 :
	begin
	if (!wrempty)
		begin
			next_STATE <= ST1;
			rdreq1 <= 1'b1;
		end	else
		begin
			next_STATE <= ST0;
			rdreq <= 1'b0;
		end
	end
	ST1:
	begin
		rdreq <= 1'b0;
		if (counter == q1_out[19:12] )
		begin
			next_STATE <= ST2;
			output1 <= 1'b1;
			counter_data<= q1_immediate[11:0];
			counter_sload <= 1'b1;
			counter_cnt_en <= 1'b1;
		end

		else
		begin
			next_STATE1_I <= ST1;
			output1  <= 1'b0;
			counter_sload <= 1'b0;
			counter_cnt_en <= 1'b0;
		end
	end
	ST2: begin
		counter_sload <= 1'b0;
		if (count_down_cnt == 12'd1)
		begin
			next_STATE<= ST3;
			output1   <= 1'b0;
			counter_cnt_en <= 1'b0;
		end
		else
		begin
			next_STATE <= ST2;
			output1    <= 1'b1;
			counter_cnt_en <= 1'b1;
		end
	end
	ST3: begin
		next_STATE <=ST0;
	end
	default:
	begin
		next_STATE <= ST0;
		output1    <= 1'b0;
		rdreq1 <= 1'b0;
		counter_cnt_en <= 1'b0;
		counter_data <= 12'd0;
		counter_sload <= 1'b0;
		counter_cnt_en <= 1'b0;
	end
	endcase

end

Thanks for your suggestions/ideas.



Re: fsm coding question - Ralf Hildebrandt - 2009-12-29 04:08:00

Am 29.12.2009 08:27, schrieb John Butler:


> The STATE is getting assigned in separate sequential process.

Write to a signal/variable only in one always statement! Although
Verilog allows the other way, it is a bad coding style and error-prone.


> Also do I need to put all the signals being checked in the always
> block ( e.g counter and  count_down_cnt  etc).
> 
> always @(STATE or counter)
> begin: FSM_COMBO1_I
> 
> case(STATE)
...

If you do it this way: then yes.
You have written a pure combinational always statement. For this this is
necessary to have all signals in the sensitivity list.

But you could merge the combinational always statement that results in
the next_STATE signal with the synchronous always statement, that
assigns next_STATE to STATE. Then you only have one synchronous always
statement and for this only the clock (and an asynchronous reset) needs
to be put in the sensitivity list.

Ralf

Re: fsm coding question - Muzaffer Kal - 2009-12-29 04:26:00

On Mon, 28 Dec 2009 23:27:05 -0800 (PST), John
Butler
<j...@gmail.com> wrote:
>I have this code which seems to run OK in RTL and gatelevel
>simulation  but I m getting glitches in signaltap and in oscilloscope.
>
You don't define which signals are showing glitches. Are you  seeing
glitches in STATE or some other signals?

>Also do I need to put all the signals being checked in the always
>block ( e.g counter and  count_down_cnt  etc).
>
For simulation/synthesis matching usually yes. For synthesis only, the
tool already assumes it so sometimes there can be mismatches so it's
safer to do that.

Are you registering rdreq, rdreq1, output1, counter_cnt_en etc.
signals ala STATE? If they're not registered and as you don't assign
them at the top of FSM_COMBO1_I block, you will get latches for them
and these latches may cause the problems you're observing. 
Also what is next_STATE1_I signal used for? It seems like a typo.

-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.