5 ms·

Overall semiconducting industry seems to be way more exciting than boring computer industry

artemonster 5y ago
ha! I guess you haven't worked as a designer or verification engineer, designing chips then? let me tell you: you work with a commitee-designed c++ like abomination language with 300 non-composible keywords that make no freaking sense. all of that crap grew from legacy-upon-legacy of crutches as an attempt to fix the goddamn broken-by-design verilog. Ultimately, this craplanguage + library that is 90% non-debuggable macros, works only with ~3 vendor simulators (all 3 would do different stuff on big designs and you are locked almost forever). When you simulate you designs, most of external components would be either encrypted blackboxes or be calling "magic" functions (called system tasks) that are absultely opaque to you and do some global side-effects. All of this multiplied by the fact that every statement is executed in parallel in your huge design and evolves in time. Oh, did I mention how crappy the actual tools are? Think of 90's era with outdated and moronic UI/UX, some poorely integrated quasi-TCL interpreter for configuration & ability to crash that tool in <3 clicks. Ah, you will be paying 15kUSD/year per license, thank you very much. You will be needing lots of them (> 50).
- spaniard89277 5y ago
  Hmmm, isn't there people pushing for better standards, language, tools?
  - Heliosmaster 5y ago
    Yes there is. But moving at enterprise speeds. Python considered "new" and young. Codebases are 30 to 40 years old
  - artemonster 5y ago
    there are some developments, but mostly you would get new additional tool on top of existing stack, rather than a new stack. Problem 1. patents. in early FOSS days people got momentum to push hard for corporations to give up compiler patents and other obvious nonsense and let GCC flourish. same situation is here in hardware, the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence. Problem 2. features. there are a lot of features that you need to push out a working chip into an existence. open source tools or alternatives are SO far behind that they cannot be used or can be used only on something really small. Problem 3. verification. there are no (VIABLE! that python coco stuff doesnt count!) open-source alternatives to UVM (uvm as a library is open source, but there are either no simulators that can run it). If we had some of the older verificaion languages to go open source (like specman, vera), maybe we had a chance.
    - adwn 5y ago
      > the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence. Doesn't that apply to basically every kind of software? How's it different for HDL simulation software?
      - artemonster 5y ago
        the point is that for FOSS there was an active movement that forced IBM and old megacorps to forfeit such "nonsense" patents. So if you roll out a brand new c++ compiler you may have some buffs with intel if you try to go to their turf about some propreitary x64 specific optimizations, but, say, IBM wouldnt sue you because you dared to create "a program/method of transforming source code into machine code" that violated 250 patents from their portfolio.
        adwn 5y ago
        I get that, but you wrote: > the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence Do you think a startup selling a new HDL simulator is any more at risk of getting sued than any other software-based startup? Not trying to be combative, I'm genuinely curious.
        artemonster 5y ago
        Yes. Happened twice? already
        adwn 5y ago
        Really? Wow! Do you happen to remember their names?
        artemonster 5y ago
        one remember - "magma automation". they were sued to pieces and then bought out
  - Ericson2314 5y ago
    https://clash-lang.org/ https://clash-lang.org/ http://www.clifford.at/yosys/ http://www.clifford.at/yosys/ I am hoping we can start proving many if the things they brute-force model check today, too.
- Heliosmaster 5y ago
  Or working with a 40M Loc codebase started in the 80s with 50% code duplication. Because it's so mission critical that nobody really touches existing code. Or that everything needs to be rubber-stamped by a ton of people and even a rename takes months to make it in the codebase. Oh well. That's probably every enterprise
  - tralarpa 5y ago
    As somebody without any experience in that field: When you say "codebase", what is that? Is it code describing circuit blocks (e.g. an ALU) that is reused in different projects or is it code for the tools that you use? (in-house tools, plugins for commercial tools, etc.)
    - Heliosmaster 5y ago
      There are several machines required to make a chip, and many steps involved. Those machines are crazy complex and accurate (i remember having a precision of around 3 atoms of silicon, femtometer scale). I meant firmware fot these machines, in general. Crazy complex (and amazing) tools with complex software
  - ineedasername 5y ago
    That's probably every enterprise Yep, pretty much any industry or individual organization that's been around for 40 years will have decades-old cruft complicating attempts to make changes. That's why it's good to have some sort of skunkworks unit as well.
