[VERILOG] Rule D101: Data bits are not synchronized when transferred between ...

[Altera_Forum]

FPGA is Cyclone 4 and design tool is Quartus 13; I've got this Design Assitant error: 

 critical warning (308060): (high) rule d101: data bits are not synchronized when transferred between asynchronous clock domains. (value defined:2). found 6 asynchronous clock domain interface structure(s) related to this rule.  It's related to an address bus fed into a ram block megafunction. Address bus is demultiplexed from a address/data/ale cpu interface:    --- Quote Start ---   reg [15:0] address_register = 0; always @( posedge ale ) begin  if ( cs_n == 0 ) begin   address_register <= address_data;  end  end   --- Quote End ---    Test ram megafunction instance is connected to address/data bus this way:    --- Quote Start ---   wire test_ram_cs_n; assign test_ram_cs_n = ( address_register == PARAM_TEST_RAM_ADDR )?0:1; wire [15:0] test_ram_data_bus; test_ram test_ram_inst  (  .address ( address_register [5:0] ),  .clock ( pll_clk ),  .data ( address_data),  .wren ( ~wr_n & ~test_ram_cs_n),  .q ( test_ram_data_bus )  ); assign address_data=(~rd_n & ~test_ram_cs_n)?test_ram_data_bus:16'bz;    --- Quote End ---     I understand that address_register comes from a D-FF clocked by ale signal and test_ram gets its clock from the main pll output. How can I solve the issue without adding a D-FF before ale signal? This will slow down my cpu bus interface (pll_clk is 40MHz)...

[Altera_Forum]

The RAM block you've generated will be expecting a synchronous address presented to it. This means the address must be generated from the same clock domain you are using to drive the RAM block - i.e. 'pll_clk'. 

 By latching 'address_register' on a rising edge of 'ale' you are creating a separate domain which is what Quartus doesn't like.  You need to generate 'address_register' in a clocked always block, driven by 'pll_clk'. Within this always block test 'ale' and 'cs_n' for the conditions you need, on every posedge of clock, and latch your 'address_register' accordingly.  Note: the 'data' and 'wren' signals on the RAM will need to be generated from the same clock domain as well.

[Altera_Forum]

If the processor bus isn't synchronized to the PLL clock, there's a certain chance that bus signals change simultaneous with the clock edge and cause a timing violation. You likely get inconsistent address or data words and rarely metastable events.  

 There are several ways to overcome the situation, but they always involve synchronization stages and respective delays. E.g. if you follow the suggestion by a_x_h_75, the bus control signals must be synchronized by double DFFs before they can be used in the synchronous clock domain.