random write on first cycle after reset_n goes hi?

Altera_Forum · ‎04-05-2007

Hi,

I have a DE1 board. I built a custom component. It simulates fine. It is fairly large because of a lot of functionality, but managable. It worked with one processor. I need to share it with two processors. This is where it fell apart.

My control register seemingly came up initialized with random bits. Same each time after compile, but when recompiled with a few changes, it fits a little different, and the bits would be different. I know because I have recompiled it all day yesterday with minor changes trying to track down the problem.

Furthermore, I have six of these components. The control registers of each of these components were different. For example for the components 0 thru 5, their control registers would be 272, 272, 264, 256, 504, 256.

It seemed my reset_n code initialization was not working, so I exported my reset_n signal (instead of using the global reset_n), and attached a button to it. Pressing the button reset things fine. I then thought it still might not be getting to the code. Like for some reason reset_n might be the reset_n from the other processor?? (grasping at straws at this point) So I placed a register to initialize and assigned a wire to it to output to an LED while in reset, and go off after reset. Reset was in fact occuring, but my control register for some reason did NOT initialize to what was expected.

Keep in mind I am new to FPGA's since November of last year. This is a hobby strictly. So I am extremely hessitant to announce there is a bug. I want someone explain if I have done something stupid, or taken the correct step to fix this, because it seems like a hack to me.

Here is this main avalon interface verilog code snippet. Of particular interest are:

(1) r_control_register - this is what was getting corrupted.

and

(2) r_update_control_register - this is what I did to stop it. Original code had no references to this register. This register stops a write to (1) until the first read cycle takes place.

The only part in my code that maniuplates (1), is the reset_n code, and avalon slave write cycle (0 wait states). You can ignore all other registers. Lines of interest have an asterisk *.

-------------------------------------------------

always @(posedge clk or negedge reset_n) begin
   if (!reset_n) begin
      r_reset_position_has_been_captured <= 1;
      r_set_counter <= 1;
*     r_control_register <= 0;
      r_counter_period <= -1;
      r_step_pulse_length <= -1;
      r_new_counter_value <= 0;
*     r_update_control_register <= 0;
   end
   else begin
      if (chipselect) begin
            if (~write_n) begin
               case (address)
                  3&#39;b000:  begin
                        r_new_counter_value <= writedata;
                        r_set_counter <= 1;
                  end
                  3&#39;b001:  begin
                        r_counter_period <= writedata;
                  end
                  3&#39;b010:  begin
                        r_step_pulse_length <= writedata;
                  end
                  3&#39;b011:  begin
                        r_reset_position_has_been_captured <= 1;
                  end
                  3&#39;b100:  begin
                  end
                  3&#39;b101:  begin
                  end
                  3&#39;b110:  begin
                  end
                  3&#39;b111:  begin
*                       if (r_update_control_register) begin   // this is part of the fix.
*                          r_control_register <= writedata;
*                       end
                  end
            endcase
         end      // ~write_n
         if (~read_n) begin         // this is part of the fix.
*           if (address == 3&#39;b000) begin
*              r_update_control_register <= 1;
*           end
         end
      end      // chipselect
      else begin
         r_reset_position_has_been_captured <= 0;
         r_set_counter <= 0;
      end
   end     // not in reset
end

-------------------------------------------------

I am using a NIOS/f core for both processors. Quartus 6.1 (don't bash because it isn't 7.0, please). It compiles with fmax > 100, and I run the processors at 100 Mhz. I do not even need to run the NIOS debugger to know if it is initialized correctly because I output some leds through hardware based upon the control_register, and can see if it was initialized correctly. So this is not a NIOS II software error on my part.

Everything now works. Anyone care to clue me in to what is happening? I hate the hack. Because IT IS A HACK. Do I need some other avalon slave control signals?

Should this be happening? Any insight would be helpful.

Thanks,

Nails

P.S. As for returning the "272, 272, 264, 256, 504, 256" numbers, what may not be clear is that even though r_control_register is only defined as 8 bits, I pre-pend 2 other status bits when reading the control register. But notice the lower order bits are still not initialized correctly.