3 ms·

From what I can tell, the goal here is to create an abstraction for interfacing with the different tools from different EDA vendors. All these tools have their

by doix 6y ago

From what I can tell, the goal here is to create an abstraction for interfacing with the different tools from different EDA vendors. All these tools have their own arcane CLI arg names for essentially the same stuff, this is trying to abstract that and create a python way of describing all of that. Where I work, we just use a bunch of Makefiles. We mostly just stick to a single vendor though.

maweki 6y ago
> the goal here is to create an abstraction for interfacing with the different tools from different EDA vendors I gathered as much. Again, the EDA-space is large. PyEDA was interfacing to severals SAT-Solvers, BDD-Libraries (even rolling their own if you didn't want dependencies), and logic minimizers. This abstraction Layer here seems to mainly wrap EDA-tooling around HDL and therefore (I guess, since I am not a hardware guy) hardware verification tools. I would guess that those are basically the two ends of the EDA-spectrum, going from the very abstract of some First Order Boolean Formula Satisfiability problem to Actual Hardware Verification.
kingosticks 6y ago
> We mostly just stick to a single vendor though. This. The tools are expensive so we license one simulation tool and we build our world around it. At least where I work, there's no situation where we pay for multiple tools that do the same thing, it would be considered a waste of money to license multiple and I think I agree with that. The same goes for the synthesis and backend tools. Driving these tools is difficult to get right so we stick with just one. There would have be a really, really really compelling reason to switch and it's yet to manifest. Sure, the tools have bugs but we report them and they do get fixed. It would have to be something quite special to make a switch interesting, even more special than synthesiable VHDL 2008!

by doix 6y ago

maweki 6y ago

> the goal here is to create an abstraction for interfacing with the different tools from different EDA vendors I gathered as much. Again, the EDA-space is large. PyEDA was interfacing to severals SAT-Solvers, BDD-Libraries (even rolling their own if you didn't want dependencies), and logic minimizers. This abstraction Layer here seems to mainly wrap EDA-tooling around HDL and therefore (I guess, since I am not a hardware guy) hardware verification tools. I would guess that those are basically the two ends of the EDA-spectrum, going from the very abstract of some First Order Boolean Formula Satisfiability problem to Actual Hardware Verification.

kingosticks 6y ago

> We mostly just stick to a single vendor though. This. The tools are expensive so we license one simulation tool and we build our world around it. At least where I work, there's no situation where we pay for multiple tools that do the same thing, it would be considered a waste of money to license multiple and I think I agree with that. The same goes for the synthesis and backend tools. Driving these tools is difficult to get right so we stick with just one. There would have be a really, really really compelling reason to switch and it's yet to manifest. Sure, the tools have bugs but we report them and they do get fixed. It would have to be something quite special to make a switch interesting, even more special than synthesiable VHDL 2008!