Re: Problem With Basically Everything

Altera_Forum · ‎07-13-2018

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"

Altera_Forum · ‎07-14-2018

--- 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 ---

I agree certainly. Almost all what you said applies to any software tool. I am equally angry whenever I sit next to my PC.

My first experience with Xilinx ISE clutter of tools was a total shock. In fact I never learned how to download the bitstream.

I blame design and development culture. Unlike the rigid designs of old analogue days now software allows easy changes and the engineers have no mercy.

Here is just some points off the top of my head:

1) a variety of options and routes to do same task from keys to icons to their combinations

2) flood of links to lists with further links linking to further links...

3) Change of versions for the sake of change after the users got all the pain of getting used to them.

4) Lies of how user friendly GUI they got in the latest greatest

5) Licensing itself is now a headache to get or install. Some greedy companies charge further lower subtool licenses or feature based licenses.

6) compatibility issues a nightmare. Whether between tools or between new/old, version control tools like svn seem useless in the long run as underlying tools change and an old design will not run after few years.

7) Design culture has tons of code everywhere, folders and subfolders and subsubsubfolders. Files copied everywhere.

It is strange that these tools work for business and are maintained given the chaotic number of versions.

Finance tools never get wrong in money calculations and bank accounts??

Atera/Xlinx/Modelsim command line Vs Gui is another story so is MATLAB Vs simulink.

Altera_Forum · ‎07-14-2018

--- 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.

Altera_Forum · ‎07-14-2018

I dunno, I don't have a problem with the Altera Quartus tools at all. I set them up to use a Makefile:


DESIGN=MY_DESIGN_NAME
all:: generate report
generate::
    $(QUARTUS_BIN)/quartus_map $(DESIGN) --write_settings_files=off
    $(QUARTUS_BIN)/quartus_fit $(DESIGN) --write_settings_files=off --seed=1
    $(QUARTUS_BIN)/quartus_asm $(DESIGN) --write_settings_files=off
    $(QUARTUS_BIN)/quartus_sta $(DESIGN)
    $(QUARTUS_BIN)/quartus_sta -t generate_timing.tcl $(DESIGN) 10
    $(QUARTUS_BIN)/quartus_eda $(DESIGN) --write_settings_files=off -c $(DESIGN)
    $(QUARTUS_BIN)/quartus_cpf -c $(DESIGN).cof
report::
    @-echo ' '
    -egrep --color -i '\(+ violated\)' TQ_*.rpt
    @-echo ' '
    -egrep -vi '^this panel reports' TQ_fmax_summary.rpt
    @-echo ' '
clean::
    -rm -f $(DESIGN).*.rpt $(DESIGN).*.summary $(DESIGN).*.smsg $(DESIGN).map
    -rm -f $(DESIGN)_assignment_defaults.qdf TQ_*.rpt PLL*.txt meminit.txt
    -rm -f $(DESIGN).done $(DESIGN).map $(DESIGN).pof $(DESIGN).sof $(DESIGN).jic
    -rm -f $(DESIGN).pin $(DESIGN).jdi $(DESIGN).qws $(DESIGN).*.ddb $(DESIGN).sld
    -rm -rf db incremental_db simulation
#  the end

so to rebuild a design after changes I just go to my design directory and type 'make' ...

I do all my designs in verilog, and write my own .qsf and .sdc files manually via text editor to guide the placement and routing result.

Altera_Forum · ‎07-15-2018

I think we all feel your pain :), but the short answer to your question as to how Altera can have any market share is that Xilinx has their own set of issues.

I agree with most of your items, but if I can get around something reasonably easily I call it a nuisance. It is bizarre that Altera can't size and position dialogs and they often go off screen. Probably due to the use of some wizard to create the dialog and it only works on one screen resolution. But it's no more bizarre than Xilinx choosing a minute font for Vivado and declaring it to be a non-issue. I posted this 5 years ago and they still have not fixed it and there is no way around it:

https://forums.xilinx.com/t5/design-entry/how-do-i-increase-the-font-size-in-the-vivado-ide/m-p/349879/highlight/true#m15213

For the most part, I greatly prefer Quartus to Vivado. For example, I used to use Xilinx ChipScope. What a piece of garbage. SignalTap is a superb tool I use all the time. The thing that first motivated me to look at Altera was the Xilinx JESD204b core. I spent weeks (including a call to the developer in Scotland) to no avail. I tried Altera's JESD204b core and had it working in a few hours.

To me, Altera's number one downside is their ridiculous unusable SoC tool flow. The Altera SoC tool flow is so moronic, I may be forced back to Xilinx. I hate to do that because the Altera hardware is superior (another reason they have market share). Also, although the Xilinx SoC tool flow makes Altera looks foolish, the actual quality of the tools is not so good. For example, Xilinx has a long standing bug in their cache functions:

