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.
Yeah, but I still love it for its absolute noiselessness. 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.
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.
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:
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?
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.
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.
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.
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.