opb2plb

[kef2189]

I have a legacy core implementing the plb34 interface.  I would like to excercise this core using software on a microblaze, so I created an EDK system with a microblaze on an opb bus, a opb2plb bridge, and a plb bus.  As a sanity check, I put a bram on the plb bus, to ensure that I could read and write to the bus. 

However, I'm having trouble.  If I try to write to the BRAM, nothing happens, and I get a constant return value of 0 for my writes  (I've made the pointer nonvolatile and disabled the cache).  

 I'm wondering if perhaps I've misconfigured something.  My bridge has address range 0x10000000 to 0x1fffffff, and the bram has (plb) range 0x10000000 to 0x10007fff.  

Does anyone have experience with this sort of design?  Id I had a working EDK project with something like this in it, I think all my problems would be solved, so if you could send one, that would be great.

 I can post more information if necessary.

Thanks,

Elliott

[barriet]

The ML405 MicroBlaze reference design includes a opb2plb bridge to access the PLBv3.4-based TFT controller:

http://www.xilinx.com/products/boards/ml405/reference_designs.htm

Cheers,

bt

[jagron]

I have had problems with PLBv46 to OPB connections before as the timeout logic on OPB and PLBv3 buses do not match up with the new v46 spec.  For me, under heavy bus load, reads to the OPB return all zero's even to addresses that should always return non-zero values.  I never get a bus error or timeout though (verified with ChipScope).

I would recommend looking at the system.vhd file located in your EDK sub-directories just to make sure that all of the proper clock and reset signals are connected up to each of the buses and bridges.

Does the core have a master or slave interface (or both).  If it is slave only, it is very easy to convert to the newer bus specification.  Master interfaces take a bit more work, but the createip tool can build most of the interface for you.

-Jason

[kef2189]

I see.  Unfortunately, it is a bus master. I suppose I might be able to hack up some bus bridge.  Maybe one already exists?  This seems like something Xilinx should provide for convience.  

I did add a reset block to the system, since there was some documentation that stated a reset of at least 2 cycles was needed.  

So, the idea is that opd may timeout and just return a 0?  There is some parameter that deals with this.  Did you try tweaking it?

[kef2189]

I notice this variable:

PARAMETER C_NUM_OPBCLK_PLB2OPB_REARB =100 

in the 8.1 sample code.   I copied this in to my mhs, but it did not seem to work. Hmmm.... I suppose I can copy my mhs params for comment:

 BEGIN plb_v34
 PARAMETER INSTANCE = plb_v34_0
 PARAMETER HW_VER = 1.02.a
 PARAMETER C_EXT_RESET_HIGH = 1
 PARAMETER C_NUM_OPBCLK_PLB2OPB_REARB = 100
 PORT PLB_Clk = sys_clk_s
 PORT SYS_Rst = proc_sys_reset_0_Bus_Struct_Reset
END

BEGIN plb_bram_if_cntlr
 PARAMETER INSTANCE = plb_bram_if_cntlr_0
 PARAMETER HW_VER = 1.00.b
 PARAMETER c_include_burst_cacheln_support = 1
 PARAMETER c_baseaddr = 0x10000000
 PARAMETER c_highaddr = 0x10007FFF
 BUS_INTERFACE SPLB = plb_v34_0
END

 BEGIN opb2plb_bridge
 PARAMETER INSTANCE = opb2plb_bridge_0
 PARAMETER HW_VER = 1.00.c
 #PARAMETER C_OPB_HIGHADDR = 0x100FFFFF
 #PARAMETER C_RNG0_BASEADDR = 0x10000000
 #PARAMETER C_RNG0_HIGHADDR = 0x1fffffff
 #PARAMETER C_SAME_CLKS = 1
 
 PARAMETER C_NUM_ADDR_RNG = 1
 PARAMETER C_RNG0_BASEADDR = 0x10000000
 PARAMETER C_RNG0_HIGHADDR = 0x1FFFFFFF
 PARAMETER C_SAME_CLKS = 1
 PARAMETER C_RNG0_PREFETCH = 0
 PARAMETER C_RNG0_LINE = 0
 PARAMETER C_OPB_REG_INTFC = 0
 PARAMETER C_DCR_BASEADDR = 0b0000001000
 PARAMETER C_DCR_HIGHADDR = 0b0000001011
 
 BUS_INTERFACE SOPB = mb_opb
 BUS_INTERFACE MPLB = plb_v34_0
 PORT BGI_Trans_Abort = net_gnd
END

BEGIN opb_v20
 PARAMETER INSTANCE = mb_opb
 PARAMETER HW_VER = 1.10.c
 PARAMETER C_EXT_RESET_HIGH = 1
 PORT SYS_Rst = proc_sys_reset_0_Bus_Struct_Reset
 PORT OPB_Clk = sys_clk_s
END