cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
muravin
Scholar
Scholar
10,562 Views
Registered: ‎11-21-2013

moving KC705 design to a custom board

Jump to solution

Hi All,

 

I realize that moving to a custom board from a Xilinx dev board such as KC705 could remove some important properties addressed in my other post on the DCI cascade that is set only for the DDR3 controller on the KC705.

 

My question is, if we move a KC705 FPGA design to another custom board with the same FPGA part, what else in the project or in the XDC or in the IPs we need to do if the pin locations are the same for all non-HPC/LPC connections?

 

Basically, our issue is that the Microblaze does not seem to run on the custom board despite the clock is running and the DDR3 controller asserts the reset and deasserts is properly. But if we load KC705 bitfile on that board, it does start ok. Any suggestions?

 

Thank you

Vlad

Vladislav Muravin
0 Kudos
1 Solution

Accepted Solutions
muravin
Scholar
Scholar
18,696 Views
Registered: ‎11-21-2013

Hello All,

 

It has been a little delay, but I got a custom board back yesterday and I could resume my debug. After recreating the project with KC705, then moving it to the custom board, I have figured out that our issue is basically the following AR#. Sad, but that's what it is.

 

http://www.xilinx.com/support/answers/64569.html

 

BR

Vlad

Vladislav Muravin

View solution in original post

0 Kudos
19 Replies
markcurry
Scholar
Scholar
10,545 Views
Registered: ‎09-16-2009

Vladislav,

 

Check your build for how the boot file is initialized.  The BMM flow is awfully fragile, and breaks easily.  If your boot image isn't being correctly loaded into the bit file, your boot won't happen.

 

Also, try connecting up to the debugger.  That'll tell you that the microblaze is at least correctly instanciated, clocked, and out of reset.

 

Regard,

 

Mark

 

0 Kudos
muravin
Scholar
Scholar
10,542 Views
Registered: ‎11-21-2013
Thanks Mark for the prompt response.

We are using the debugger and when launching the Microblaze with debug mode, thru SDK, the debugger launches successfully. And then we see nothing.

BR
Vlad
Vladislav Muravin
0 Kudos
markcurry
Scholar
Scholar
10,539 Views
Registered: ‎09-16-2009

What do you mean "nothing"? Does the debugger actually connect to microblaze?  If so, the microblaze is there. 

 

Try manually uploading the boot image (.elf file) from the debugger, and manually starting it.

 

Regards,

 

Mark

0 Kudos
muravin
Scholar
Scholar
10,535 Views
Registered: ‎11-21-2013

I have just spoken with my embedded SW peer. Basically, we are able to see the MDM and the ELF is loaded but we cannot get to the point where we can start running the software (i.e. hit the 'Run' button). That's as far as I understand.

 

Needless to say, the IP is the same for both projects, the clocking scheme is the same etc. Everything is the same except board property and dozens of pin locations that have nothing to do with the Microblaze.

Vladislav Muravin
0 Kudos
markcurry
Scholar
Scholar
10,521 Views
Registered: ‎09-16-2009

Vlad,

 

If it connects, and you can download the ELF, then your clocking and resets are probably fine.  (The debugger usually won't even do those steps if your clocks and resets are barfed).

 

Now it's a more of a SW issue.  Why isn't it doing what you expect.  Single steps and breakpoints.  You'll just need to plug away at it.  It'll probably be something silly.

 

Good luck

 

--Mark

0 Kudos
muravin
Scholar
Scholar
10,517 Views
Registered: ‎11-21-2013

No, the software is the same in all platforms. I hope this is something silly but I don't know what... yet.

Vladislav Muravin
0 Kudos
bwiec
Xilinx Employee
Xilinx Employee
10,499 Views
Registered: ‎08-02-2011

I would try manually writing DDR via XMD. Can you use mrd/mwr commands to read/write correct data to/from DDR addresses? What if you do a small MB program that you link to BRAM (instead of DDR. Just hello world or something). Does it run in that case?

www.xilinx.com
0 Kudos
muravin
Scholar
Scholar
10,489 Views
Registered: ‎11-21-2013

Hi Brian,

 

Thanks for the suggestion. We have always been using MB internal memory for running the MB program and the DDR3 has always been used as a video buffer for our proprietary processing.

 

We have checked also resets connection and polarity and we see nothing. What else can go wrong?

 

Cheers

Vlad

 

 

Vladislav Muravin
0 Kudos
markcurry
Scholar
Scholar
10,483 Views
Registered: ‎09-16-2009

 

As Brian suggests, start with the basics.  Divide and Conquor.   A small "hello_world" program that just dumps "hello world" out a UART, or just blinks a LED.  Start small, and work from there.  Make the program small enough you can just single step through each assembly instructions if you must.

 

I know it's particularly frustrating when it works on A, but not B - you're forced to start peeling the layers of the onion.  But when the other obvious candidates have been ruled out, you gotta roll up your sleeves.

 

Regards,

 

Mark

 

 

 

 

0 Kudos
muravin
Scholar
Scholar
10,895 Views
Registered: ‎11-21-2013

We have tried this and even "hello world" programs fails loading into the MB memory.

 

One correction - there is no evidence we are not able to talk to the MDM, we are able to load the XGDB, and right after that, that's the point at which we are stuck. Again, the SDK fails to load the program into the MB memory.

 

For all we know 100%, the clock is 100 MHz, the reset to the MB pulses high on power up and is not holding the MB at reset.

 

Sleeves are rolled @markcurry but there is little time to experiment. I welcome and appreciate any suggestions, ladies and gentlemen.

 

Thanks again

Vlad

Vladislav Muravin
0 Kudos
markcurry
Scholar
Scholar
10,892 Views
Registered: ‎09-16-2009

 

Ok, you cannot WRITE to your internal BRAM where the boot vector resides.  Check the basic connections there.  Do reads of the BRAM return just all zeros?  Or perhaps something more interesting?  Issue a few more reads around the memory map to try and figure out where you are (if it's just an addressing problem).

 

If all else fails drop it into chipscope, and probe the connections to mblaze. 

 

Regards,

 

Mark

0 Kudos
subbuh
Xilinx Employee
Xilinx Employee
10,876 Views
Registered: ‎11-18-2015

Hi Vladislav,

                   Assuming that the design has been migrated correctly to the custom board, here are some of the suggestions I can give :

 

1st Method :

1.) Once you generate the bitstream and launch the SDK, create a Hello World Application project (Ex Name of Project : hello_world). 

2.) Once the project is created Click on the hello_world folder in the project Explorer, go to Xilinx Tools --> Generate Linker Script --> Generate (Do not change anything) --> Click Yes to overwrite the existing linker script. 