- dataflow 5y ago
  Any thoughts on Chisel?
  - artemonster 5y ago
    as much as it pains to say me, but IMO its a wasted effort. we don't need new design languages. VHDL/Verilog "pain points" as RTL are tiny and don't require solving, we pretty much figured out design. Verification, on the other hand, is still an evolving (now stagnating) mess that needs inputs. The biggest offender on that project list is FIRRTL. Cleary outgrew as someone's university work of "hey, lets do IR, but for RTL" without knowing anything of the industry, tools, etc. At best you can do the same with one reduced canonical simplified verilog source-to-source translation. at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.
    - GregarianChild 5y ago
      Chisel's being hooked into the Java / Scala tool chain give makes setting up automated verification pipelines much easier: - You can use SBT or MVM to pull in dependencies - You can wrap up designs as .jar files - Powerful testing tools like QuickCheck come ready made None of the above is rocket science, but simply by being there things become easier. without knowing anything of the industry, tools, It's pretty difficult for a student to find out about what is actually used in industry. The semi industry's secrecy doesn't help. But software and hardware people really don't even have a shared language, and misunderstand each other's abilities and pain points. The very term "verification" is understood quite differently between the different communities.
    - ekiwi 5y ago
      > At best you can do the same with one reduced canonical simplified verilog source-to-source translation. Parsing Verilog and generating valid Verilog is fairly difficult. If you want to stay with Verilog, the most realistic alternative to firrtl right now is the RTL-IL representation used inside of yosys. > at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax. Canonicalized LoFirrtl (i.e., the representation the compiler lowers Chisel to) is essentially SSA (single static assignment) which encodes a dataflow DAG. So on a per module level, firrtl does represent the circuit as a graph. What you might be talking about is the fact that this graph isn't global. Having a global circuit graph could make some analyses easier, but it might require essentially in-lining the whole circuit which is something a lot of designers are opposed to. Even small optimizations like removing unused pins from internal modules are often times opposed. Chris Lattner and others are currently working on an "industry" version of firrtl as part of the CIRCT hardware compiler framework: https://github.com/llvm/circt https://github.com/llvm/circt As you can see they did not decide to go with a global graph based IR and instead opted to just represent local data-flow graphs as SSA.
- lordnacho 5y ago
  What's the compensation / benefits / work-life balance like?
  - iancmceachern 5y ago
    My experience in this industry is that it pays well, good benefits, but it ebbs and flows much like the defense industry with large boom times and slower times with large layoffs.
- m1kal 5y ago
  From FPGA design point of view SystemVerilog is OK. I think it gives high enough level of abstraction to create even complex systems. It can also be readable after some years if care is taken to keep the code clean. But I believe we need LISPy syntax - mainly for simplicity, also for easier parsing and static analysis. I think LISP is a natural way to describe data flow. Unfortunately none of the attempts to write functional synthesizable code that I found so far make the code simpler. BTW I'm preparing a talk on simplifying RTL code. Can I cite some of your posts in this thread?
baybal2 5y ago
Pure sarcasm, but no :) > Overall semiconducting industry seems to be way more exciting than boring computer industry The most groundbreaking things all tech must be about are cat video websites, and internet companies :D People completely forget that were Morris Chang (the previous CEO of TSMC,) not been polite, and ethical to a fault, the industry would've still be dominated by monster big semis, manufacturing every chip around, and who would've milked all big chip users like internet companies to death. I can't imagine Panasonic, Toshiba, Motorola, or AMD of old not scheming to squeezing their clients to the last cent, and strategizing to prevent clients from gaining negotiating power. TSMC's benevolent stance in comparison to that would be almost bordering on charity.
thehappypm 5y ago
I've worked on hard science problems and while it's more bleeding edge it's all very, very slow moving. You're not shipping anything in less than a year, max. And that's OK. It's just very glacial and you go VERY deep into the topic.

