am I the only one who thinks Vivado/Vitis is a muddled mess? - Page 1
Forum section: electronics / general

author: slburris
author_rank: Frequent Contributor
timestamp: August 01, 2020, 03:18:00 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: August 01, 2020, 07:05:32 pm
content: 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.

author: slburris
author_rank: Frequent Contributor
timestamp: August 01, 2020, 07:48:38 pm
content: 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 01, 2020, 08:24:47 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: August 02, 2020, 12:23:23 am
content: Quote from: slburris on August 01, 2020, 07:48:38 pmI merely matched the tone of original post...

author: slburris
author_rank: Frequent Contributor
timestamp: August 02, 2020, 01:01:34 am
content: 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 FarmBothttps://farm.bot/

author: Bassman59
author_rank: Super Contributor
timestamp: August 02, 2020, 01:59:12 am
content: 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?

author: miken
author_rank: Regular Contributor
timestamp: August 02, 2020, 03:15:05 am
content: 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.

author: 0db
author_rank: Frequent Contributor
timestamp: August 02, 2020, 04:13:31 pm
content: Will Vivado work decently on a computer with only 4Gbyte of ram?

author: 0db
author_rank: Frequent Contributor
timestamp: August 02, 2020, 04:43:45 pm
content: I am more worried about thememory recommendations. It seems 8Gbyte is decent, but ... not so much.

author: SMB784
author_rank: Frequent Contributor
timestamp: August 02, 2020, 06:57:39 pm
content: 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:

author: miken
author_rank: Regular Contributor
timestamp: August 02, 2020, 09:20:05 pm
content: 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.

author: 0db
author_rank: Frequent Contributor
timestamp: August 02, 2020, 11:37:06 pm
content: Thanks mikenNow I know I can resist until the mid 2021, postponing the purchase of the laptop dedicated to Vivado.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 03, 2020, 12:49:39 am
content: 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:. /opt/Xilinx/Vivado/2019.2/settings64.shecho source build.tcl | vivado -mode tclAnd here's the TCL for the design:Code:set_part "xc7a35tcpg236-1"# read all design filesread_vhdl ../src/systems/top_level_expanded.vhdread_vhdl ../src/cpu/riscv_cpu.vhdread_vhdl ../src/cpu/decode.vhdread_vhdl ../src/cpu/data_bus_mux_a.vhdread_vhdl ../src/cpu/data_bus_mux_b.vhdread_vhdl ../src/cpu/result_bus_mux.vhdread_vhdl ../src/cpu/program_counter.vhdread_vhdl ../src/cpu/shifter.vhdread_vhdl ../src/cpu/alu.vhdread_vhdl ../src/cpu/sign_extender.vhdread_vhdl ../src/cpu/register_file.vhdread_vhdl ../src/cpu/branch_test.vhd# The Program ROM and RAMread_vhdl ../src/program_memory/program_memory_test.vhdread_vhdl ../src/program_memory/ram_memory_test.vhd# The 'external' CPU bus - bridge, RAM and Serial peripheralsread_vhdl ../src/bus/bus_bridge.vhdread_vhdl ../src/bus/bus_expander.vhdread_vhdl ../src/peripheral/peripheral_gpio.vhdread_vhdl ../src/peripheral/peripheral_ram.vhdread_vhdl ../src/peripheral/peripheral_serial.vhdread_vhdl ../src/peripheral/peripheral_millis.vhd# board specific stuffread_vhdl ../src/boards/basys3_top_level.vhdread_xdc ../src/boards/basys3.xdc# Synthesize Designsynth_design -top basys3_top_level -part "xc7a35tcpg236-1" -flatten_hierarchy nonewrite_checkpoint basys3_top_level_synth.dcp# Opt Designopt_design# Place Designplace_design# Route Designroute_designwrite_checkpoint basys3_top_level_route.dcp# Write the bitstreamwrite_bitstream -force -file ../bitstreams/basys3_top_level.bit# Generate reportsreport_timing -nworst 1report_utilization -hierarchical

author: 0culus
author_rank: Super Contributor
timestamp: August 03, 2020, 01:20:10 am
content: 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'tneeda "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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2020, 02:40:46 pm
content: Quote from: slburris on August 01, 2020, 07:48:38 pmIMO, Vivadoissignificantly 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2020, 02:47:15 pm
content: Quote from: 0db on August 02, 2020, 04:13:31 pmWho cares if it'll run on an antique like that?

author: 0db
author_rank: Frequent Contributor
timestamp: August 03, 2020, 03:09:00 pm
content: Quote from: Sal Ammoniac on August 03, 2020, 02:47:15 pmIt'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 2012Carbon X1 G2 2014Carbon X1 G3 2015 <-------- current laptop for Vivado, 4GB of ramCarbon X1 G4 2016Carbon X1 G5 2017Carbon X1 G6 2018Carbon X1 G7 2019Carbon X1 G8 2020Carbon X1 G9 2021 <-------- future laptop for Vivado, 16GB of ramFor 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 03, 2020, 03:10:08 pm
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2020, 03:33:57 pm
content: 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.

author: BrianHG
author_rank: Super Contributor
timestamp: August 03, 2020, 05:43:02 pm
content: Quote from: Sal Ammoniac on August 03, 2020, 03:33:57 pmI 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2020, 10:33:00 pm
content: I've found that memory size and storage speed makes more of a difference in Vivado execution speed than does raw processor speed.

