Make -f Makefile.e300artydevkit mcs fails


I’m using Ubuntu 16.04 on VMware.

“make -f Makefile.e300artydevkit mcs” fails as follows;

$ make -f Makefile.e300artydevkit mcs
VSRC_TOP=/home/osboxes/Work/freedom/builds/e300artydevkit/sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.v EXTRA_VSRCS="/home/osboxes/Work/freedom/rocket-chip/vsrc/AsyncResetReg.v /home/osboxes/Work/freedom/rocket-chip/vsrc/DebugTransportModuleJtag.v /home/osboxes/Work/freedom/sifive-blocks/vsrc/SRLatch.v" make -C /home/osboxes/Work/freedom/fpga/e300artydevkit mcs
make[1]: Entering directory '/home/osboxes/Work/freedom/fpga/e300artydevkit'
VSRC_TOP=/home/osboxes/Work/freedom/builds/e300artydevkit/sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.v EXTRA_VSRCS="/home/osboxes/Work/freedom/rocket-chip/vsrc/AsyncResetReg.v /home/osboxes/Work/freedom/rocket-chip/vsrc/DebugTransportModuleJtag.v /home/osboxes/Work/freedom/sifive-blocks/vsrc/SRLatch.v" vivado -nojournal -mode batch -source script/board.tcl -source script/prologue.tcl -source script/init.tcl -source script/impl.tcl
awk: symbol lookup error: awk: undefined symbol: mpfr_z_sub

****** Vivado v2016.4 (64-bit)
  **** SW Build 1756540 on Mon Jan 23 19:11:19 MST 2017
  **** IP Build 1755317 on Mon Jan 23 20:30:07 MST 2017
    ** Copyright 1986-2016 Xilinx, Inc. All Rights Reserved.

source script/board.tcl
# set name {arty_e300devkit}
# set part_fpga {xc7a35ticsg324-1L}
# set part_board {}
# set bootrom_inst {rom}
source script/prologue.tcl
# set scriptdir [file dirname [info script]]
# set commondir [file dirname $scriptdir]
# set srcdir [file join $commondir src]
# set constrsdir [file join $commondir constrs]
# set wrkdir [file join [pwd] obj]
# set ipdir [file join $wrkdir ip]
# set top {system}
# create_project -part $part_fpga -in_memory
# set_property -dict [list \
#   BOARD_PART $part_board \
#   TARGET_LANGUAGE {Verilog} \
#   DEFAULT_LIB {xil_defaultlib} \
#   IP_REPO_PATHS $ipdir \
#   ] [current_project]
ERROR: [Board 49-71] The board_part definition was not found for The project's board_part property was not set, but the project's part property was set to xc7a35ticsg324-1L. Valid board_part values can be retrieved with the 'get_board_parts' Tcl command. `Check if board.repoPaths parameter is set and the board_part is installed from the tcl app store.`
INFO: [Common 17-17] undo 'set_property'

    while executing
    invoked from within
"set_property -dict [list \
  BOARD_PART $part_board \
    (file "script/prologue.tcl" line 12)
INFO: [Common 17-206] Exiting Vivado at Mon Apr 17 13:44:53 2017...
Makefile:13: recipe for target 'obj/system.bit' failed
make[1]: *** [obj/system.bit] Error 1
make[1]: Leaving directory '/home/osboxes/Work/freedom/fpga/e300artydevkit' recipe for target '/home/osboxes/Work/freedom/builds/e300artydevkit/sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.mcs' failed
make: *** [/home/osboxes/Work/freedom/builds/e300artydevkit/sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.mcs] Error 2

It seems that I have to install additional files for Arty board for vivado. But I don’t understand what does the sensense “Check if board.repoPaths parameter is set and the board_part is installed from the tcl app store.” means.

I found “Xilinx Tcl Store” button on the vivado GUI window, but I cannot find any proper packages on the list.

(Richard Xia) #2

Try following the instructions on this page to download the board files:


Thank you very much. Now “make mcs” completes sucessfully. Please let me ask you one more question.

I looked for how to upload the MCS file, and found a article, (in Japanese, sorry)

  • connecct the Arty board with USB cable

  • start vivado GUI

  • select Hardware Manager

  • Open Target -> Auto connect

  • select “xc7a35t__0 (1)”

  • right click -> Add Configuration Memory Device

  • Filter: Manufacturer: Micron, Density: 128, Type spi, width: x1_x2_x4

  • select n25q128-3.3v, OK

  • Program Configuratoin Memory Device

  • set the MCS file as Configuration File

  • OK

  • wait for about 1 miniutes

    $ cd …/freedom-e-sdk
    $ make software PROGRAM=hello BOARD=freedom-e300-arty

    $ make upload PROGRAM=hello BOARD=freedom-e300-arty
    /home/osboxes/riscv/freedom-e-sdk/bsp/tools/ /home/osboxes/riscv/freedom-e-sdk/software/hello/hello /home/osboxes/riscv/freedom-e-sdk/bsp/env/freedom-e300-arty/openocd.cfg

    • tee openocd_upload.log
    • openocd -f /home/osboxes/riscv/freedom-e-sdk/bsp/env/freedom-e300-arty/openocd.cfg -c 'flash protect 0 64 last off; program /home/osboxes/riscv/freedom-e-sdk/software/hello/hello verify; resume 0x20400000; exit’
      Open On-Chip Debugger 0.10.0-dev-g193f630 (2017-01-11-11:39)
      Licensed under GNU GPL v2
      For bug reports, read
      adapter speed: 10000 kHz
      Info : auto-selecting first available session transport “jtag”. To override use 'transport select '.
      Error: no device found
      Error: unable to open ftdi device with vid 15ba, pid 002a, description ‘Olimex OpenOCD JTAG ARM-USB-TINY-H’, serial ‘’ at bus location '

