am I the only one who thinks Vivado/Vitis is a muddled mess?

[slburris]

I'm pretty familiar with ISE and Lattice Diamond (which looks like like ISE), but this is the first project I've done with Vivado and Vitis.  I'm doing a Microblaze design with external memory, SPI, I2C, and general I/O.   I get that the general idea is to do the hardware design in Vivado, and it generates include files and whatnot for software development in Vitis.

But intuitive?  Not to me.  If I hadn't found a workflow example which says click here, type this in here, do this, do that, I'd still be struggling. 

For Vivado, it seems to be throw a bunch of pieces into a block design, keep clicking on block automation and connection automation multiple times until they stop popping up, then generate a bitstream and send that and some other info to Vitis.  But apparently you don't program the FPGA with Vivado, you use Vitis?  Hmm, I'm more used to a flow where you program the FPGA, and then JTAG is used to insert the running program for Microblaze, presumably this is still happening under the covers.  But Vivado seems to desperately want to abstract everything away from you.   I haven't yet worked on how to get my own Verilog into the design -- presumable there's a side way to do this, or maybe I create my own IP chunk that gets dropped into the block design?  And why was it so hard to figure out how to do the pin planning for my design.  Oh, you switch to a pin planning layout when you happen to be viewing either the synthesis or implementation output?  That's not intuitive to me.  Why isn't there a pin planning/constraints button right in the left flow panel?

Then there's Vitis.  Point it at the stuff from Vivado and you're good to go, no?  Platform project?  System project?  Domain?  Say what?  Yet, I muddled through it and got an app running.  Presumably doing "program FPGA" sends the vivado bitstream, and "Launch on Hardware" puts the microblaze program into the internal blockram through JTAG.  Oh, but heaven forbid you make a hardware change in Vivado, then forget to re-export the bitstream, and tell Vitis to read it again.  Then either things don't work or they don't compile.  Why is this such a clunky way to do things?  Why isn't there a dependency between Vivado and Vitis so then when the hardware changes, Vitis knows this and updates everything as appropriate?  Ugh!

Did I miss the magic document that simply explains how everything is supposed to work and hang together?  Instead docs seem to be either marketing ("seize the future with HLS and Vivado/Vitis!") or detailed user guides about a particular topic.

[asmi]

Yes it's a mess for clueless people who couldn't be bothered to learn a tool, and instead prefer to throw the mud around. For others - it's the only free tool in it's class out there with no competitors in sight, and it's pretty logical too (even though it is buggy sometimes). If you try thinking instead of bitching, you can answer all your questions yourself.

[slburris]

Wow, that's pretty harsh.  No discussion about the user interface, the design, or anything, just "you're an idiot, go away".  I would have thought that Xilinx's $200M and 1000 man years would have produced a user interface significantly easier to use than ISE.

I'll take your comments to mean that the learning curve is high, just get used to the fact that it doesn't work they way you want, and suck it up and spend more time with the documentation.

[rstofer]

A lot of Xilinx documentation revolves around the command line.

Actually, a Makefile and the command line tools leaves more freedom for code editors and such.  I have been playing with Visual Studio Code (using it with Lattice tools) and I like the editor.  If I were using Linux, I would probably be using the command line toolchain.

I wonder how many high tier developers use the command line tools.

[asmi]

Wow, that's pretty harsh.  No discussion about the user interface, the design, or anything, just "you're an idiot, go away".

I merely matched the tone of original post...

[slburris]

Specific example here.  You have an existing microblaze project that was baremetal, but now you want to use it with FreeRTOS. You modify your block design altering the predefined configuration from Microcontroller Preset to Real-time Preset.  But...you forget to add an AXI_TIMER.  Generate bitstream, export, etc.

You launch Vitis, and go to create an application project, setting the Operating System to FreeRTOS.  What happens?  Vitis thinks for a bit, then pops up an error saying creating the domain failed.  There's a "details" button, which when you press it, and it says failed to generate the bsp sources for the domain.  OK, that's not actually any more helpful.  Close the error, and go root through the Vitis log and you find a message about the missing timer.

But why?  Can't this explanation be in the details output when you click the button?  Or better yet, you've already told Vitis what your hardware looks like with the XSA, why can't it do a hardware pre-check and when you select FreeRTOS as the OS, tell you then and there that your hardware is screwed up?

Things like this are just irritating.  Yes, some may call it "bitching", I prefer to term it a design error in the user interface.

In any case, if Vivado/Vitis are the best thing since sliced bread, and I just haven't seen the light yet, I'll accept that.

Back to working on my design - a custom motion control system for my FarmBot https://farm.bot/

[Bassman59]

I will also add the Xilinx finally got support for source-code control right with ISE 14.7.

And Vivado blew it, and as far as I can tell, continues to blow it.

There's an overcomplicated method for restoring projects with a script and yadda yadda yadda, but you know -- fuck that. It doesn't have to be that hard.