ha! I guess you haven't worked as a designer or verification engineer, designing chips then? let me tell you: you work with a commitee-designed c++ like abomination language with 300 non-composible keywords that make no freaking sense. all of that crap grew from legacy-upon-legacy of crutches as an attempt to fix the goddamn broken-by-design verilog. Ultimately, this craplanguage + library that is 90% non-debuggable macros, works only with ~3 vendor simulators (all 3 would do different stuff on big designs and you are locked almost forever). When you simulate you designs, most of external components would be either encrypted blackboxes or be calling "magic" functions (called system tasks) that are absultely opaque to you and do some global side-effects. All of this multiplied by the fact that every statement is executed in parallel in your huge design and evolves in time. Oh, did I mention how crappy the actual tools are? Think of 90's era with outdated and moronic UI/UX, some poorely integrated quasi-TCL interpreter for configuration & ability to crash that tool in <3 clicks. Ah, you will be paying 15kUSD/year per license, thank you very much. You will be needing lots of them (> 50).

spaniard89277 5y ago
Hmmm, isn't there people pushing for better standards, language, tools?
- Heliosmaster 5y ago
  Yes there is. But moving at enterprise speeds. Python considered "new" and young. Codebases are 30 to 40 years old
- artemonster 5y ago
  there are some developments, but mostly you would get new additional tool on top of existing stack, rather than a new stack. Problem 1. patents. in early FOSS days people got momentum to push hard for corporations to give up compiler patents and other obvious nonsense and let GCC flourish. same situation is here in hardware, the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence. Problem 2. features. there are a lot of features that you need to push out a working chip into an existence. open source tools or alternatives are SO far behind that they cannot be used or can be used only on something really small. Problem 3. verification. there are no (VIABLE! that python coco stuff doesnt count!) open-source alternatives to UVM (uvm as a library is open source, but there are either no simulators that can run it). If we had some of the older verificaion languages to go open source (like specman, vera), maybe we had a chance.
  - adwn 5y ago
    > the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence. Doesn't that apply to basically every kind of software? How's it different for HDL simulation software?
    - artemonster 5y ago
      the point is that for FOSS there was an active movement that forced IBM and old megacorps to forfeit such "nonsense" patents. So if you roll out a brand new c++ compiler you may have some buffs with intel if you try to go to their turf about some propreitary x64 specific optimizations, but, say, IBM wouldnt sue you because you dared to create "a program/method of transforming source code into machine code" that violated 250 patents from their portfolio.
      - adwn 5y ago
        I get that, but you wrote: > the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence Do you think a startup selling a new HDL simulator is any more at risk of getting sued than any other software-based startup? Not trying to be combative, I'm genuinely curious.
        artemonster 5y ago
        Yes. Happened twice? already
        adwn 5y ago
        Really? Wow! Do you happen to remember their names?
        artemonster 5y ago
        one remember - "magma automation". they were sued to pieces and then bought out
- Ericson2314 5y ago
  https://clash-lang.org/ https://clash-lang.org/ http://www.clifford.at/yosys/ http://www.clifford.at/yosys/ I am hoping we can start proving many if the things they brute-force model check today, too.
Heliosmaster 5y ago
Or working with a 40M Loc codebase started in the 80s with 50% code duplication. Because it's so mission critical that nobody really touches existing code. Or that everything needs to be rubber-stamped by a ton of people and even a rename takes months to make it in the codebase. Oh well. That's probably every enterprise
- tralarpa 5y ago
  As somebody without any experience in that field: When you say "codebase", what is that? Is it code describing circuit blocks (e.g. an ALU) that is reused in different projects or is it code for the tools that you use? (in-house tools, plugins for commercial tools, etc.)
  - Heliosmaster 5y ago
    There are several machines required to make a chip, and many steps involved. Those machines are crazy complex and accurate (i remember having a precision of around 3 atoms of silicon, femtometer scale). I meant firmware fot these machines, in general. Crazy complex (and amazing) tools with complex software
