Lattice Mach XO2 - Unable to simulate reading TraceID through Wishbone

[bsccara]

I need to read the TraceID from inside the fabric, using the Wishbone interface and the EFB. According to my understanding the Wishbone master has to do a write cycle to register 0x70, setting it to 0x80 to open the connection, followed by four write cycles to register 0x71 for the 'Read TraceID Code' command, setting it to 0x19, 0x00, 0x00, 0x00. After this eight read cycles from register 0x73 should provide the data.
I've implemented the master but in simulation with Active-HDL 10.3 the first cycle looks OK but on all other the 'wb_ack_o' signal goes high as soon as the master drives the 'wb_stb_i' signal high. Originally the master did the cycles back to back but I've since changed the master to insert a long delay between each cycle and again changed the master to keep the 'wb_cyc_i' signal high during the whole sequence but to no avail. On the EFB instantiation, done with IPExpress,  I've tested with 'User Flash Memory' both selected and unselected. The 'wb_clk_i' signal is driven from the internal oscillator, at 88.67 MHz.
So it seems the Wishbone slave on the EFB gets confused after the first write cycle, but why?

P.S. I've attached a picture of the signals on the simulation; the blue line crosses the first write cycle and the red the second one. The second picture is from Lattice's TN1246 and has an example of reading the UserCode, which is quite similar to what I want to do.

[bsccara]

More strangeness... According to the attached paragraph from page 7 of the TN1246 for the simulation to work properly the 'wb_cyc_i' and 'wb_stb_i' signals need to have their assignment delayed by 100ps. Doing that the simulation now appears as shown; the 'wb_ack_o' signal is now driven by the slave some time after (first write cycle) or on (other cycles) the second clock transition. The discrepancy doesn't fill me with confidence on the correctness of the simulation but it seems to be an improvement.
The paragraph also states that those signals should be deasserted immediately on 'wb_ack_o' assertion, which I took to mean that combinatorial logic was needed to short the signals low. But alas if I do that combined with the delayed assignment all these signals enter into a fast oscillation (in the GHz range) until the next clock transition. Go figure...
Regardless I'm getting all zeros as TraceID, which I'm not too sure is correct for the simulation. Guess I'll try using Reveal to debug on the actual FPGA.