Electronic – Why two Xilinx scripts with different bitgen options yield correct and incorrect behaviors

the rising_edge() parameter is only really for clock signals. One option would be the following:

clk_proc: process( clk, switch1, switch0 )
begin
    if switch1 = '1' then
        counter <= ( others => '0' );
    elseif rising_edge( clk ) then
        if switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

This is known as an asynchronously reset process, which means that it'll reset the counter whenever reset (switch1) is high, regardless of clock state. A synchronously reset process would look the same as your second example:

clk_proc: process( clk, switch1, switch0 )
begin
    if rising_edge( clk ) then
        if switch1 = '1' then
            counter <= ( others => '0' );
        elsif switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

You did state though that your second example didn't work as expected. My suspicion is that this is because the signals driving it are switches rather than clocked logic signals. Switches don't actually switch instantaneously, instead bouncing between on and off a few times before settling. You need to implement some sort of debounce process to produce a signal which is synchronous with your clock and can control your timer.

It's also worth mentioning that FPGA design is a lot easier if you simulate stuff first. Xilinx ISE includes a simulator - create a testbench and use it! That lets you easily see what's happening in your implementation before you ever get near hardware.

Some hints for and questions to your code:

• signal nextColor should not have a default value, because it's not mapped to a register
  signal nextColor : color_type;
• signal qtemp misses a default value: it's a counter/mapped to a register
• secondly, this signal represents a counter and it's used in arithmetic calculations. So qtemp should be of type (un)signed or integer/natural. Doing artithmetic calculations on std_logic_vector is not a recommended style.
  signal qtemp : unsigned(24 downto 0) := (others => '0');
• qtemp should also be reset to 0 after 1 second passed by (as David Koontz wrote in the comment below)
• if you change the type of qtemp you can rewrite the test (qtemp = "10111110101111000010000000") to (qtemp = 50000000)
  Actually, it should be 49,999,999, because your counter starts at 0.
• ONEsec_flag is asynchronous set and synchronous reset -> try to write full synchronous design.

• line if (BaseBeat'event and BaseBeat = '1') and (ONEsec_flag='1') then can and will cause several problems:

  1. BaseBeat is no clock signal, but you are using this signal as a clock. A better solution would be to use BaseBeat as an (clock)enable signal.
  2. writing a rising edge condition and a clock enable in one line is no good style. Additionally it can cause synthesis tools to infer wrong hardware.

  3. In combination with your else-statement this code will not be synthesizable. Here is a solution:

     calculating the flag (concurrent statement):
     ONEsec_flag <= '1' when (qtemp = 49999999) else '0'; -- ternary operator like ?: in C

     transition process:

     transition: process(clk)
     begin
       if rising_edge(clk) then         -- synchronous design using the main clock    
         if (BaseBeat = '1') then       -- using BaseBeat as an clock enable
           if (ONEsec_flag='1') then    -- using flag as an write enable (second ce)
             current_color <= next_color;
           end if;
         end if;
       end if;
     end process;
     

• So now, flag is calculated concurrently, it can be used to reset the second timer, otherwise a 25 bit vector will overflow after 2^25 cycles, that are 33554432:

  process(clk)
  begin
    if (clk'event and clk='1') then
      if (ONEsec_flag = '1') then      -- synchronous reset if one second is reached
        qtemp <= (others => '0');
      else
        qtemp <= qtemp + 1;
      end if;
    end if;
   end process;
  

• this leads us to another problem: your counter signal has insufficient bits to hold 49,999,999 -> you need at least 26 bits

• the UCF file has several errors:

  1. NET "clk" ... has another signal name in comment
  2. one signal can not have multiple locations

  3. ON_BOARD_LED_output is a vector, so you should access each bit by using netname<index> and assign a location for each bit.

     NET "ON_BOARD_LED_output<2>" LOC = "G1" ; # Bank = 3, Signal name = LD7
     NET "ON_BOARD_LED_output<1>" LOC = "P4" ; # Bank = 2, Signal name = LD6
     NET "ON_BOARD_LED_output<0>" LOC = "N4" ; # Bank = 2, Signal name = LD5
     

  4. NET "output" ...: Why have you enabled internal pullup resistors (inside the IOB)? Most development boards have them externally.

  5. and why are you limiting the current to 2 mA (DRIVE = 2)?
  6. All pins have no assigned IOSTANDARD: This is needed for a proper timing analysis. If you want to switch to newer FPGAs and tools, it's then absolutely necessary to declare an IOSTANDARD