--- Quote Start ---
Greetings,
The following forms a basis for my lack of understanding how Atlera has any market share whatsoever. I present the following points of fact regarding tool usability:
- graphical incompetency
- ​launching a program will often spawn its respective window on the "average" of all displays, often in no-man's-land
- Goes without saying, but: does not play nicely (at all) with multiple displays
- CLI versions of programs function differently from their GUI "counterparts" (logically, the GUI should just be a front-end to the CLI but experimentally this does not seem to be the case)
- System Console looks, acts like a piece of software from the early 90s
- Obviously has a linked-list or realloc based text buffer so the longer you type/more you echo to the console, the slower it gets
- Extremely sluggish
- Misses keypresses frequently
- Copy/Paste functionality is hit-or-miss
- TCL proliferation is incomplete, shoddy at best
- Still using TCL from 1999
- NO DICT DATATYPE. Seriously.
- Some tools (Qsys) interface with it, some don't
- Newer renditions of tools essentially graphical updates to the same buggy core from decades ago
- sopc builder -> qsys -> platform designer
- Cryptic, unhelpful compilation messages
- Inability to log useful information
- No reproducibility
- No standardization of interfaces across versions or families when it comes to IP
- The memory interface generator. Need I say more? I could write a book on the unreliability of this IP (and to be fair Xilinx's isn't perfect either)
- Classic: Spawning your own Xvfb (X Virtual Frame Buffer) instance to cater to the CLI generating the memory interface
- That is right, spawning a fake display for a "cli" program to function
- PLLs.
- Naming conventions all over the map - capitalization (locked, Locked, LOCKED), alphanumeric ordering, naming (clk, clock, CLK_, ck)
- Different families seem to reinvent the wheel with no added value (altpll, the other pll, etc. etc.)
- PLL Dynamic Reconfiguration requires a ton of extra "IP" when it could simply be memory mapped
- Useless "devkit" resources
- an executable file (!!) that "installs the devkit resources" (??)
- Bloated with a ton of useless files including ones with syntax errors
- obviously no concern about jettisoning an "archive" of zero-value files out into the void
- ​(the excuse) "factory"
- ​All issues get routed to the, nebulous, probably non-existant, "factory"
--- Quote End ---
You clearly have no experience with Xilinx Vivado. If you did, you'd want to come back to the Quartus tools because Vivado is just a mess.
Honored Contributor