author: BrianHG
author_rank: Super Contributor
timestamp: August 03, 2020, 10:50:04 pm
content: Quote from: Sal Ammoniac on August 03, 2020, 10:33:00 pmOOops, 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.

author: slburris
author_rank: Frequent Contributor
timestamp: August 04, 2020, 01:13:38 am
content: Quote from: Sal Ammoniac on August 03, 2020, 02:40:46 pmOK, 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.

author: 0db
author_rank: Frequent Contributor
timestamp: August 04, 2020, 10:25:31 am
content: @slburrisYou mentioned Eagle, Diptrace, CircuitStudio, Altium DesignerWhy not KiCAD? You need to complete the collection

author: asmi
author_rank: Super Contributor
timestamp: August 04, 2020, 03:12:22 pm
content: Quote from: slburris on August 04, 2020, 01:13:38 amUnfortunately, 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).

author: laugensalm
author_rank: Regular Contributor
timestamp: August 04, 2020, 06:18:34 pm
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: August 04, 2020, 06:45:05 pm
content: Quote from: slburris on August 04, 2020, 01:13:38 amThe 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 04, 2020, 07:55:33 pm
content: Quote from: Bassman59 on August 04, 2020, 06:45:05 pmVivado is already 25G download

author: asmi
author_rank: Super Contributor
timestamp: August 04, 2020, 08:11:36 pm
content: Quote from: Bassman59 on August 04, 2020, 06:45:05 pmI seriously doubt that to be the case. Using MB to orchestrate and control HW is too convenient to not take advantage of it.

author: 0db
author_rank: Frequent Contributor
timestamp: August 04, 2020, 08:17:05 pm
content: Quote from: NorthGuy on August 04, 2020, 07:55:33 pmit there a way to reduce it? Any "light" edition?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2020, 09:52:20 pm
content: Quote from: 0db on August 04, 2020, 08:17:05 pmThe 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: August 05, 2020, 04:32:06 pm
content: 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.

author: slburris
author_rank: Frequent Contributor
timestamp: August 06, 2020, 04:06:55 am
content: Yes! Yes! I am not aloneQuote from: ralphrmartin on August 05, 2020, 04:32:06 pm

author: Fred27
author_rank: Unknown
timestamp: August 06, 2020, 08:02:21 am
content: 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: August 06, 2020, 03:29:45 pm
content: Quote from: Fred27 on August 06, 2020, 08:02:21 amIt 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...

author: asmi
author_rank: Super Contributor
timestamp: August 06, 2020, 07:39:37 pm
content: Quote from: ralphrmartin on August 06, 2020, 03:29:45 pmThis is absolutelywrongway 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 onlyafterthat 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 towho are telling you otherwise.

author: Bassman59
author_rank: Super Contributor
timestamp: August 07, 2020, 05:07:35 pm
content: Quote from: asmi on August 06, 2020, 07:39:37 pmShorter @asmi: what @ralphrmartin is describing is "hacking," not proper engineering.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: August 07, 2020, 05:14:41 pm
content: Quote from: asmi on August 06, 2020, 07:39:37 pmI 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: August 07, 2020, 05:22:51 pm
content: Quote from: Bassman59 on August 07, 2020, 05:07:35 pmIf, 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.

author: asmi
author_rank: Super Contributor
timestamp: August 07, 2020, 05:49:43 pm
content: Quote from: ralphrmartin on August 07, 2020, 05:14:41 pmThat's exactly what integration testing is for - to make sure nothing unexpected happens when you put pieces together.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: August 07, 2020, 05:50:50 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: August 07, 2020, 05:53:50 pm
content: Quote from: ralphrmartin on August 07, 2020, 05:22:51 pm"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.Quote from: ralphrmartin on August 07, 2020, 05:22:51 pmLOL. This sounds like trolling.

author: asmi
author_rank: Super Contributor
timestamp: August 07, 2020, 05:56:47 pm
content: Quote from: ralphrmartin on August 07, 2020, 05:50:50 pmYes 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.

author: asmi
author_rank: Super Contributor
timestamp: August 07, 2020, 06:06:09 pm
content: Quote from: Bassman59 on August 07, 2020, 05:07:35 pmI 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: August 07, 2020, 07:09:13 pm
content: Quote from: asmi on August 07, 2020, 05:53:50 pmIn fact, in a specification-based approach, bugs are very often the result of incomplete or inconsistent specifications.Quote from: asmi on August 07, 2020, 05:53:50 pmNot 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.

author: GrandTheftAuto4life
author_rank: Contributor
timestamp: August 10, 2020, 11:29:32 am
content: Quote from: 0db on August 04, 2020, 10:25:31 amThrow in OrCAD and NI Ultiboard while your at it.

author: Dmeads
author_rank: Regular Contributor
timestamp: August 11, 2020, 07:21:41 am
content: Quote from: slburris on August 01, 2020, 03:18:00 pmYou can program the FPGA with vivado. Use the Hardware manager in the flow navigator under "program and debug"Quote from: slburris on August 01, 2020, 03:18:00 pmRight click on your HDL code in the sources tab and click "add module to block diagram"Quote from: slburris on August 01, 2020, 03:18:00 pmBecause if you were only working on hardware, it would waste a ton of time and resources updating something you arent using.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 08, 2024, 07:48:08 am
content: That was fun.