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

[asmi]

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

Unfortunately, it's not that Vivado is great, it's competitors are worse. By "worse" I meant not just "intuitivity", but entire offering - features, usability, performance, price. At least Vivado has some logic in it, that, once understood, makes getting the tool to do what you want it to a fairly straightforward affair.
FPGA toolset is always going to be complicated because FPGAs themselves are complicated. At least in Vivado you can design quite sophisticated HW systems without writing a single line of HDL code, which is not a simple feat to accomplish. It also allows to incorporate your own modules into IPI diagram (right click -> Add Module), and it will attempt to recognize common "buses" like AXI allowing you to connect your own modules to the rest of the system. And of course you can bypass this entire IPI diagram business, and do it all the "old" way - using only HDL code (and constraints of course).

[laugensalm]

I am certainly not clueless and worked with a few tools. From a GUI perspective, recent Vivado releases may appear as an improvement to earlier concoctions, but from the operation behind the curtains, it's still the same mess (indeed) and eventually made me migrate to a Lattice ECP5. There's still one world between Vivado and Synplify..
I'm typically putting every aspect of the work flow into one Makefile these days to be sure things are in sync (something which Xilinx seems to never get working properly).
Anyhow, there are lots of ways to make your life easier with Opensource tools. If you don't like it, change it.
I for myself just prefer an environment, that, once set up, builds and tests with one command, instead having to remember a sequence of clicks here and there. Same goes for all Eclipse based patch work. It can be really cool and it can be a mess, especially when maintenance is needed and things don't build or are out of sync and you have to find out where.

[Bassman59]

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.

The flip side of this is why put Vitis functionality into Vivado when many -- the majority, my guess -- of Xilinx customers don't care about Vitis.

[NorthGuy]

The flip side of this is why put Vitis functionality into Vivado when many -- the majority, my guess -- of Xilinx customers don't care about Vitis.

Vivado is already 25G download

[asmi]

The flip side of this is why put Vitis functionality into Vivado when many -- the majority, my guess -- of Xilinx customers don't care about Vitis.

I seriously doubt that to be the case. Using MB to orchestrate and control HW is too convenient to not take advantage of it.

[0db]

Vivado is already 25G download

it there a way to reduce it? Any "light" edition?

[Sal Ammoniac]

Vivado is already 25G download

it there a way to reduce it? Any "light" edition?

The installer itself is only about 67MB, and you can customize to a limited extent how much it will download when it installs the full package. For example, if you only use Spartan-7, you can deselect Artix, Kintex, and Virtex and it won't download those pieces. The whole download, however, will still be quite large.

[ralphrmartin]

The one thing I don't like about using Vivado and Vitis together is that there is an awful lot of rote things to do in a cycle of edit and build the fpga design, move it across, compile and run your Linux / C software. Presumably you can script all of it, and presumably it is like iot is to give you great control in complex situations. However, it would be a lot nicer if there were one integrated tool instead of two, where dependency chains were determined automatically, and you could just edit the VHDL, then build / run the whole kaboodle in one button press.

[slburris]

Yes!  Yes!  I am not alone 

The one thing I don't like about using Vivado and Vitis together is that there is an awful lot of rote things to do in a cycle of edit and build the fpga design, move it across, compile and run your Linux / C software. Presumably you can script all of it, and presumably it is like iot is to give you great control in complex situations. However, it would be a lot nicer if there were one integrated tool instead of two, where dependency chains were determined automatically, and you could just edit the VHDL, then build / run the whole kaboodle in one button press.

[Fred27]

I get where you'er coming from about the disconnect between Vivado (hardware) and Vitis (software) but I assume a far more common use case for Xilinx customers is to have two teams - or at least different team members - specializing in each of these areas. You'll notice that you can export the hardware without a bitstream. This only makes sense if the two teams have agreed an interface between themselves and the software needs to be developed before the hardware is ready.

