Non deterministic FPGA - MCU interface (data bus)?

Question

Hello,
   Working on a learner project. ..  Using a Digilent Spartan 3A dev board where I have implimented counters for rotary encoder signals.  The counters seem correct as they are accurate for measuring displacement (distance/rotations).  The counters are presente to my MCU (LPC1769 Cortex M3) via GPIO...  16bit "data bus and 4bit "address bus".
   On a 1Khz interrupt, the MCU will write the address lines, delay 1us, and read the 16 bits data (GPIO) connected to the FPGA.  For testing, a function gereator is providing a consistent  signals to the FPGA with no physical encoders ,so I know the what the counter data shoud be.  However, the counter data being read from the FPGA has too much inconsistency and smells like a classic determinism problem.  
   I'm thinking the problem is in my verilog implimentation of the bus, shown here:
module FPGA_Interface(
input [3:0] Signals,
input CLK_50M,
input [3:0] Addr,
output Valid,
output wire [15:0] Data
//Use of 'Valid' for handshaking is TBD
assign Valid = 1'b0;
wire [15:0] CountData0;
wire [15:0] CountData1;
//create two counters for the rotary encoders
QuadratureCounter counter0(.EncSig(Signals[1:0]),.CLK_50M(CLK_50M),.CountData(CountData0) );
QuadratureCounter
counter1(.EncSig(Signals[3:2]),.CLK_50M(CLK_50M),.CountData(CountData1) );
assign Data = (Addr == 4'b0000)? ~CountData0:
(Addr == 4'b0001)? ~CountData1:
(Addr == 4'b0010)? ~16'b0000000000000010:
(Addr == 4'b0011)? ~16'b0000000000000011:
16'b0000000000000111;
endmodule
      Perhaps I should "latch" the data  to eliminate the potential of the data changing at read time? Any feedback on the design of the "data bus" would be grealy appreciated. Thanks,

Answer 1

aszeghy wrote:
Thank you bassman59 for the explanation.  Understood, now at least, this is a design problem. Although, I originally wanted to gate or "latch" the counter data so that it can be reliably ready by the MCU.  I thought I was getting that by latching the count data when the address lines changed state...  Apparently not.  This further confuses me.
Looking at this academic mux example I see:
always @ (posedge clk )
if (reset == 0) begin
y <= 0;
end else if (sel == 0) begin
y <= a;
end else begin
y <= b;
end
Now in this synthesised mux module y is updated on the positive edge of clk. Is y updated on a change to a or b?   If y is not updated then the sensitivity list has not been ignored.
Is this because my code's sensitivity list suggested a change of state (combinational) and the text book example suggests a rising edge (sequential)?
Thanks again for the education,
Andrei
In the code above you used the template for a register (flip-flop). 
To answer your question, y is updated only on the event in the sensitivity list. Now, that statement is true for all always blocks. It was true for your initial address-decoder example, too, because as you discovered in simulation, the Data output did not change when the counter value changed, it changed only when there was an event on Addr (when the address changed).
Now, please note my use of the word "template" above. At its core, synthesis is all about template matching, meaning that the synthesizer looks for specific patterns in your code when deciding what sort of logic to infer. And for the case where you would like to infer registers, the template demands that you put only the clock edge detector on the sensitivity list. Why? Because in a real flip-flop, what happens on the D input isn't interesting until a clock edge occurs.
And that is what happens here. In simuation, everything on the right-hand-side of the assignments are ignored until there is an event which matches what is on the sensitivity list. In this case, the event of interest is the rising edge of the clock. At that moment, all right-hand-sides (which include the conditionals like if, case, etc) are evaluated and then the y output is assigned.
In the real flipflop inferred by the synthesizer, that too is what happens. This is why for a synchronous block where you are inferring a register there is no simulation/synthesis mismatch when only the clock is on the sensitivity list.