cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
aasavich
Visitor
Visitor
6,416 Views
Registered: ‎05-09-2009

plbv46_pcie bridge v3.00.a and 3.00.b problems, ML506

Jump to solution

Hi,

 

I upgraded my tools to 10.1 SP3 and also tried v11.1 evaluation.  the pcie bridge for edk got upgraded, I was using 2.01.b before, everything was working.

 

I tried linking the aux_rst pin on the microblaze to linkup output on the bridge core as suggested in the core datasheet.  I tried connecting PERSTN to sys_rst_n and to an external switch.  The pc doesn't recognize designs made with this new core version.

 

I tried creating a new basic design with the bsb provided, the ML506 still doesn't have a bridge option (505 and 507 do, so I create a 505 design, and change the target chip to SX).  It looks like the bridge is provided with timing/placement constraints for LX and FX chips, but nothing for the SX chips still.

 

Does anyone have the new bridge versions working in their design (any v5 chip series), or maybe even on an ML506 board?  How did you manage that?  Maybe you can share the relevant UCF files?

 

Thanks!

0 Kudos
1 Solution

Accepted Solutions
aasavich
Visitor
Visitor
7,494 Views
Registered: ‎05-09-2009

problem solved.  the new reset scheme works, however the defaults are wrong, and one has to look carefully at proc_sys_reset to get it right.  linkup signal from the core is active high, and so is the polarity of aux reset signal - system startsup with link down, when link is up, cpu is reset, plb is reset, and so is the pcie endpoint with bridge.  go figure... the solution is to change the aux reset input polarity, in proc_sys_reset configuration to ACTIVE LOW (0).

 

I'm still experiencing timing closure problems with no specific constraints given for the ml506 board (sx chip).  when only the ddr2 and pcie bridge ip's are the only auxiliary cores on a microblaze bus, the two cannot get routed properly, they conflict one another.  when more stuff gets thrown in (ie. custom cores, gpio, sram controllers, etc.), the system gets routed ok.  go figure...

View solution in original post

4 Replies
aasavich
Visitor
Visitor
7,495 Views
Registered: ‎05-09-2009

problem solved.  the new reset scheme works, however the defaults are wrong, and one has to look carefully at proc_sys_reset to get it right.  linkup signal from the core is active high, and so is the polarity of aux reset signal - system startsup with link down, when link is up, cpu is reset, plb is reset, and so is the pcie endpoint with bridge.  go figure... the solution is to change the aux reset input polarity, in proc_sys_reset configuration to ACTIVE LOW (0).

 

I'm still experiencing timing closure problems with no specific constraints given for the ml506 board (sx chip).  when only the ddr2 and pcie bridge ip's are the only auxiliary cores on a microblaze bus, the two cannot get routed properly, they conflict one another.  when more stuff gets thrown in (ie. custom cores, gpio, sram controllers, etc.), the system gets routed ok.  go figure...

View solution in original post

austinchipworks
Visitor
Visitor
5,550 Views
Registered: ‎11-04-2008
Came across your post, as I'm trying to bring up the PCIe bridge on an ML509 (XUPV5). Will be trying flipping the polarity of the aux_reset_pin.
 
I dealt  with the same timing closure issues. I looked at the placed netlist in Planahead. The PCIe endpoint blockrams were placed in the middle of the chip. Seems like when there is too much of space (low utilization), the placer does a poor job on bram placement.
 
Here are the exported fixed placements, moving the endpoint brams close to the PCIe hard macro. These were really the only constraints needed for timing closure.  
 
INST "PCIe_Bridge/PCIe_Bridge/comp_block_plus/pcie_blk/pcie_mim_wrapper_i/bram_tl_rx/generate_tdp2[1].ram_tdp2_inst" LOC = RAMB36_X3Y9;
INST "PCIe_Bridge/PCIe_Bridge/comp_block_plus/pcie_blk/pcie_mim_wrapper_i/bram_tl_rx/generate_tdp2[0].ram_tdp2_inst" LOC = RAMB36_X3Y8;
INST "PCIe_Bridge/PCIe_Bridge/comp_block_plus/pcie_blk_if/ll_bridge/rx_bridge/fifo_inst/oq_fifo/Mram_regBank" LOC = RAMB36_X3Y12;
INST "PCIe_Bridge/PCIe_Bridge/comp_block_plus/pcie_blk/pcie_mim_wrapper_i/bram_tl_tx/generate_tdp2[1].ram_tdp2_inst" LOC = RAMB36_X3Y11;
INST "PCIe_Bridge/PCIe_Bridge/comp_block_plus/pcie_blk/pcie_mim_wrapper_i/bram_retry/generate_sdp.ram_sdp_inst" LOC = RAMB36_X3Y7;
INST "PCIe_Bridge/PCIe_Bridge/comp_block_plus/pcie_blk/pcie_mim_wrapper_i/bram_tl_tx/generate_tdp2[0].ram_tdp2_inst" LOC = RAMB36_X3Y10;
0 Kudos
austinchipworks
Visitor
Visitor
5,536 Views
Registered: ‎11-04-2008

Flipping the aux_reset polarity worked. 

 

I also figured why PAR had a hard time. The IP has a set of location constraints for ML505,507 and 555. These place the BRAMs, but of course non of those placements would be optimal for a board thats not listed.

 

Adding the location constraints described in my previous post to system.ucf, overrides what the IP provides. (Resolved in the NGDBUILD step). 

haaziq
Newbie
Newbie
4,853 Views
Registered: ‎07-13-2010

Hi,

 

My reset scheme already working, the link up signal is up also. But the problem is when i check the 'PCIe Requester ID Register'  it seems that the root complex does not assign the device number to it(Pcie bridge is configured as endpoint).

Why is this happening??

 

BTW, I'm using ml505 and the PC still don't recognize the board, whereas the PC hang during boot-up. Hope I'll be getting some help here..

 

 

0 Kudos