The article above is using Olimex JTAG ARM-USB-TINY-H JTag adapter.
Cannot I upload a program via USB cable as I can do with Hifive-1 board?

(Donnie Agema) #4

No, I believe you must use the debegger connection to upload programs to the Arty. See chapter 2 of the Freedom E310 Arty FPGA Getting Started Guide



Thank you for your reply. It is getting clear.

I cannot access Freedom E310 Arty FPGA Getting Started Guide as I wrote in Getting Started Guide for Freedom E300 Arty FPGA Dev Kit.

Here is my current understanding;

  • Hi-Five-1 board , ARTY board, and Olimex JTAG ARM-USB-TINY-H use FTDI2232 chip.
  • FTDI2232 on the ARTY board is only for FPGA programming.
  • Debug logic requires dedicated JTAG I/F, because it is implemented as user logic in FPGA.

I have a DIGILENT JTAG-USB Cable It does not have TRST_n nor SRST_n signal. Does anyone know how to use this instead of Olimex JTAG ARM-USB-TINY-H?

And it seems that I need additional cables to use Olimex JTAG ARM-USB-TINY-H. USB cable between PC and TINY-H.
Between TINY-H and ARTY do we have to make a cable like this?


RISC-V External Debug Support Version 0.13 Chapter 10 “JTAG Debug Transport Module” defines two JTAG TAP Registers.

  • DTM Control and Status (dtmcs, 0x10)
  • Debug Module Interface Access (dmi, 0x11)

7 Series FPGAs Configuration User Guide Chapter 10 “Advanced JTAG Usge” says we can define 4 user defined registers, USER1 (0x02), USER2 (0x03), USER3 (0x22), USER4 (0x23).

If we implement dtmcs and dmi by using 2 of 4 user defined registers, and change register assignment of OpenOCD, we don’t need additinal JTAG interface.

I don’t know how difficult it is, but I think it is worth to be considered.

(Jack Kang) #7


Sorry to hear that. In terms of the developer program which you refer to in that post, it allows for access to additional material, such at FPGA bitstream downloads. The good news is that we have taken a look at how we structured things and agree with many of you–so we are in process of moving a bunch of material (like the document mentioned) to be more freely available, without a developer agreement. Look for this next month!

However, you do still need to agree to the developer program agreement for certain items like the FPGA bitstream itself.

The exact license is there to be clicked through when you sign up for an account. We believe it is a pretty standard agreement. The basic idea is that the items on the dev site are provided as-is, and that there’s no warranty or indemnification. Legally it also allows us (just in case) to remove items, receive your feedback, and ask you to not re-distribute materials, etc.



First, I really thank your team for the great work. I feel sympathy and I’ve been evaluating RISC-V architecture by using your work.

I understand that you cannot distribute everything, ex. the FPGA bitstream includes Xilinx properties.

As for the license, I agree with you that it is really standard one. But I have to get approval from the company legal division. The problem is that there is no description what the developer program is, nor what will be provided by the agreement. I cannot explain to legal people why I have to make agreement.

Look for this next month!

Is it difficult for you to put the Getting Started Guides under sooner?


(Donnie Agema) #9

I cannot see from the picture if all of the pins are connected correctly, but yes, that is the kind of cable connection you need for program uploads to the Arty. It is described rather well in the getting started guide - hopefully Jack can get you access to that document soon.



Thank you for your info!


I find that documents including the Freedom E310 Arty FPGA Getting Started Guide were uploaded.
Thank you very much!

(Salman Sheikh) #12

I got everything installed (Xilinx Vivado 2018.3, freedom, board files, dtc, a) got the Arty to build the verilog but it fails verilog synthesis with these 6 errors at the end of my vivado.log file. Is there a way to see why this is happening in the GUI mode of vivado. Its a lot to try to digest. Shouldn’t this work out of the box. Do I need to use an older version of Vivado to make it work (i just upgraded to 2018.3 today because 2017.4 on linux didn’t have the artix devices installed, I was developing on zynq on my previous project).

WARNING: [Synth 8-4446] all outputs are unconnected for this instance
and logic may be removed [/home/local/NDC/ssheikh/freedom/builds/e300a
ERROR: [Synth 8-439] module ‘BootROM’ not found [/home/local/NDC/sshei
ERROR: [Synth 8-6156] failed synthesizing module ‘TLMaskROM’ [/home/lo
ERROR: [Synth 8-6156] failed synthesizing module 'E300ArtyDevKitSystem
’ [/home/local/NDC/ssheikh/freedom/builds/e300artydevkit/sifive.freedo
ERROR: [Synth 8-6156] failed synthesizing module ‘E300ArtyDevKitPlatfo
rm’ [/home/local/NDC/ssheikh/freedom/builds/e300artydevkit/
ERROR: [Synth 8-6156] failed synthesizing module ‘E300ArtyDevKitFPGACh
ip’ [/home/local/NDC/ssheikh/freedom/builds/e300artydevkit/

(Donnie Agema) #13

The mcs file provided in the download package (sifive_coreip_E31_FPGA_Evaluation_Arty_35T_v3p0_rc0.mcs) does work “out of the box”. I just tested it with Vivado 2018.3 and had no problems.