I am a retired ASIC designer. I also have some experience writing EDA tools. A friend of my has an idea for a new processor architecture and I wanted to help him write a software model so he could start making some specific hardware decisions and also provide more detail to investors, patent attorneys, etc.
I saw a few presentations on MyHDL and Cocotb, and I was thinking of using one of them to implement the concurrency we would need for the modeling. We are not even thinking about synthesis at this stage, but just want to build a model as quickly as possible. In the beforetime, when I was designing graphics chips, my team and I would write C models to do this type of thing. We would roll our own concurrency features, etc. It looks like there are now many tools to help with these types of things, and it appears to me that MyHDL and Cocotb might be the most promising open source solutions at present. I have used SystemC and SystemVerilog in the past, and am thinking the Python ecosystem might be a good reason to prefer MyHDL and/or Cocotb. Any thoughts or suggestions would be very much appreciated as we are hungry to get started and would love to benefit from all of your perspectives before we move too far in any one specific direction.
I hope this is an OK question for this forum. I know I would be chastised for this type of question on some of the StackExchange forums . Also, any suggestions on how to solicit feedback on this topic would be greatly appreciated.
IMHO MyHDL is among the best choices when it comes to designing processors (I’ve done the dance with unorthodox stack machines, RISC-V and others).
When it comes to managing complex pipelines though, you might be tempted to design framework which will work fine for modelling, but eventually not translate to HDL, which can be cumbersome to re-design, then again you’ll gain back a lot of time with the superior test benching ecosystem of Python.
MyHDL is already quite good at co-simulation through VPI, if you’re fine with the ‘upstream’ iverilog simulator support. When choosing VHDL, you might run into issues with arithmetics during translation (#322).
Thank you so much for your reply and encouraging words. The MyHDL approach looks very promising to me, and I am really looking forward to starting to use it in earnest. Please let me know if you know where to find some well-written examples I can use to get started. For example, generic DRAM and/or SRAM models would be very helpful to help me get started. Any other processor-related components could also be instructive, and useful as starting points.
For simple modelling of a single port RAM, you can simply use one of the approaches from the MyHDL docs (https://docs.myhdl.org), there should be some material under the ‘Conversion Examples’
Those pointers sound great. I will take a look right away. Ideally, I would find existing BFMs for various types of complex SRAMs and DRAMs, as well as models for other “off-the-shelf” models (eg, PCIe, USB, MIPI, etc.) to get started, and if I need to roll my own, I will happily post them as public domain somewhere so that others can leverage them if/when they are complete. Maybe others will chime-in and comment on how I could better write them after I post them.
FYI, I worked at an EDA supplier for a while and had a vision to create a very powerful mechanism to facilitate a visual Lego-like drag and drop interface for our library of cores. By doing so, I hoped to create an eco-system that would become the standard for system design including all aspects of hw/sw co-design.
Long term, I think it would be pretty fun to try to implement something like that on top of MyHDL. Part of the vision was to add a feature to SystemVerilog whereby one could seamlessly (and inline) transition between C++ and Verilog, much like one can do between C and Assembly. I got as far as working with the standards committee to add a simple keyword recognized by Verilog followed by {}, and then just start writing in C and having default but overridable casting between the two languages for like-named variables. Anyway, I digress, but I’m hoping MyHDL is an even better way to accomplish what I was trying to do with the inline-C feature. I think a lot of this stuff dies on the vine because it is not intuitive. In my experience, many hw engineers never even leverage the DPI because it is too foreign. I could imagine how the intuitive, minimalistic, and Verilog-like simplicity of MyHDL might bridge the gap between hw and sw designers and create an eco-system that will be a game changer.
I very much appreciate your help and am also very interested in any other pointers suggestions you may have.
For simulation, Python indeed allows to go ‘seamless’ compared to the classical V* Co-Simulation constructs, so you can mix software-routines with logic descriptions or generate HDL test benches up to some extent. Foreign interfaces might come into play when co-simulating against V* output or external ‘known good’ models for verification.
Where MyHDL - as a Python dialect and library - excels, is mainly the arithmetics ‘done right’ and with rapid-prototyping a functional model. So it will just do fine for developing and testing your core logic (when focusing just on a new CPU architecture, for example). But it is not so much different from VHDL and Verilog as you probably gathered, it won’t do the crazy meta programming dance you might know from the C++ transpiling side. That’s again something where you’d get more ‘show’ from the migen world, but with the digital logic designer background, I wouldn’t recommend their syntactic approach.
If you’d rather want to move towards high level, such as pluggable components for system-on-chip projects, you’ll run into the same limitations as with the V* HDLs, other frameworks will come into play and there’s hardly a way to establish a standard in terms of interchangeable descriptions, apart from IP-XACT (which is of questionable efficiency). I assume you’ve already come across kactus2 and all those XSL translation sheets.
Implementing these sort of HLS tools on top of MyHDL, apart from performance issues, had lead me to hardly long-term maintainable source code generators, they’re now being buried for good.
After all, I guess developers tend to end up with proprietary variants of SoC-Builders plus tool patchwork, trying to avoid complex second hand construction sites. I’m the kind of conservative/lazy user who likes to have a chip built like a Linux kernel (make config && make). I’d share your vision, on my side it just has boiled down a lot.
. Also, any suggestions on how to solicit feedback on this topic would be greatly appreciated.