Problem synthesizing Verilog created by Chisel

I am running Vivado under Windows on a Lenovo laptop

and Ubunto 16.04. on a virtual machine

Synthesis in Vivado takes abiout 18 minutes:
synth_design: Time (s): cpu = 00:17:42 ; elapsed = 00:17:54 . Memory (MB): peak = 1688.258 ; gain = 1475.910

I have not yet been able to implement successfully, so I cannot report how long implementation or bitfile generation and upload takes.

I can’t give an exact time for the make in Chisel, but as I recall it took a few or more hours.May have completed faster had I run it with parallel jobs parameter.

Hmm. N3540 looks like about 1000 - 1100 per core on Geekbench3. So 40% the speed of my i7-2720QM MacBook Pro, or 20% the speed of my i7-6700K Linux desktop.

So synthesis times should be reasonable here.

I guess there’s nothing to stop me trying Chisel without an Arty.

Something seems wrong with the XDC constraint files:

Yeah, but I still love it for its absolute noiselessness. :relaxed: I banned my power PCs to the washroom where they can make all the noise they want. When I do serious compute work, I connect and run there remote.

I also see that it is not finding the generated IP. You will need to generate the IP so you can use it (this is for the clock generation block and the System Reset block. In the freedom flow, this is done by a TCL script:
https://github.com/sifive/freedom/blob/master/fpga/e300artydevkit/script/ip.tcl

In the screenshot, It has ‘dut’ is bolded, which makes me think that it is still trying to use E300ArtyDevKitTop as the Top-level. Make sure that “system.v” is selected as the top for the entire synthesis/placement flow.

Sure. My machine for that stuff is a MacBook Air. Can’t even notice the speed difference with web browsing, spreadsheets etc. Notice a BIG difference building things such as the freedom-e-sdk, which is almost five minutes on my big machine. It could well be an hour on the Air.

Big tower PCs don’t have to be noisy. It’s surprisingly few extra dollars to spec them with cases with thicker walls, insulation, bigger and better and slower fans. Very hard to find pre-built though.

Hi Megan,

I get errors when running any of the tcl scripts. Can it be that I am in the “wasn`t meant for Windows” trap?

I set the system.v file to top, and worked out the right sequence for running the tcl scripts to get the ip generated, but I am still getting the “set_property” errors in the XDC contraint files:

What is on the line it’s complaining about?

Well, this is embarrassing, but after I restarted Vivado the synthesis and impeimentation ran without errors. :blush:

Hi Megan,

I am trying to get around the cricial warnings issued on three lines of the arty-master.xdc constraint file. The error message is saying that the objects clkbfout_mmcm_1, clk_out1_mmcm_1 and clk_out2_mmcm_1 do not exist in the design, but when I run “report_clocks” they do appear. And since the xdc file is the last to be compiled, I don’t think it can be caused by wrong compile sequence. Do you have any hints? Is it OK to just ignore these warnings?

Hi Donnie,

Were you able to get your design compiling successfully even with those warnings? I will take a look at our flow and see if the warnings exist and perhaps we should just remove those lines from the constraint file. I’m guessing those constraints don’t apply anymore to this design.

Well, I can generate a bitfile, but the implementation is failing so many timing restrictions that a am rather hesitant to upload it to the Arty.

Hm, where did you get that constraint file arty-master.xdc from? It looks different from the one here:

https://github.com/sifive/freedom/blob/master/fpga/e300artydevkit/constrs/arty-master.xdc#L9

I got the constraint file here: freedom/fpga/e300artydefkit/constrs/arty-master.xdc
The contrent is identical, at least as far as what you posted.

This file is a general .xdc for the ARTY Rev. B

To use it in a project:

- uncomment the lines corresponding to used pins

- rename the used ports (in each line, after get_ports) according to the top level signal names in the project

Clock signal

set_property -dict { PACKAGE_PIN E3 IOSTANDARD LVCMOS33 } [get_ports { CLK100MHZ }]; #IO_L12P_T1_MRCC_35 Sch=gclk[100]
create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports {CLK100MHZ}];

##Switches

set_property -dict { PACKAGE_PIN A8 IOSTANDARD LVCMOS33 } [get_ports { sw_0 }]; #IO_L12N_T1_MRCC_16 Sch=sw[0]
set_property -dict { PACKAGE_PIN C11 IOSTANDARD LVCMOS33 } [get_ports { sw_1 }]; #IO_L13P_T2_MRCC_16 Sch=sw[1]
set_property -dict { PACKAGE_PIN C10 IOSTANDARD LVCMOS33 } [get_ports { sw_2 }]; #IO_L13N_T2_MRCC_16 Sch=sw[2]
set_property -dict { PACKAGE_PIN A10 IOSTANDARD LVCMOS33 } [get_ports { sw_3 }]; #IO_L14P_T2_SRCC_16 Sch=sw[3]

##RGB LEDs

set_property -dict { PACKAGE_PIN E1 IOSTANDARD LVCMOS33 } [get_ports { led0_b }]; #IO_L18N_T2_35 Sch=led0_b
set_property -dict { PACKAGE_PIN F6 IOSTANDARD LVCMOS33 } [get_ports { led0_g }]; #IO_L19N_T3_VREF_35 Sch=led0_g
set_property -dict { PACKAGE_PIN G6 IOSTANDARD LVCMOS33 } [get_ports { led0_r }]; #IO_L19P_T3_35 Sch=led0_r
set_property -dict { PACKAGE_PIN G4 IOSTANDARD LVCMOS33 } [get_ports { led1_b }]; #IO_L20P_T3_35 Sch=led1_b
set_property -dict { PACKAGE_PIN J4 IOSTANDARD LVCMOS33 } [get_ports { led1_g }]; #IO_L21P_T3_DQS_35 Sch=led1_g
set_property -dict { PACKAGE_PIN G3 IOSTANDARD LVCMOS33 } [get_ports { led1_r }]; #IO_L20N_T3_35 Sch=led1_r
set_property -dict { PACKAGE_PIN H4 IOSTANDARD LVCMOS33 } [get_ports { led2_b }]; #IO_L21N_T3_DQS_35 Sch=led2_b
set_property -dict { PACKAGE_PIN J2 IOSTANDARD LVCMOS33 } [get_ports { led2_g }]; #IO_L22N_T3_35 Sch=led2_g
set_property -dict { PACKAGE_PIN J3 IOSTANDARD LVCMOS33 } [get_ports { led2_r }]; #IO_L22P_T3_35 Sch=led2_r

I assume you are referring to the lines following 231. I checked my pulled github directory and find also only 231 lines. The file is actually the same as you referenced. Vivado must have added those new lines automatically. I deleted them and reran the implementation. The 4 related critical errors dissappeared, but the timing errors still remain.

. . . getting some moral support - always welcome! :heart_eyes:


Hi Bruce,

For what it`s worth, I just ran across a post spelling out some advantages of using LiteX for FPGA developement, which suggests a four-fold reduction in fabric utilization and faster synthesis. I have not tried it out yet, but I do intend to do so, as it might enable getting multiple HiFive1 cores into the Arty and/or Z7.

Cool. Hopefully I’ll be able to start seriously playing with FPGAs soon, now this stuff is not just for unused evenings.

Reading Bunnie’s article, it seems that LiteX is something comparable to the Berkeley “Chisel” design language that is used to generate the Verilog for Rocket-based RISC-V cores.