The way in which the Chisel Freedom project for Xilinx platforms is pretty straight forward. I will suggest you to run the project for Arty board in GUI mode and become familiar with the structure of it. Most probably you’ll need to change only device family (Zynq) and pin assignments and that’s it.
You can try it and ask for any help if something goes wrong.
The repo is updated recently (I think 1 day ago?), and the flow based on README is no longer working, do you know how we get the GUI mode flow based on this repo?
Hi @dong, what do you mean that the flow based on the README is not working? Can you share what error you get? You can generate the verilog as directed by the README, then use your usual Zedboard flow to instantiate the Verilog. We’ve moved to an all-Chisel top level file, but you can still modify/replace either the generated Verilog or Chisel top-level that matches your ZedBoard’s top level.
Thanks for your reply. I got the error when I try to generate the mcs file as per README:
“
File “/projects/freedom0821/freedom/rocket-chip/scripts/vlsi_rom_gen”, line 114
for key, val in iterate_by_n(line.split(), 2)}
^
SyntaxError: invalid syntax
make1: *** /projects/freedom0821/freedom/builds/e300artydevkit/rom.v Error 1
make1: Leaving directory `/projects/digital/work/ken/freedom0821/freedom/bootrom/xip’
make: *** /projects/freedom0821/freedom/builds/e300artydevkit/sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.rom.v Error 2
”
Also, for porting e300 to zedboard, I was a bit confused about what I need to do, so for the current flow, I used all the Chisel top level to generate the top level HDL wrapper, and I just modified the pin assignment in arty-master.xdc to match the pins in zedboard. Is that it? Or did I miss anything?
I am running into two problems, the first one is console access for E300.
In Arty board, this is done by USB-UART cable (in FPGA), but in zedboard, we don’t have access to USB-UART interface via Programmable Logic (PL), but only Processing System (PS). How do we deal with that in this case?
Similarly, E300 is booted via Quad SPI (which is built-in chip on FPGA board), but in zedboard, we also don’t have access to SPI via PL. That means we can’t boot E300 in PL. How do we deal with it?
I am not too familiar with the Zedboard, but if you are already using the Olimex debugging dongle, you can connect up the other interface for UART connectivity. You would need to modify your FPGA constraints file to put the UART RX/TX lines out to pins similar to the JTAG pins, and hook them to the appropriate pins on the Olimex header.
If you want to boot from SPI and can’t access the one on the ZedBoard, you may need to connect an external SPI Flash device and again adjust the qspi pin interface to hook to those.
There may be a better answer from someone more familiar with the ZedBoard.
I have modified the constraint file of the zedboard so that all the pins are lined up, but when I connect the JTAG to PMOD header (I mapped JTAG to PMOD D header, which is same as Arty) and upload an gpio_demo program via freedom-e-sdk, I got the following errors:
adapter speed: 10000 kHz
Info : auto-selecting first available session transport “jtag”. To override use 'transport select '.
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway…
Error: riscv.cpu: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Unsupported DTM version: 15
Error: Target not examined yet
Remote communication error. Target disconnected.: Connection reset by peer.
“monitor” command not supported by this target.
“monitor” command not supported by this target.
You can’t do that when your target is `exec’
“monitor” command not supported by this target.
“monitor” command not supported by this target.
Successfully uploaded ‘hello’ to freedom-e300-arty.
I have checked my wiring between the debugger and the PMOD on the zedboard twice, and it looked fine. What would be the potential issue?
Hmmm, I would check the reset connections. Also is it possible for you to see if the TCK, TDI, TMS lines are wiggling (perhaps by connecting to some LEDs on the ZedBoard)?
I think I find out the reason (but not sure if that is exactly it). Before that, may I ask if the master clock (the clock of Arty) needs to be running for the JTAG interface to work even though TCK is from development system (PC) anyway?
I am asking because when I synthesise it, I got the warning that no clock is inferred in the design, because in order to use clock in FPGA fabric, one needs to initialise the ARM side of zynq to get the clock running on PL side.
The core clock will need to be running in order to do anything interesting with the JTAG, but you should be able to at least read the DTM registers without any other clock but TCK running.
You could make a PR of your Zedboard port to github.com/sifive/fpga-shells repo and it would be easier to see what could be going wrong.
Thanks @mwachs5, I have routed it TDO to one of the LEDs on the zedboard, and I have changed the frequency of JTAG (in the open_ocd configuration file) to 1KHz. When I am trying to upload a program to RISC-V core to debugger, I can see the led is on for ~0.5s and off. Does the mean we have a good connectivity on JTAG?
But I am still getting the error similar to the thread here:
Info : dtmcontrol_idle=5, dmi_busy_delay=1, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=2, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=3, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=4, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=5, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=6, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=7, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=8, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=9, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=10, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=12, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=14, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=16, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=18, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=20, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=23, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=26, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=29, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=32, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=36, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=40, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=45, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=50, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=56, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=62, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=69, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=76, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=84, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=93, ac_busy_delay=0
I have followed your suggestions in this thread and modified the configuration file, and the error is gone, but then I got:
Remote connection closed
“monitor” command not supported by this target.
“monitor” command not supported by this target.
You can’t do that when your target is `exec’
“monitor” command not supported by this target.
“monitor” command not supported by this target.
and nothing gets uploaded. When I run “make run_openocd PROGRAM=hello BOARD=freedom-e300-arty”, it just got seg falut. How do I resolve this error? I am wondering if this is something to do with the flash. Thins I have done:
Plug in an EXTERNAL flash, and route the qspi pins in the constraint correspondingly. Do we need to change any configuration other than constraint?
Any suggestions would be much appreciated! Thanks!
Well, what you are seeing is consistent if there is no core clock running. You can see that you can successfully access the DTM registers (clocked by TCK) but not the ones clocked by core clock (actually it looks even weirder, like perhaps reset was asserted?).
Have you figured out how to get your core clock running?
I have ported Freedom E300 SoC for zybo broad successfully. If you’re interested in this, you can check my github repository: https://github.com/gongqingfeng/freedom_zybo.
Zybo is similar with ZedBoard. Both of them belong Zynq 7000 AP series. Therefore, I guess my repository may be helpful with you.
I trying to use Olimex JATG with VCU118 using pmod but getting following error.
Open On-Chip Debugger 0.10.0+dev (SiFive OpenOCD 0.10.0-2019.05.1)
Licensed under GNU GPL v2
For bug reports: https://github.com/sifive/freedom-tools/issues
adapter speed: 1000 kHz
Info : auto-selecting first available session transport “jtag”. To override use 'transport select '.
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 1000 kHz
Error: Timed out handling USB events in mpsse_flush().
Error: ftdi device did not return all data: 0, expected 85
I compare the board schematic of Arty, Zybo and VCU118 and found VCU118 board use voltage translator 3.3v <-> 1.8 between pmod FPGA io. where as Arty and zybo board don’t have voltage translator. does this can cause this failure.