Answering you original question - I'm fairly new to FPGAs and I didn't find Vivado too hard to get used to.

I agree that it's big and slow, and have to take Xilinx's word for it that it's necessarily so. My biggest gripe is versioning. I current have 3 versions installed as required by various examples / workshops. Moving projects between them is not as easy as it should be either.

[ralphrmartin]

... I assume a far more common use case for Xilinx customers is to have two teams [who] have agreed an interface between themselves.

It may be suited to that case, but not for the development style of "get something working, and keep modifying it step by step such that it always remains working, until it does what you want".

In my experience this style works better (*) than "try to specify it all at the start before you fully understand the problem" and later "use a debugger when something does not work as expected".

(*) Unless, perhaps, you have the kind of resources associated with aerospace etc. But even then, I'm not sure...

[asmi]

It may be suited to that case, but not for the development style of "get something working, and keep modifying it step by step such that it always remains working, until it does what you want".

This is absolutely wrong way to do things. And as your designs get more complex, you will see why. The right way to do things is decomposing design into submodules/subsystems, and developing them using simulation (in parallel if it's a team effort). Once your simulations check out, you combine them into a single piece and do what's called in software development world "integration tests" - again, in simulation. And only after that you move onto testing on a real hardware. Advantages of that approach are obvious - work is easily split into multiple people (or even multiple teams if design is complicated enough to warrant that), hardware design can proceed in parallel with HDL design process. Even for a single person designs it still makes sense - you do just enough design work upfront to figure out if pinout you want to use will work and meets all constraints and limitation of your target device, then you design HW and send it off for manufacturing, while waiting for it to arrive, you proceed with HDL design. Also you don't have to stall over long P&R process, which sometimes gets so long that you need to actually write down what you are going to test (otherwise you will forget that by the time you are ready to program the board), and you don't have to fight the tools which were designed for the approach I described above.
Once again - learn how to use simulations, this is a key to success in FPGA design world, and don't listen to who are telling you otherwise.

[Bassman59]

It may be suited to that case, but not for the development style of "get something working, and keep modifying it step by step such that it always remains working, until it does what you want".

This is absolutely wrong way to do things. And as your designs get more complex, you will see why. The right way to do things is decomposing design into submodules/subsystems, and developing them using simulation (in parallel if it's a team effort). Once your simulations check out, you combine them into a single piece and do what's called in software development world "integration tests" - again, in simulation. And only after that you move onto testing on a real hardware. Advantages of that approach are obvious - work is easily split into multiple people (or even multiple teams if design is complicated enough to warrant that), hardware design can proceed in parallel with HDL design process. Even for a single person designs it still makes sense - you do just enough design work upfront to figure out if pinout you want to use will work and meets all constraints and limitation of your target device, then you design HW and send it off for manufacturing, while waiting for it to arrive, you proceed with HDL design. Also you don't have to stall over long P&R process, which sometimes gets so long that you need to actually write down what you are going to test (otherwise you will forget that by the time you are ready to program the board), and you don't have to fight the tools which were designed for the approach I described above.
Once again - learn how to use simulations, this is a key to success in FPGA design world, and don't listen to who are telling you otherwise.

Shorter @asmi: what @ralphrmartin is describing is "hacking," not proper engineering.

[ralphrmartin]

The right way to do things is decomposing design into submodules/subsystems...combine them into a single piece and do ... "integration tests".

I am of course doing that too...

Any real system is a mix of top down and bottom up design. I was talking about the integration part. If you have any sense, you don't develop 100 subsytems and chuck them all together and see what happens. You add them into the mix gradually, making sure you understand the interactions between what already works, and what was newly added.

[ralphrmartin]

Shorter @asmi: what @ralphrmartin is describing is "hacking," not proper engineering.

If, in fact, any particular development approach is "proper engineering", how come most large software systems (with a few notable exceptions) don't work as planned or as the users want? How come bugs are found in chips?

Methodology is not engineering. Engineering done right (with sufficient understanding) is based on physics and mathematics, and guarantees results like buildings won't fall down and the like. Calling software and hardware development methodology engineering is wishful thinking.

[asmi]

Any real system is a mix of top down and bottom up design. I was talking about the integration part. If you have any sense, you don't develop 100 subsytems and chuck them all together and see what happens. You add them into the mix gradually, making sure you understand the interactions between what already works, and what was newly added.

That's exactly what integration testing is for - to make sure nothing unexpected happens when you put pieces together.

[ralphrmartin]

Finally, simulation has its limits. For example, the only way to know if a realtime deepfake system works as intended, or if some change makes an improvement, is to show the output to a human being.

[asmi]

If, in fact, any particular development approach is "proper engineering", how come most large software systems (with a few notable exceptions) don't work as planned or as the users want? How come bugs are found in chips?

"as planned" and "users want" are not the same thing. "Bugs" are usually result of insufficient test coverage, which missed certain edge cases, or if the test itself is buggy (sometimes this happens too). None of that is an indication of a faulty approach, in most cases it's an indication of incorrect and/or incomplete application of that approach.

Methodology is not engineering. Engineering done right (with sufficient understanding) is based on physics and mathematics, and guarantees results like buildings won't fall down and the like. Calling software and hardware development methodology engineering is wishful thinking.

LOL. This sounds like trolling.

[asmi]

Finally, simulation has its limits. For example, the only way to know if a realtime deepfake system works as intended, or if some change makes an improvement, is to show the output to a human being.

Yes it does have limits. But it's sufficient in 99.(9)% cases. And 100% of cases you (or me) are likely to ever encounter. If you can't think of a way to simulate something, it doesn't mean that there is no way to do it.

[asmi]

Shorter @asmi: what @ralphrmartin is describing is "hacking," not proper engineering.

I did a quite a bit of "hacking" in the beginning too (like most others I suspect), however I will be first to admit that the reason I resorted to "hacking" was my lack of systemic understanding how all that stuff worked. It also offered some gratification to boost morale for continuing learning ("yay! see it blinks in a different way now! my change works!!!!!" ), which is especially important for hobbyists.
So while important and useful in certain circumstances, I still wouldn't recommend "hacking" as a "production-ready" approach to get serious projects completed. And even when it's useful, it's best to do that in simulation.

[ralphrmartin]

... how come most large software systems (with a few notable exceptions) don't work as planned or as the users want...

"Bugs" are usually result of insufficient test coverage, which missed certain edge cases, or if the test itself is buggy (sometimes this happens too). None of that is an indication of a faulty approach, in most cases it's an indication of incorrect and/or incomplete application of that approach.

In fact, in a specification-based approach, bugs are very often the result of incomplete or inconsistent specifications.

Methodology is not engineering... Calling software and hardware development methodology engineering is wishful thinking.

LOL. This sounds like trolling.

Not in the least. I'd remind you of the highly respected book called "The Art of Electronics". The authors chose this title for a very good reason. Methodology is indeed an art, not engineering. People keep coming up with "magic bullet" methodologies, and have been for years. None of them work very well, which is why people keep inventing new ones.

Some methodologies work better for some kinds of development than others. "Hacking" works well when you are doing research and don't yet know what is or isn't going to work. Specification driven development works well when you have a very well understood problem, with a well-defined goal, and well known methods of achieving the goal.

And in fact, my area is visual computing, where the human needs to be in the loop.

 

[GrandTheftAuto4life]

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

Why not KiCAD? You need to complete the collection 

Throw in OrCAD and NI Ultiboard while your at it.

[Dmeads]

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.

You can program the FPGA with vivado. Use the Hardware manager in the flow navigator under "program and debug"

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?

Right click on your HDL code in the sources tab and click "add module to block diagram"

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!

Because if you were only working on hardware, it would waste a ton of time and resources updating something you arent using.