Hacker Newsnew | past | comments | ask | show | jobs | submit | sdvsfqe's commentslogin

> How fortunate we all are!

I think so.

As someone who makes things, they solve a really important chicken-and-egg problem for me.

i.e. Where does the money needed to make a thing come from before you make it so that you can sell it and make money from selling the thing?

I suppose technically I could risk my money, assuming I have some. But I'd much rather risk the bank's, and I understand that they will charge me for that.


Also, soft cpus without strict performance and power requirements are really easy to implement with modern toolchains. In one quarter you can take an undergraduate who doesn't even know digital design and have them make a cpu core as a final project, and they can make a decent one.

HW is actually really hard. If you can use a soft core to simplify the overall design and suck up a bunch of peripheral logic it's probably a good idea. Then the engineers can spend their time focusing on getting the hard parts of the design correct.


> how slow/resource intensive it is

compared to what?

It's not like all the other EDA tools are really fast or not resource intensive. For smaller design firms I would think things like FireSim [1] would be a significant advantage.

I can imagine it is a disadvantage in other ways, i.e. it's only possible to do single phase positive edge synchronous design, which could be an impediment to high performance digital design.

But I wouldn't imagine that scala performance is particularly significant.

[1] https://fires.im


It's pointless to argue with people on hn because you'll tell them "I have cold hard experience" and they'll respond with hype links and conjecture.

> But I wouldn't imagine that scala performance is particularly significant.

Imagine all you'd like - reality is much less imaginative though.


Just curious, do they have a migration plan? Have they started new designs using Verilog/SystemVerilog/VHDL?


In hardware everything boils down to volume and NRE.

If the design is low volume then minimizing NRE, which is mostly set by engineering hours, makes sense. At low volume, the semiconductor unit cost is mostly irrelevant so you can potentially use things like SpinalHDL to keep engineering hours down, and therefore potentially save NRE, and eat the higher unit cost which occur due to toolchain inefficiencies.

At high volume NRE is mostly irrelevant and unit cost is everything. So even if a tool or language is hard and annoying to use, if it gives a lower unit cost, you use it. Here you see things like an engineers hand tuning the layout of a single MUX to eek out a bit more of something good in the PPA space.

I only have experience with high volume HW and there something like Chisel or SpinalHDL wouldn't be considered as it just adds complexity to the flow, and makes it hard to do the optimizations that high volume enable us to consider, for a potential benefit we're not interested in.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: