Hacker News Reader

Comment by pjmlp | Hacker News Reader

> IMHO, the barrier isn't so much the tools, but a clashing of paradigms.

I guess another issue is that most EE guys are happily using GUI tools and don't have any ideological problem with commercial tooling, as what matters is the final result.

View on HN

I think you can treat 60 - 70% of the FPGA design flow as open source. For example, I am developing a system using PCIe, 10G Base T and some logic to send and receive network packets and to design the HDL and test it, I am using two open source tools predominately (icarus verilog and cocotb). I just use the FPGA P&R tools for building the design once I am satisfied it works. You can also run these tools on the command line quite easily and automate most of the process (They all use tcl for scripting up the flow). Sure theres a few FPGa specific interfaces you have to deal with (transceivers, DDR4, pcie hard ip) but you can pretty much traet these as black boxes and write your tests to target the interfaces in and out of the logic. Also, for things like transceivers, the interface is really not that different between Xilinx and Altera (I treat them as a black box that generates 32-bits every 322MHz cycle for 10G-Base T). The flow to my mind is not that disimilar to a traditional software development flow. I have simulation tests and test cases, I use continous integration to run tests everytime something is commited, everytime I build the FPGA with the P&R tools, I kick off hardware tests automatically, etc

Agreed on the closing note, but I'm not certain that's the case. I mean a good tool is a good tool, regardless of foundational discipline.

It comes down to choice...or rather lack thereof. EDA tools are very expensive and tend to have a steep learning curve. Professional divisions tend to standardize to keep costs in check. Here's an example of one that's "affordable"[1].

[1] http://www.digikey.com/products/en/development-boards-kits-p...

Reply on news.ycombinator.com