All that needs to go into the repo are the sources, the constraints and a project file that controls everything.

Instead when you create a project, you get subdirectories and crufty files and you don't know what's important and what's not, and oh by the way when you open a project just to look at stuff, files get "touched" and even though they didn't change a timestamp got updated and ...

Come on, Brand X. You can do this. Right?

[miken]

I haven't really messed around with Vitis. But my impression is that it's more a rebranding exercise than anything. Just putting everything under the "unified software platform".

Anyway, people have been complaining about the Xilinx embedded/FPGA workflow since the days of EDK, I wouldn't expect a new name to change anything.

[0db]

Will Vivado work decently on a computer with only 4Gbyte of ram?

[0db]

I am more worried about the memory recommendations. It seems 8Gbyte is decent, but ... not so much.

[SMB784]

I wouldn't know if it's a muddled mess because this is all I see when I open it on my supposedly "compatible" linux operating system:

[miken]

I have 8GB on my work laptop. Vivado starts to get clunky with moderate-sized sims. I don't attempt large FPGA builds since we have a remote build server, but something like small Artix is probably fine.

[0db]

Thanks miken 
Now I know I can resist until the mid 2021, postponing the purchase of the laptop dedicated to Vivado.

[hamster_nz]

I thought it was a bit of a lemon when I first tried using it - but Zynq designs are pretty complex because of the need to integrate over to software land. If you don't lean on the wizards and automation and design flow there are millions of ways to build things wrong. If you do lean on the wizards and automation there there are only 1000s of ways to build things wrong. 

For pure RTL I've become quite partial to using Vivado it over SSH:

Here's the build script:

Code: [Select]

. /opt/Xilinx/Vivado/2019.2/settings64.sh
echo source build.tcl | vivado -mode tcl

And here's the TCL for the design:

Code: [Select]

set_part "xc7a35tcpg236-1"

# read all design files
read_vhdl ../src/systems/top_level_expanded.vhd
read_vhdl ../src/cpu/riscv_cpu.vhd
read_vhdl ../src/cpu/decode.vhd
read_vhdl ../src/cpu/data_bus_mux_a.vhd
read_vhdl ../src/cpu/data_bus_mux_b.vhd
read_vhdl ../src/cpu/result_bus_mux.vhd
read_vhdl ../src/cpu/program_counter.vhd
read_vhdl ../src/cpu/shifter.vhd
read_vhdl ../src/cpu/alu.vhd
read_vhdl ../src/cpu/sign_extender.vhd
read_vhdl ../src/cpu/register_file.vhd
read_vhdl ../src/cpu/branch_test.vhd

# The Program ROM and RAM
read_vhdl ../src/program_memory/program_memory_test.vhd
read_vhdl ../src/program_memory/ram_memory_test.vhd

# The 'external' CPU bus - bridge, RAM and Serial peripherals
read_vhdl ../src/bus/bus_bridge.vhd
read_vhdl ../src/bus/bus_expander.vhd
read_vhdl ../src/peripheral/peripheral_gpio.vhd
read_vhdl ../src/peripheral/peripheral_ram.vhd
read_vhdl ../src/peripheral/peripheral_serial.vhd
read_vhdl ../src/peripheral/peripheral_millis.vhd

# board specific stuff
read_vhdl ../src/boards/basys3_top_level.vhd
read_xdc ../src/boards/basys3.xdc

# Synthesize Design
synth_design -top basys3_top_level -part "xc7a35tcpg236-1" -flatten_hierarchy none
write_checkpoint basys3_top_level_synth.dcp

# Opt Design
opt_design
# Place Design
place_design
# Route Design
route_design

write_checkpoint basys3_top_level_route.dcp

# Write the bitstream
write_bitstream -force -file ../bitstreams/basys3_top_level.bit

# Generate reports
report_timing -nworst 1
report_utilization -hierarchical


[0culus]

All the tools I've used in the EDA space have a significant learning curve. I've used Vivado WebPACK extensively for personal and school projects, and fully licensed Vivado at work. The one thing that is super nice about the free version of Vivado is it doesn't lock you out of nearly as many features as the free version of Altera/Intel Quartus. And it works great with the types of boards hobbyists are likely to buy. You don't need a "real" Vivado license unless you are stepping into newer, bigger parts that are steps above what Digilent is putting in their Arty series.

Fundamentally, no EDA tool is trivial to use, and they all have pain points. In some cases, tools that cost $50k+ per seat have problems that really make you wonder where all that money goes. 

[Sal Ammoniac]

Wow, that's pretty harsh.  No discussion about the user interface, the design, or anything, just "you're an idiot, go away".  I would have thought that Xilinx's $200M and 1000 man years would have produced a user interface significantly easier to use than ISE.

IMO, Vivado is significantly easier to use than ISE. No doubt about it. I can understand people who used ISE for many years not liking change, but overall I think anyone who doesn't have a lot of time invested in ISE will agree that Vivado has the better UI and is more pleasant to use.

