11–20 of 24 posts
Earlier quoted context omitted.
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.
> 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.
Earlier quoted context omitted.
> 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.
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
Earlier quoted context omitted.
> 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.
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
go back in time to before gcc - i'm 100% sure people were saying the exact same thing about borland (or whatever).
as a HW designer that writes RTL for living I will repeat this 150 times and will put this on my gravestone: WE DONT NEED ANOTHER SHMANCY HDL. really. existing ones are moooooorrreeee than fine. our tools suck, verification sucks. your design complexity is entirely limited by your verification capabilities (and automation infra). having fancy constructs for CDC or pipelining in HDL is utterly useless, especially that…
Earlier quoted context omitted.
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
> 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).
as a HW designer that writes RTL for living I will repeat this 150 times and will put this on my gravestone: WE DONT NEED ANOTHER SHMANCY HDL. really. existing ones are moooooorrreeee than fine. our tools suck, verification sucks. your design complexity is entirely limited by your verification capabilities (and automation infra). having fancy constructs for CDC or pipelining in HDL is utterly useless, especially that…
As a hardware engineer turned software developer (including in EDA) who has dabbled in trying to create higher-level HDLs over the years, I now tend to agree with you. As it turns out you can already do a lot of things with parametarization of modules (which has been possible in Verilog and VHDL for years (decades) now). I think a lot of SW folks who look at the problem tend to come up with something that seems bette…
Earlier quoted context omitted.
> 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).
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.
A sufficiently smart compiler requires ever more clever compiler writers who are deeply knowledgeable about the many quirks of the numerous architectures.
as a HW designer that writes RTL for living I will repeat this 150 times and will put this on my gravestone: WE DONT NEED ANOTHER SHMANCY HDL. really. existing ones are moooooorrreeee than fine. our tools suck, verification sucks. your design complexity is entirely limited by your verification capabilities (and automation infra). having fancy constructs for CDC or pipelining in HDL is utterly useless, especially that…
But even when using plain verilog the language was never the limiting factor on the design process.