https://forums.xilinx.com/t5/embedded-development-tools/bug-s-in-xil-dcacheinvalidaterange-in-standalone-v-3-11-a/m-p/389395/highlight/true#m29482

Altera does not need such functions since they had sense enough to make peripherals cache coherent. I occasionally look at the Xilinx forums and laugh when I see posts to the effect of "... why are the last few bytes of my packet corrupt ...". I could go on and on about bugs in Xilinx SoC libraries. Just one more example:

https://forums.xilinx.com/t5/embedded-development-tools/driver-macros-need-parenthesis-around-arguments/m-p/365771/highlight/true#m28688

The Xilinx geniuses were not bright enough to put parenthesis in C macros. This is C programming 101. Instead of fixing the problem, throughout the Xilinx drivers you would see things like XEmacPs_Transmit((&emac)); where they put the () at the call instead of in the macro.

You mention standard interfaces. Be careful what you wish for. Xilinx standardized on AXI for EVERYTHING! Even a multiplier. And worse, their SoC has AXI 3 but they decided to standardize cores on AXI 4 so you need bridges. AXI is a ridiculously complicated bus that serves no useful purpose for most FPGA cores. Thank you Altera for using a simple Avalon bus when possible.

These are just examples to show that both have issues. To me, Altera's issues are much more easily fixed but they don't seem to have any intention of doing so. Developers tend to want to work on "fun" stuff and Altera management needs to say you can't do that until some fundamental tool issues are fixed.

The number two Altera downside would have to be Qsys but this could go on forever. I avoid it to the extent possible, but you can't when using the SoC tools.

I guess I would change your post to ask "How to either one of these companies have any market share :) ?"

Altera_Forum · ‎07-15-2018

--- Quote Start ---

You mention standard interfaces. Be careful what you wish for. Xilinx standardized on AXI for EVERYTHING! Even a multiplier. And worse, their SoC has AXI 3 but they decided to standardize cores on AXI 4 so you need bridges. AXI is a ridiculously complicated bus that serves no useful purpose for most FPGA cores. Thank you Altera for using a simple Avalon bus when possible.

--- Quote End ---

I would argue the other way around. AXI is very simple with no configuration paramters, Wheres Avalon has fewer connecting signals but loads of behavior parameters. All AXI channels behave the same - if ready and valid are high at the same time, a transaction occurs. This is NOT true of avalon, as you have that annoying "ReadyLatency"/"waitrequestAllowance" parameter meaning that if ready is de-asserted, you need to know how many cycles you have already been valid with ready low before you can stop sending. This makes debugging harder.

I can understand why Altera went this way, as years ago timing wasnt as good and so pipelining these things was a good idea. But now timing for logic cells is much easier, I prefer to see instantly whether a transaction occured or not.

There is also the argument the only people that use Avalon are Altera. When Altera had the Arm SoC parts the soc there was also AXI3, so is no blameless in this respect either. Then you had to bridge everything from AXI3 to Avalon also rubbish.

AXI is industry standard, many IP cores use AXI and so it can all talk to each other. If you try and port some 3rd party IP to Altera you'll probably need an Avalon AXI bridge. Add to that the free verification IP you can get for AXI, plus the other tons of vendor support it just makes your life easier. The Avalon verification IP is just rubbish (or non-existant). Altera are now stuck with Avalon as the majority of their IP uses it. And now they are Intel, even less incentive to use AXI.

In general though, Of all the people I know that have used both Altera and Xilinx tools, Altera is always the winner (I dont know anyone that has used lattice, MicroSemi or Atmel)

Altera_Forum · ‎07-16-2018

Tricky,

