I’m a student having extensive experience in SystemVerilog and FPGA design. I’m really excited to see a service (apart from the proprietary ones) to program FPGAs at such a high level of abstraction. I’d like to start a project to design CPU components like TLBs, branch predictors, etc. for rapid prototyping of logic behind them. I’ve read some articles about the explicit concurrency present in Go lang but would like to know from the community whether it makes sense to design a small CPU core at this abstraction level.
I’ve given some thoughts to this and would be happy to share them with the community.
I think you’d need to develop a cycle accurate model to guarantee the number of cycles each operation may take (which is critical in latency critical systems like processors). However, if you’re concerned with
only functionality and fast prototyping of your hardware ideas this is a great idea. While back I did a simplistic model of the SSEM processor in Go: https://github.com/Mahdi89/go-pro ; it’s based on SPARC v8 arch. Feel free to fork and contribute;)
Thanks a lot for your insight. I had a quick scan through your code but couldn’t find any explicit triggers or control mechanism for clock cycle operation integrity. Is it safe to assume that each concurrent goroutine is implicitly working on a clock cycle. I was thinking of developing a simple systolic array for CNN inference. Perhaps the developer community can give an insight regarding clock cycle operation integrity at such a high abstraction level.
True, there is no notion of clock cycles in that code. It’s a proof-of-concept design and cycle accurate behaviour is yet to be added. Regarding your question on whether each concurrent goroutine could run in one clock cycle, I should say that it really depends on your implementation at this point. The amount of control flow going into each of routines determines that. However we have plans to guarantee single-cycle routines in the future.
Also for implementing a CNN checkout our brain project.