Results 1 to 8 of 8

Thread: Problem With Basically Everything

  1. #1
    Join Date
    Jan 2018
    Posts
    2
    Rep Power
    1

    Angry Problem With Basically Everything

    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"
    Last edited by jdarchon; July 13th, 2018 at 10:28 AM.

  2. #2
    Join Date
    Oct 2008
    Location
    London
    Posts
    3,652
    Rep Power
    1

    Default Re: Problem With Basically Everything

    Quote Originally Posted by jdarchon View Post
    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"
    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.

  3. #3
    Tricky is online now Moderator **Forum Master**
    Join Date
    Oct 2008
    Posts
    6,071
    Rep Power
    1

    Default Re: Problem With Basically Everything

    Quote Originally Posted by jdarchon View Post
    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"
    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.

  4. #4
    Join Date
    Oct 2008
    Location
    Silicon Valley, USA
    Posts
    350
    Rep Power
    1

    Default Re: Problem With Basically Everything

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

    Code:
    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 '\([0-9]+ 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.
    Last edited by ak6dn; July 13th, 2018 at 11:45 PM.

  5. #5
    Join Date
    Nov 2016
    Posts
    99
    Rep Power
    1

    Default Re: Problem With Basically Everything

    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-...ht/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/Embedde...ht/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/Embedde...ht/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 ?"
    Last edited by corestar; July 14th, 2018 at 08:32 PM.

  6. #6
    Tricky is online now Moderator **Forum Master**
    Join Date
    Oct 2008
    Posts
    6,071
    Rep Power
    1

    Default Re: Problem With Basically Everything

    Quote Originally Posted by corestar View Post
    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.
    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)

  7. #7
    Join Date
    Nov 2016
    Posts
    99
    Rep Power
    1

    Default Re: Problem With Basically Everything

    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:

    Code:
        output [31:0] S_AXI_HP0_araddr,
        output [1:0]  S_AXI_HP0_arburst,
        output [3:0]  S_AXI_HP0_arcache,
        output [5:0]  S_AXI_HP0_arid,
        output [3:0]  S_AXI_HP0_arlen,
        output [1:0]  S_AXI_HP0_arlock,
        output [2:0]  S_AXI_HP0_arprot,
        output [3:0]  S_AXI_HP0_arqos,
        input         S_AXI_HP0_arready,
        output [2:0]  S_AXI_HP0_arsize,
        output        S_AXI_HP0_arvalid,
        output [31:0] S_AXI_HP0_awaddr,
        output [1:0]  S_AXI_HP0_awburst,
        output [3:0]  S_AXI_HP0_awcache,
        output [5:0]  S_AXI_HP0_awid,
        output [3:0]  S_AXI_HP0_awlen,
        output [1:0]  S_AXI_HP0_awlock,
        output [2:0]  S_AXI_HP0_awprot,
        output [3:0]  S_AXI_HP0_awqos,
        input         S_AXI_HP0_awready,
        output [2:0]  S_AXI_HP0_awsize,
        output        S_AXI_HP0_awvalid,
        input  [5:0]  S_AXI_HP0_bid,
        output        S_AXI_HP0_bready,
        input  [1:0]  S_AXI_HP0_bresp,
        input         S_AXI_HP0_bvalid,
        input  [63:0] S_AXI_HP0_rdata,
        input  [5:0]  S_AXI_HP0_rid,
        input         S_AXI_HP0_rlast,
        output        S_AXI_HP0_rready,
        input  [1:0]  S_AXI_HP0_rresp,
        input         S_AXI_HP0_rvalid,
        output [63:0] S_AXI_HP0_wdata,
        output [5:0]  S_AXI_HP0_wid,
        output        S_AXI_HP0_wlast,
        input         S_AXI_HP0_wready,
        output [7:0]  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.
    Last edited by corestar; July 15th, 2018 at 05:38 PM.

  8. #8
    Tricky is online now Moderator **Forum Master**
    Join Date
    Oct 2008
    Posts
    6,071
    Rep Power
    1

    Default Re: Problem With Basically Everything

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

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •