On Thursday 08 April 2010 19:51:57 Philip Pemberton wrote: > It's an Altera M4K ROM megafunction, 1024x 32-bit words, tied straight > onto the instruction bus: > > // boot ROM > wire [31:0] INSROM_DATA; > bootrom ROM ( > .clock (MCLK), > .address (CPU_I_ADDR[9:2]), > .q (CPU_I_DATA_TO_CPU) > ); > assign CPU_I_ACK = CPU_I_STB; > assign CPU_I_ERR = 1'b0; > assign CPU_I_RTY = 1'b0;
I will assume this is a synchronous ROM (since it has a clock signal). In this case, your Wishbone signaling is incorrect and this pretty much explains your problem. If you have a register in the data path, with the basic Wishbone cycles, each transfer happens in two clock cycles: 1- master sets address and asserts stb 2- slave returns data and asserts ack (3- master releases stb, slave releases ack) See http://github.com/lekernel/milkymist/tree/master/cores/bram/ for an example of using synchronous memories with Wishbone. By the way, you should infer your memories (unless there is a synthesizer bug or lack of optimization, which sometimes happens). Using the FPGA vendor's clickodrome for that is a retarded idea. Wastes your time, makes your design uselessly complex, and locks your design to that vendor. > There isn't a Wishbone slave per se There is. :) > And I agree, it's an obvious error in the core and one that shouldn't > have slipped through... if Lattice are running any testbenches against > the core before releasing it. >From my experience with Mico32, the concerns about quality that I have are related to the GNU toolchain, the GNU/Linux port and GNU Autocrap. I think the hardware design is really good (that cache issue doesn't count, the problem stems from Xst). Sébastien _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkym...@freenode Webchat: www.milkymist.org/irc.html Wiki: www.milkymist.org/wiki