3.) It takes a little time but the .elf file is rebuilt. Now re-program FPGA with the .elf file.

 

2nd Method (If method 1 does not work) :

1.) Go back to Vivado project

2.) Tools --> Associate ELF Files --> Associate the ELF File created and then re-generate the Bitstream

3.) Now in the Program FPGA option of SDK, Browse and add the newly created bitstream from the  project.runs/impl directory

4.) Under the Processor Option (Software Configuration section), select none from the dropdown and program the FPGA.

 

Do let us know if this works.

 

Regards,

Subbu

www.xilinx.com 

0 Kudos
muravin
Scholar
Scholar
10,853 Views
Registered: ‎11-21-2013

Hi Subbu,

 

Thank you for your suggestion.

- We have tried option 1, no change, same behaviour

- We have tried option 2, in the VIVADO I had added the ELF file to the project, and after re-generating the bit stream, we get the same result

 

BR

Vlad

Vladislav Muravin
0 Kudos
markcurry
Scholar
Scholar
10,849 Views
Registered: ‎09-16-2009

Vlad,

 

I'm not surprised that those two options didn't work. The debugger cannot upload an ELF file to your boot RAM.  That's a prerequisite for either of those two options.

 

What's clocking the BRAM itself?  In the normal mblaze setup the top clock to the microblaze "CLK" get's passed down to the lmb controller clock input port "LMB_Clk".  Within the LMB controller it just is fed back out to the output port "BRAM_Clk_A" which actually goes to the BRAM clock port.  I'm wondering if somehow something got broken here.

 

I'm thinking you may be forced to chipscope the block memory.  Just add it to the LMB ports:

BRAM_Rst_A
BRAM_Clk_A
BRAM_EN_A
BRAM_WEN_A
BRAM_Addr_A
BRAM_Din_A
BRAM_Dout_A

 

This should narrow down your problem.

 

Regards,

 

Mark

 

0 Kudos
muravin
Scholar
Scholar
10,839 Views
Registered: ‎11-21-2013

Thanks Mark. Yes, the connections to the memory are exactly the same as you describe them.

 

As said earlier, we did probe clock, reset, and these signals are good. The reset property is ACTIVE_HIGH, it pulses high on the power up and then stays low.

 

Seems like we are running out of options, and the next week promises to be very exciting. Thanks again.

 

Regards

Vladislav Muravin
0 Kudos
muravin
Scholar
Scholar
10,812 Views
Registered: ‎11-21-2013

Hi All,

 

The board I worked on was taken for rework until next week but I was able to do is 2 things:

1. Probe LMB clock and reset and they are good

2. I took the project, regenerated it from TCL BD, then changed the board property to KC705, resynthesized and it worked. So there is a short-term workaround with the above-mentioned rework, but the issue is still there.

 

I am getting the board back next week and will probe all internal LMB/DLMB signals. If anyone has any magical suggestions, please feel free to share. I will update this post with the results of the debug next week.

 

BR

Vlad

Vladislav Muravin
0 Kudos
muravin
Scholar
Scholar
18,697 Views
Registered: ‎11-21-2013

Hello All,

 

It has been a little delay, but I got a custom board back yesterday and I could resume my debug. After recreating the project with KC705, then moving it to the custom board, I have figured out that our issue is basically the following AR#. Sad, but that's what it is.

 

http://www.xilinx.com/support/answers/64569.html

 

BR

Vlad

Vladislav Muravin

View solution in original post

0 Kudos
markcurry
Scholar
Scholar
10,210 Views
Registered: ‎09-16-2009

 

Ah - very frustrating, and tricky to find.  Glad you root-caused the problem.  As often is the case, it's satisfying having a solution, but sometimes frustrating when you realize how much time was wasted on such a trivial error.

 

Regards,

 

Mark

 

0 Kudos
muravin
Scholar
Scholar
10,207 Views
Registered: ‎11-21-2013
Yes Mark thanks for the "cheer up". The documentation is wrong, the schematic is wrong, the pin locations are only set correctly when the board is set to KC705. So the hardware designer copies the pin locations based off the schematic and we just change the project properties and expect it to be a smooth ride.
Vladislav Muravin
0 Kudos