- ineedasername 5y ago
  That's probably every enterprise Yep, pretty much any industry or individual organization that's been around for 40 years will have decades-old cruft complicating attempts to make changes. That's why it's good to have some sort of skunkworks unit as well.
dataflow 5y ago
Any thoughts on Chisel?
- artemonster 5y ago
  as much as it pains to say me, but IMO its a wasted effort. we don't need new design languages. VHDL/Verilog "pain points" as RTL are tiny and don't require solving, we pretty much figured out design. Verification, on the other hand, is still an evolving (now stagnating) mess that needs inputs. The biggest offender on that project list is FIRRTL. Cleary outgrew as someone's university work of "hey, lets do IR, but for RTL" without knowing anything of the industry, tools, etc. At best you can do the same with one reduced canonical simplified verilog source-to-source translation. at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.
  - GregarianChild 5y ago
    Chisel's being hooked into the Java / Scala tool chain give makes setting up automated verification pipelines much easier: - You can use SBT or MVM to pull in dependencies - You can wrap up designs as .jar files - Powerful testing tools like QuickCheck come ready made None of the above is rocket science, but simply by being there things become easier. without knowing anything of the industry, tools, It's pretty difficult for a student to find out about what is actually used in industry. The semi industry's secrecy doesn't help. But software and hardware people really don't even have a shared language, and misunderstand each other's abilities and pain points. The very term "verification" is understood quite differently between the different communities.
  - ekiwi 5y ago
    > At best you can do the same with one reduced canonical simplified verilog source-to-source translation. Parsing Verilog and generating valid Verilog is fairly difficult. If you want to stay with Verilog, the most realistic alternative to firrtl right now is the RTL-IL representation used inside of yosys. > at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax. Canonicalized LoFirrtl (i.e., the representation the compiler lowers Chisel to) is essentially SSA (single static assignment) which encodes a dataflow DAG. So on a per module level, firrtl does represent the circuit as a graph. What you might be talking about is the fact that this graph isn't global. Having a global circuit graph could make some analyses easier, but it might require essentially in-lining the whole circuit which is something a lot of designers are opposed to. Even small optimizations like removing unused pins from internal modules are often times opposed. Chris Lattner and others are currently working on an "industry" version of firrtl as part of the CIRCT hardware compiler framework: https://github.com/llvm/circt https://github.com/llvm/circt As you can see they did not decide to go with a global graph based IR and instead opted to just represent local data-flow graphs as SSA.
lordnacho 5y ago
What's the compensation / benefits / work-life balance like?
- iancmceachern 5y ago
  My experience in this industry is that it pays well, good benefits, but it ebbs and flows much like the defense industry with large boom times and slower times with large layoffs.
m1kal 5y ago
From FPGA design point of view SystemVerilog is OK. I think it gives high enough level of abstraction to create even complex systems. It can also be readable after some years if care is taken to keep the code clean. But I believe we need LISPy syntax - mainly for simplicity, also for easier parsing and static analysis. I think LISP is a natural way to describe data flow. Unfortunately none of the attempts to write functional synthesizable code that I found so far make the code simpler. BTW I'm preparing a talk on simplifying RTL code. Can I cite some of your posts in this thread?

baybal2 5y ago

Pure sarcasm, but no :) > Overall semiconducting industry seems to be way more exciting than boring computer industry The most groundbreaking things all tech must be about are cat video websites, and internet companies :D People completely forget that were Morris Chang (the previous CEO of TSMC,) not been polite, and ethical to a fault, the industry would've still be dominated by monster big semis, manufacturing every chip around, and who would've milked all big chip users like internet companies to death. I can't imagine Panasonic, Toshiba, Motorola, or AMD of old not scheming to squeezing their clients to the last cent, and strategizing to prevent clients from gaining negotiating power. TSMC's benevolent stance in comparison to that would be almost bordering on charity.

thehappypm 5y ago

I've worked on hard science problems and while it's more bleeding edge it's all very, very slow moving. You're not shipping anything in less than a year, max. And that's OK. It's just very glacial and you go VERY deep into the topic.