MATLAB 2018a HDL-coder : Failed Program target FPGA device.

Hi.

I am Using MATLAB 2018a, HDL coder,

( Now following installing a patch file from Mathsworks (Kiyoko) that fixes step 1.3 in setting the Target device - see July 13 2018 ANSWERS post from Dean Oswald )

for the "hdlcoder_led_blinking.slx" example.

The code now builds a FPGA bitsteam file, but the last step (programming) now fails ; - HDL coder section 4.4 "Program The Target device".

Failed Program target FPGA device.
ask "Program Target Device" unsuccessful. See log for details.
Generated logfile: C:\ALL\SOAR\MATLAB_DEV\hdl_prj2018a\hdlsrc\hdlcoder_led_blinking\workflow_task_ProgramTargetDevice.log
Downloading target FPGA device configuration over Ethernet to SD card ...
Error executing command "mw_setboot '/tmp/hdlcoder_rd/hdlcoder_system.bit' 'devicetree_axilite.dtb' '/tmp/hdlcoder_rd' 'Default system'". Details:

STDERR: 
STDOUT: # Copied /tmp/hdlcoder_rd to /mnt/hdlcoder_rd
# Copying Bitstream hdlcoder_system.bit to /mnt/hdlcoder_rd
# Set Bitstream to hdlcoder_rd/hdlcoder_system.bit
ERROR: Devicetree /mnt/devicetree_axilite.dtb not found
ERROR: Failed to set the target devicetree

What is reported is true, the Devicetree_axilite.dtb does not exist. I can see the /mnt directory from a terminal.

/mnt/devicetree_axilite.dtb

Networking & serial comms to the Zedboard containing the Zynq device, seems to be fine, I can ping each way.

{The Zedboard is on a private ethernet link, the host machine is set to 192.168.30.3 and the Zedboard 192.168.30.2.}

The comms definately starts, becuase the Programming step fails earlier unless the COM port terminal is shut down.

( I thought the "download" method would be network-only, if you could explain the involvement of sertial, it would help...)