[Sal Ammoniac]

Will Vivado work decently on a computer with only 4Gbyte of ram?

Who cares if it'll run on an antique like that?

[0db]

Who cares if it'll run on an antique like that?

It's a 5 years old laptop, equipped with a dual core i7-5600, with 256GByte SSD and 4Gbyte of (soldered) RAM. Is it antique? ... yes and no. It's good for programming, and Windows 10 works more than decently, as well as EagleCAD v7.

Carbon X1 G1 2012
Carbon X1 G2 2014
Carbon X1 G3 2015 <-------- current laptop for Vivado, 4GB of ram
Carbon X1 G4 2016
Carbon X1 G5 2017
Carbon X1 G6 2018
Carbon X1 G7 2019
Carbon X1 G8 2020
Carbon X1 G9 2021 <-------- future laptop for Vivado, 16GB of ram

For sure you cannot use modern version of Premiere on it. In fact this year I bought a brand new Apple MBP, but it's dedicated to FinalCut (I do prefer), and it's the laptop I use for my job, thus I won't load any Windows or Linux virtual machine on it.

That's why I do cared! Because I had to decide if to postpone or anticipate the purchase of the laptop to be dedicated to Vivado and on where to migrate all my other stuff!

Anyway, I will probably buy a X1 Carbon 9th Gen (2021), which will likely be have 16GB of ram since 32 GByte will be still considered an expensive premium.

[NorthGuy]

I use Vivado for VHDL design. It's certainly slow, bloated, somewhat buggy, has some memory leaks. However, I wouldn't say it's a mess. If everything worked fast and was bug-free, it would be great.

I don't use Vitis and have no need for it.

[Sal Ammoniac]

I upgraded my machine last year specifically to get better performance with Vivado. This box has 128 GB of RAM, a 16-core Threadripper, and fast NVMe SSDs in RAID-0. Vivado is certainly not "fast", even on this machine, but it's much better than it was on my previous machine.

[BrianHG]

I upgraded my machine last year specifically to get better performance with Vivado. This box has 128 GB of RAM, a 16-core Threadripper, and fast NVMe SSDs in RAID-0. Vivado is certainly not "fast", even on this machine, but it's much better than it was on my previous machine.

I hate to say it, but both Vivado and Qartus and probably others are mostly dependent on only 1 or 2 cores and your CPU maximum sustained core clock frequency & dram clock speed & CAS latency.  In other words, a sustained 5.1GHz 4 core machine will outperform a 32 core sustained 3.5GHz system with occasional 4.5GHz boost speeds.

Funny enough, I can get Quartus 9.1, 12 &13 all simultaneously compiling on one 8 core system with no slow down & they all simultaneously compile at close to top speed after the first build.  Quartus Prime just boggles everything down, takes longer to compile and doesn't even do a better job at fitting in general.

[Sal Ammoniac]

I've found that memory size and storage speed makes more of a difference in Vivado execution speed than does raw processor speed.

[BrianHG]

I've found that memory size and storage speed makes more of a difference in Vivado execution speed than does raw processor speed.

OOops, sorry, but I guess with my systems, I've always had at least 16 or 32gb ram with a near blank SSD since those were cheap.  So my bottleneck has always been the raw CPU core clock speed.

However, ram and HD may be related to the size of our projects.  My largest project for a complete build taking into consideration multicorner timing and SSN optimizations took around 4 hours to compile.  Though the FPGA was 92% full and I just squeezed out the required FMAX.

[slburris]

Wow, that's pretty harsh.  No discussion about the user interface, the design, or anything, just "you're an idiot, go away".  I would have thought that Xilinx's $200M and 1000 man years would have produced a user interface significantly easier to use than ISE.

IMO, Vivado is significantly easier to use than ISE. No doubt about it. I can understand people who used ISE for many years not liking change, but overall I think anyone who doesn't have a lot of time invested in ISE will agree that Vivado has the better UI and is more pleasant to use.

OK, I'll take that as it will eventually grow on me as I put more hours into it's use.  I still don't understand why Xilinx didn't subsume all the functionality of Vitis into Vivado and have just one program that completely understood what was going on.  They still feel like two programs that are tied together at best through exports and imports.

I think what's disappointing for me is my experience was quite different in the schematic/PCB space.  I used Eagle and Diptrace for quite a while, and then I started using CircuitStudio.  Yes, it's a watered down Altium Designer, yes it's buggy, and yes they are glacially slow at issuing updates for it.   But...I found that the user interface just clicked for me in a way the other programs did not.  Things I used to dread, like creating a new part from scratch, seem to be no big deal anymore.  Now I do everything in Circuit Studio.

I was expecting something similar for Vivado over ISE and so far, that "clicking" hasn't happened.  Maybe someday.

[0db]

@slburris
You mentioned Eagle, Diptrace, CircuitStudio, Altium Designer

Why not KiCAD? You need to complete the collection