5 ms·

Totally agreed. This is the problem of academia unfortunately, the people working on these have no experience in designing complex chips and facing the real lim

by bgnn 1y ago

Totally agreed. This is the problem of academia unfortunately, the people working on these have no experience in designing complex chips and facing the real limitations. We are so stupidly limited by our EDA tooling and infrastructure. I wish these efforts would have been put to use in that front.

thijson 1y ago
It would be nice to have a simulator like Verilator for VHDL.
- kvemkon 1y ago
  There is mature GHDL https://github.com/ghdl/ghdl https://github.com/ghdl/ghdl and rather new NVC https://github.com/nickg/nvc https://github.com/nickg/nvc.
  - thijson 1y ago
    I was aware of GHDL. NVC looks like it's potentially more performant.
    - rluoy 1y ago
      LLVM never works in EDA.
almostgotcaught 1y ago
> We are so stupidly limited by our EDA tooling and infrastructure. The problem that no one will ever solve is there's no gcc equivalent to NXT. Everything is downstream of that problem.
- artemonster 1y ago
  are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it *works*. we are far from reaching limits of what is capable to design and tape with current flows. frontend money aspect for tools is still peanuts in comparison to backend and actual fabrication, so it will not generate a renaissance era like gcc did for software
  - bgnn 1y ago
    Backend and fab costs are dominant (or even packaging costs are on par with silicon costs these days), correct, but verification is an multiplier on overall costs. The cost of a re-spin is huge. To your point though, most issues warranting a resping are backend related.
  - almostgotcaught 1y ago
    > are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it works go back in time to before gcc - i'm 100% sure people were saying the exact same thing about borland (or whatever).
    - KerrAvon 1y ago
      I don't recall anyone being "objectively-sucks" level of unhappy with proprietary C compilers. Moving to gcc was often a regression -- because it was much slower to run and sometimes generated worse code -- for developers used to Turbo C or CodeWarrior-style IDEs.
      - GianFabien 1y ago
        AFAIK when it comes to using the features of recent CPU architectures, Intel's compilers produce more performant / efficient code than GCC or Clang. A sufficiently smart compiler requires ever more clever compiler writers who are deeply knowledgeable about the many quirks of the numerous architectures.
        almostgotcaught 1y ago
        > Intel's compilers produce more performant / efficient code than GCC or Clang Intel's compiler are clang forks.

by bgnn 1y ago

thijson 1y ago

It would be nice to have a simulator like Verilator for VHDL.

kvemkon 1y ago
There is mature GHDL https://github.com/ghdl/ghdl https://github.com/ghdl/ghdl and rather new NVC https://github.com/nickg/nvc https://github.com/nickg/nvc.
- thijson 1y ago
  I was aware of GHDL. NVC looks like it's potentially more performant.
  - rluoy 1y ago
    LLVM never works in EDA.

almostgotcaught 1y ago

> We are so stupidly limited by our EDA tooling and infrastructure. The problem that no one will ever solve is there's no gcc equivalent to NXT. Everything is downstream of that problem.

artemonster 1y ago
are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it *works*. we are far from reaching limits of what is capable to design and tape with current flows. frontend money aspect for tools is still peanuts in comparison to backend and actual fabrication, so it will not generate a renaissance era like gcc did for software
- bgnn 1y ago
  Backend and fab costs are dominant (or even packaging costs are on par with silicon costs these days), correct, but verification is an multiplier on overall costs. The cost of a re-spin is huge. To your point though, most issues warranting a resping are backend related.
- almostgotcaught 1y ago
  > are you sure it will do anything at all? I am not. The current setup, while objectively sucks for engineers is still quite capable and it works go back in time to before gcc - i'm 100% sure people were saying the exact same thing about borland (or whatever).
  - KerrAvon 1y ago
    I don't recall anyone being "objectively-sucks" level of unhappy with proprietary C compilers. Moving to gcc was often a regression -- because it was much slower to run and sometimes generated worse code -- for developers used to Turbo C or CodeWarrior-style IDEs.
    - GianFabien 1y ago
      AFAIK when it comes to using the features of recent CPU architectures, Intel's compilers produce more performant / efficient code than GCC or Clang. A sufficiently smart compiler requires ever more clever compiler writers who are deeply knowledgeable about the many quirks of the numerous architectures.
      - almostgotcaught 1y ago
        > Intel's compilers produce more performant / efficient code than GCC or Clang Intel's compiler are clang forks.