{ Note : I am sure this programming step has worked previously, perhaps if I targetted a generic-ASIC/FPGA workflow,

becuase my Zedboard is blinking it's red LED , This must mean that the hdl code did download and I guess program and store the HDL,

becuase the red LED now blinks from boot. ( it didn't, before I started work on this example )

So,,, is the programming 1-shot and the Zedboard SD card image require regenerating from new ?

When I got it to work, I may have not set the hdlcoder to IP core generation workflow,,,,

I might have to put in support case on this :-

( I have been generating hdl using the generic ASCI/FPGA workflow to check my code for some time without issue)

Regards,

Dr Michael Brewin. - Mike

This is the report of Z= zynq() in MATLAB that I ran after the failure.

>> z= zynq

z = 

  LinuxShell with properties:

    IPAddress: '192.168.30.2'
     Username: 'root'
         Port: 22

[Noam Levine]

Mike - A couple of things:

• Did you download both Zynq Hardware Support Packages? (Zynq support from HDL Coder and Zynq support from Embedded Coder) - the set-up process for the Embedded Coder support package will re-program the SD Card on the ZedBoard. We need to make sure that you use this MathWorks image in order for the workflow to behave properly
• You shoud be using the IP Core Generation workflow in HDL Workflow advisor, with the ZedBoard as the target hardware
• What version of Vivado are you using, and did you install the Vivado SDK as well?

Thanks,

-noam

[michael brewin]

Hi Noam,

Yes, I have both Hardware support packages installed in both versions of 2018A and 2018B.

Zynq support from HDL Coder and

Zynq support from Embedded Coder

When I intalled them, I made separately labelled SD cards.

( I read that 2018b comms is different to 2018a - change in driver from BaseOS to IIO).

With the Generic ASIC/FPGA flow, but selecting the Zynq as targer device, the 2018a set up worked to download code and flash an LED. Now, after moving to the IP-core Generation flow,

and installing the patch file to get pas the section 1.3 GUI error on setting the target device, it all works until the final step (4.4) of downloading the generated .bit file.

I have Xilinx 2017.2 vivado & Vivado SDK installed and selected as the HDL tool path, SIMULINK2018a doesn like any later version fothe Xilinx tools.

Noam, While your advice is good, I don't think it is possible to get to generating a bit file, if the setup things you describe are not all working. I noticed as this as I progressed with the 2018b setup that the the HDL coder just stops and issues warnings before getting to section 4.3 and creating a .bit file if the H/ware support packagers and VIVADO SDK tool-chain are not set up.

Meanwhile, 2018b, with the same example model "hdlcoder_led_blinking.slx" gets all the way through the HDL coder steps 1.1 to 4.4, without errors or warmings, but bizzarely, does NOT flash the LED on the Zedboard. Note, that for working with 2018b, I am using the 2018b SD card that I built, not the 2018a one.

I'm not mixing them up and making that mistake, for sure.

I think the only thing I can do is to recreate the 2018a reference Linux image, by going through the setup for one of the support packages again and re-try. I am just waiting on the arrival of a new SD card or two. I don't want to erase the 2018a image that I have - it has a blinking LED :-)

Thanks,

Mike.

[Noam Levine]

Mike - Thanks for confirming your set-up. I'm still puzzled by the results you're seeing. Let me escalate this to see if I can find a better answer for you...

[michael brewin]

Hello Noam.

The issues seem to be fixed.

I rebuilt the 2018a reference image and managed to get through all steps, rpogramming the Zedboard to blink the LED. I also noticed why the 2018b version programmed but failed to blink the LED - my mistake, I had set up the interfaces wrong. I corrected it and now I have

2018a and 2018b working with the Zeboard blinking LEDs,

I have 2 separate Linux SD cards for this.

I have seen that it is true that if section 4 is set to run -all, HDLcoder tries to program the Zedboard before the bitstream file is built.

I have also seen one one occasion a time-out in first invoking the Xilinx tools, orange warnings issued in the command .

I have not foudn a root cuase for the problem I say with the error-mesage on programming, so it may re-occur, as the erro report seemed true and described and automatic step, - but for now I am happy to say that I have both HDLcoder 2018a and 2018b working to generate and download code to my Zedboard ( & ADI RF SOM ).

Thanks for answering my questions, the fact that yhou kept repsonding with some things to try kept me going to resolve the issues, at least one of them was mine.

Regards,

Mike Brewin.

[michael brewin]

Hello again.

So, I made my new reference image and cleared out all created HDL and went through the process again. This time, after 1 timeout upset in launching in reporting not finding Vivado, the second time round, the Zedboard programmed . I attach a file to show this.

I am not sure what I did to encoutnerthe problem with the bit file not downloading and the lack of the "/mnt/devicetree_axilite.dtb" directory, but now, with the reflashed image, both 2018a and 2018b (with a different SD card image) can be programmed wit the blinked LED image, and the LEDs blink when this happens.

For now, it is best to close the case. I will re-open it or create another if it happens again.

I have previously been able to create and download .bit files - this event is not my first go. HDLcoder was working reliably on a few occasions when I used it in the last few months.

Lets close the case.

Regards,

Mike.

[Noam Levine]

Mike - Glad the problem is resolved. The folks I talked to here felt that the error message pointed to an SD card that didn't get programmed correctly (missing the device tree for some reason).

-noam

Answer 1

[Kiran Kintali]

(per Kiyoko notes)

There are some old ISE reference designs shipped in Zynq Hardware Support Package. These cause confusion. HDL Coder is deprecating Xilinx ISE reference designs for shipping Zynq boards. The programming method Download no longer works in these reference designs.

These ISE reference designs are not needed, as one can use Vivado on all the Zynq devices. We cannot completely remove ISE support, for usage with Spartan6 there is still need to support Xilinx ISE.