Some good points. And if someone is just using a wizard to connect IP that understands AXI, the complexity does not matter. And to be fair, the Xilinx multiplier and other cores are using AXI stream which is quite simple. It sounds like you are referring to AXI Lite which is not too bad. My comments were based on my experience of having to implement a full AXI bus in my own user IP. Just listing the signals is exhausting and it requires a state machine to handle transactions:


    output  S_AXI_HP0_araddr,
    output   S_AXI_HP0_arburst,
    output   S_AXI_HP0_arcache,
    output   S_AXI_HP0_arid,
    output   S_AXI_HP0_arlen,
    output   S_AXI_HP0_arlock,
    output   S_AXI_HP0_arprot,
    output   S_AXI_HP0_arqos,
    input         S_AXI_HP0_arready,
    output   S_AXI_HP0_arsize,
    output        S_AXI_HP0_arvalid,
    output  S_AXI_HP0_awaddr,
    output   S_AXI_HP0_awburst,
    output   S_AXI_HP0_awcache,
    output   S_AXI_HP0_awid,
    output   S_AXI_HP0_awlen,
    output   S_AXI_HP0_awlock,
    output   S_AXI_HP0_awprot,
    output   S_AXI_HP0_awqos,
    input         S_AXI_HP0_awready,
    output   S_AXI_HP0_awsize,
    output        S_AXI_HP0_awvalid,
    input    S_AXI_HP0_bid,
    output        S_AXI_HP0_bready,
    input    S_AXI_HP0_bresp,
    input         S_AXI_HP0_bvalid,
    input   S_AXI_HP0_rdata,
    input    S_AXI_HP0_rid,
    input         S_AXI_HP0_rlast,
    output        S_AXI_HP0_rready,
    input    S_AXI_HP0_rresp,
    input         S_AXI_HP0_rvalid,
    output  S_AXI_HP0_wdata,
    output   S_AXI_HP0_wid,
    output        S_AXI_HP0_wlast,
    input         S_AXI_HP0_wready,
    output   S_AXI_HP0_wstrb,
    output        S_AXI_HP0_wvalid

I had to read the AXI spec in great detail and did not find it at all simple although the state machine did not end up being too complicated.

I've never had to deal with an Avalon bus where I didn't just respond in one clock cycle. I see in the Avalon spec that the default values for "ReadyLatency"/"waitrequestAllowance" you mention are 0 and the defaults for the others correspond with what I've called "simple". I see what you're saying; if those were nonzero, it would get VERY complicated! I agree, I'd rather deal with the 30 extra lines of AXI at that point. Can you point me to a core where that is the case (I'm just curious)?

We've used Lattice and Microsemi tools. Lattice is not too bad. Microsemi is bad and painfully slow and their chips are FLASH based so it takes several minutes to program them each time. Their PolarFire FPGA is actually impressive and makes Cyclone V look pretty dated, but we stayed with Altera due to tools and price. Neither has any real support and are nowhere near as good as Altera. To me, one of the best things about Altera was the superb free online training videos/labs for Quartus. They don't seem to be updating them for new releases though. And the Altera SoC training is pretty bad/nonexistant. If they are going to have a horrid SoC tool flow they could at least have good training for it. The NIOS tools are actually pretty reasonable; why in the world didn't they just replicate it?

My biggest concern at the moment is that all Intel seems to care about are high-end chips for servers and AI and those of us in the middle will be forgotten.

Altera_Forum · ‎07-16-2018

You forgot to list all the "_xuser" optional signals in the AXI spec :)

But honestly, most of them are not needed for most applications. Where most FPGA engineers would use AXI would be some external memory controller, and here you probably dont care about caching, quality of service, lock, protect and maybe not even ID. These are usally just left as a constants. Then the rest of the design will probably be AXI Streaming (which can connect pretty easily to the wdata/rdata channel). At least with AXI4 (over AXI3) you dont need to care about out of order write transactions. But a lot of these signals, while they do have meaning,

My only experience with non-zero readyLatency was in the Altera RapidIO core, where readyLatency is 1, and I had to connected it to an AXIS interface. Its not all that hard, you can just use a FIFO and connect ready to the almost full from the FIFO, and set the almost full threadhold to be "readyLatency". But it does mean a FIFO at every interface! Otherwise not much direct involvement with Avalon - just plumbing busses together in QSYS/SOPC.

Altera SoCs are dead. They missed the boat by a couple of years and Xilinx ran away with the Zynq parts (although they had had Hard PowerPC parts for years prior to these). So Altera didnt get any SoC traction and basically just abandoned them. Now they're trying to bring the x86/FPGA hybrid parts to market. Im in Xilinx land now so dont really know how its all coming along. But from the forum it seems most problems are coming from OpenCL users (which is what they're aiming the new parts at).

corestar · ‎08-07-2018

I have to change my answer ( I see all my old posts are listed as by "Altera Forum (Intel)" ).

Is Intel actively trying to destroy Altera? Does Intel hope to have any market share whatsoever? I was already looking at going back to Xilinx due to Altera's ludicrous SoC tools, but now wonder if Intel ever plans to come out with new FPGA's for anything other than data center. I've been trying to use these new forums, but they can't even get that right. Is Altera dead?

People like Tricky and a few others, who did Altera's support job for them for years and years, are now listed as beginners. Intel seems to have no clue as to what they've done and how important these forums were.

I'm sure this will be ignored, but I feel better ... Off do download Vivado and see if I can stomach it.

JDarc · ‎08-08-2018

OP here. I have no idea what happened with this thread, but it ironically serves to prove my original point. Absolutely nothing to do with these tools or surrounding user experience is usable. Even the forums...