phanrahan
Cooperation
Hello,
I am afraid that we are doing the exactly the same thing.
https://github.com/Nic30/hwt
https://github.com/Nic30/hwtLib/blob/master/hwtLib/samples/showcase0.py
This library is also SystemC/Chisel + UVM equivalent in python. I have 4+ years for developing (phd). The library is currently used only by FIT VUTBR and Cesnet. In order to have any chance of survival, both of our projects needs to get much bigger userbase and community.
Do you have any chat or email?
Hi, I'm available at [email protected] if you'd like to email. For chat, lennyt on keybase is one option, let me know if there's a different chat service you'd prefer. I'm okay with discussing here as well.
I haven't had a chance to review all the code you have, but I agree that it'd be in both our interests to find a way to collaborate. One idea would be to implement a backend for our language that targets yours. Then our users would have access to all your tools/libraries, and your users would be able to write code in our language or at least use any existing code in our language. We probably need to work out some details on how to approach this. Once I get a chance to review your code in more detail I think I'll have a better idea on possible collaboration paths moving forward.
@Nic30 thanks for contacting us. We would love to cooperate. I agree, all of us doing these types of projects need a way to get more users! I am out of town. Please talk to Lenny in the mean time.
Hello maybe something went wrong and lenny did not received my message. Or maybe there is something that you do not like. If it is a case, please tell me too.
Hello Leonard, I am Nic30 from github (https://github.com/phanrahan/magma/issues/281#issuecomment-419994528).
I think that magma is very similar to core (RTL layer) of the hwt framework. https://github.com/Nic30/hwtLib/blob/master/hwtLib/samples/rtlLvl/simpleWhile.py Both of them are netlist generators wit some functions to export the netlist to other format like verilog or VHDL. Where export part (backend, serializers) are separated from netlist generator. (My knowledge of magma is limited to few hours.)
hwt.synthesizer.rtlLevel compared to magma:
- Direction of interfaces are resolved automatically from access.
- Hierarchy is resolved automatically from connections.
- Wire/reg signal type is resolved automatically from usage as it is in VHDL.
- Minor differences in syntax.
- Hwt users does not use rtlLevel directly because it is too low level for them.
hwt.serializer compared to magma.backend:
- blif, coreir, firrtl (but easy to implement)
- dot replaced by ELK (dot can't do layered graphs suitable for HW)
- docstrings propagated to generated code
- vhdl, systemC
- IPcore packager (respecting the interfaces, clocks, address maps etc.)
- resource analyzer prototype
hwt.simulator vs magma.simulator:
- support for ABC, coreir
- UVM environment with agents for many interfaces (AXI3/4/Lite/stream, I2C, Avalon, ....)
Hwt is not just a python description to HDL for example last member of ecosystem is a plugin for sphinx doc generator which creates schemes like this https://hwtlib.readthedocs.io/en/latest/_static/schematic_viewer/schematic_viewer.html?schematic=../../_static/hwt_schematics/hwtLib.logic.crc.Crc.json
I do not know the possibilities of blif, coreir, firrt. I worked with ABC only in classes. Maybe I have a time to write some compatibility layer between our projects. But the decision was not made I need o know the goal of your project.
Hwt was originally the backend for HLS synthesis experiments. Later then it was adopted for writing system level writing and gluing thinks together. It is also god for systemc-like hardware description. Hwt greatly reduces the pain from developing the HW with complex interfaces like PCI/AXI. Python retrospectivity and component model from hwtLib allows to write hardware which will work with any interface (for example you write ring-style interconect and it does not matter if you use AXI or Avalon interface), which greatly improves the productivity.
Problems of HWT:
Hwt is well documented but it has not a public wiki (and wiki on github is trash...)
Hwt has over 1000 tests but it still not enough in order to become bug-free.
HLS is becoming mainstream and we are behind.
Hwt users are working on network, high-reliability applications and RISC-V. (no video processing or acceleration in cloud which are hot topics).
Also we have only Xilinx-7/Ultrrascale+, Arria10, Statrix10 users (no low level FPGA users).
I may be a good programmer but I am definitely bad in explaining to users.
I am usually pessimistic about everything, but I react well on constructive critics. If something seem you to be wrong do not hesitate to write me. I am ready to improve it.
Best regards, Michal Orsak@Nic30.
Sorry, I have yet to respond to your mail yet because I have yet to had a chance to review your code.
Thank you for an information. You do not need to hurry. I also have plenty of work at the moment.
In the meantime there are another similar projects
- pymtl - 2014+, Hardware metalanguage integrated in Python
- veriloggen - 2015+, Python, Verilog centric Hardware metalanguage with HLS like features
- migen - 2013+, Python, Hardware metalanguage integrated in Python
Their developers are active, pymtl veriloggen author works alone (academic) and there is small company behind migen and pymtl. They would like to cooperate, but it is not clear how to synchronize the projects.
@shtaxxx @sbourdeauducq @jsn1993 @timsherwood
Maybe we should really work together or at least make our frameworks compatible in future. I am not there to judge but. From my point of view majority of FPGA users never heard about pymtl, veriloggen, migen, magma, PyRTL, hwt or any other HDL metalanguage. And for many applications they are must-have and for rest they are big advantage.