Resetless ACTEL FPGA

[shaiko]

process ( clock ) is
	begin 
		if rising_edge ( clock ) then
			counter <= counter + 1 -- counter is defined as an 8 bit unsinged vector
			if counter = "11111111" then
				test <= not test -- test is defined as a buffer std_logic 
			end if ;
		end if ;	
	end process ;

The above code has been used to test the functionallity of an FPGA (Actel ProAsic3) on a newly manufactured board.
The PCB has been designed without an external POR (power on reset) source.
A scope probe a the "test" pin showed a constant '1' (3.3 volts).

Afterwards, the PCB has been reworked and a simple RC circuit has been connected to one of the input pins to generate a reset signal and drive it to one of the input pins of the Actel FPGA. The code has been rewritten and reflashed:

process ( clock ) is
	begin 
		if n_reset = '0' then
			test <= '0' ;
			counter <= ( others => '0' ) ;
		elsif rising_edge ( clock ) then
			counter <= counter + 1 -- counter is defined as an 8 bit unsinged vector
			if counter = "11111111" then
				test <= not test -- test is defined as a buffer std_logic 
			end if ;
		end if ;	
	end process ;

Reapplying the scope probe to the "test" pin showed a perfect square wave with the desired frequency.

My questions is:
Can the lack of an external reset cause such a problem ?

 

[FvM]

Can the lack of an external reset cause such a problem ?

No. If so, it would be a synthesis software bug. You should check the synthesized netlist

 

[shaiko]

What if the FPGA has no internal POR circuitry ?
Can it cause the flipflops to "freeze" ?

 

[FvM]

No. It would cause arbitrary initial values for counter and test at worst case. This can be said, because it's a binary counter without any risk of illegal states. The answer would be different for a state machine without "safe FSM" logic.

 

[shaiko]

So...you're suggesting that adding the reset in the second attempt caused the synthesis tool to go down a different algorithmical path and not encounter the glitches of the first compilation cycle ?

 

[FvM]

I don't suggest anything for the design.

The design with reset is supposed to work. If it doesn't, you need to interrogate the gate level synthesis result.

 

[std_match]

Was the n_reset signal only added to this process?
How can you be sure that the clock to this process was running before the change?

Is it possible that n_reset was added also somewhere else, and that caused the clock to run properly?

 

[shaiko]

When the PCB arrived and passed initial testing I proceeded with loading my full code (a custom IP...)

As I got no response from the communication lines of the IP I proceeded with my debug plan.
I wrote this code :

process ( clock ) is
	begin 
		if rising_edge ( clock ) then
			counter <= counter + 1 -- counter is defined as an 8 bit unsinged vector
			if counter = "11111111" then
				test <= not test -- test is defined as a buffer std_logic 
			end if ;
		end if ;	
	end process ;

clock_view <= CLOCK ; -- clock view is an output pin to the scope.

I recompiled the design - and applied the scope probes to "clock_view" and "test".
The "clock_view" was as it should be. "test" however remained a constant '1'.
Afterwards, the circuit has been reworked and an external RC POR circuit has been added.

I recompiled the design with the following code and everything worked fine:

process ( clock , reset ) is
  begin 
    if n_reset = '0' then
      test <= '0' ;
      counter <= ( others => '0' ) ;
    elsif rising_edge ( clock ) then
      counter <= counter + 1 -- counter is defined as an 8 bit unsinged vector
      if counter = "11111111" then
         test <= not test -- test is defined as a buffer std_logic 
      end if ;
    end if ;	
  end process ;

clock_view <= CLOCK ; -- clock view is an output pin to the scope.

Pin assignment has been tripple checked during the whole process - so I rule out any such error.

 

[FvM]

As an additional requirement, the clock frequency and rise/fall time must correspond to the FPGA specifications. If you drive the clock input with a very slow edge, irregular behaviour may be possible. Are you sure, that all necessary operation requirements have been satisfied during the first test, e.g. all chip voltages applied?

There may be a condition, where the internal POR circuit (I still assume, that Actel has it) is hoiding the FFs in reset, although the combinational clock_test pin is working.

 

[shaiko]

FvM,

Other than a simple rework of the external RC POR - nothing has been changed from an hardware point of view.
I used LVCMOS 3.3V in both cases and never touched the 50MHz clock source.

I'm not saying that the addition of the RC POR did the difference - But, it was the one and only applied hardware change.