Verilog coding format used by ZipCPU.

[imc_user1]

Hello fellow makers, 

I am trying to get some grasp of CPU RTL and toolchain design and ZipCPU showed up in my search result and looks very promising. However the verilog coding style really confuses me. 

I use ncsim 2015 for my office work and used Verilog for at least ten years. Now I tried to simulate the ZipCPU core RTL but it had too many syntax errors. The most obvious one being variables being used before it's declared, e.g. r_wb_cyc_gbl. 

Here comes my question, is the bugs I saw as a result of I use ncsim or difference between ncsim and verilator? 

Anybody run simulation with Vivado simulator? 

 

Another question, where is the best website, material or lectures to study how to customize GCC for my custom instruction set? 

Thank you! 

[xc6lx45]

Hi,

I'd have a look at LLVM, you may find it's cleaner and more modern than gcc (I guess people might disagree, I don't have much of an opinion here since I haven't looked too deeply into either).
For a worked-out example with gcc, the ZPU implementation is something you could study but as a CPU it's very slow.

[zygot]

@imc_user1,

Your question about the ZipCPU source and simulating it works as a pretty good cautionary tale. Open source is only truly open if users can both (effectively) use and understand the source with the tools that one is familiar or if one is willing to learn how to use the tools that the source is dependent on. Either way, I suspect that in the case of a veteran Verilog user and the this particular project,  at least some design choices, strategies, and concepts can be gleaned. The essential problem with using some one else's design and source is that a lot of work generally has to be done to decide if what you have been provided will make a suitable base for making your own customizable version for some application given the effort involved.  The calculus isn't usually an easy one to make and experience spanning many years helps one quickly pursue or abandon such "starter" projects with minimal effort. Nothing is free. Personally, as far as the HDL goes,  it's an easy decision for me if I can't simulate the source using the tools provided by the FPGA vendor. Being able to simulate source certainly makes the process of understanding the source easier and quicker ( assuming that you have developed an expertise in simulation.. another subject worth discussion ).

The problem for someone like @D@n who wants to provide a alternate softcore platform that will be adopted widely is this: does he use an arcane toolset that he is familiar and comfortable with to develop his project or does he use a more standard toolchain that his potential "customers" are familiar with. From past conversations and experience I know that Dan isn't a believer in the idea that simulation is a necessary part of the design process. The ZipCPU has many admirable goals. Perhaps the best one is allowing use of the GCC toolchain for software development. I personally have no need or interest in the overhead involved in a softcore processor for FPGA development except in very rare cases. For those rare times when it makes sense I'd use a something like an open source HDL softcore that is compatible with a vendor's ( such as Atmel ) software toolchain. But I'd only do this if I had to use a particular FPGA device without an embedded hard core and the software was minimal. For projects requiring an FPGA and and substantial and ongoing software capability it's hard to pass on a ZYNQ. I don't see having a hard ARM CPU as a convenience because there just isn't a lot of things that I can't do with less hassle using an HDL without a software toolchain tied to the FPGA development. I'd rather do my software on a PC.

I really don't buy the idea that hardware ( FPGA ) development requires a CPU, or that it is easier with one for 90% of potential applications.

[D@n]

@imc_user1,

Looks like i missed this post yesterday, sorry about that.

Yes, as @zygot points out, I am the author and maintainer of both the ZipCPU and the ZipCPU blog.  You can also find me on twitter and several freenode IRC channels.

The hardware style you describe of using something before declaring it is something I would consider to be a bug and not a feature.  Apparently it isn't something my tools are picking up.  If you see this in my code, please create a github issue and I'd be glad to work with you to help get it fixed.

As for simulators, I have only ever used Verilator for simulation.  I haven't tried simulating the ZipCPU with Vivado's simulator.  I like to have a simulation I can interact with--one where the serial port acts like a serial port (i.e. I telnet into my simulations), SD cards read from a valid SD card image, VGA or other video outputs display within a window on my screen, and where I can load and debug the CPU just like I would on the actual hardware.  I find I can do this easily using Verilator.  There's another interface that can be used for this purpose as well, (I think it's called VPI?), I've just never tried it and so have no background in it.  In other words, if you want to simulate the ZipCPU using a Verilog based test bench, you will have some work to get it up and running.

The most recent changes to the ZipCPU source right are in the formal branch.  I haven't merged them into dev (yet), although I'm working on doing so.  Basically, I've been working on formally verifying the entire CPU.  In the process, I've come across an amazing number of bugs that I had previously missed in simulation.  Once I verify that these bug fixes work in simulation, I'll move them into the dev branch.  Once I verify that they work on my hardware, I'll move them into the master branch.  Or, at least, that's my plan.  We'll see what happens.

Finally, if you want to build a GCC back end for your instruction set, there is a wonderful GCC internals document describing what it takes to do that.  You can find that here.  You will find the particular chapters on the RTL representation, machine description, and target description macros and functions the most useful.  (I'm not sure if I read any more than those.)  When I first started, I was given a patchset for getting GCC running on the ECO32.  It was so valuable to me, teaching me how to set up my port and more, that I currently maintain the ZipCPU's GCC backend as a patch on top of the GCC 6.2 release.

As for @zygot's comments on whether or not there is ever a need for a CPU within an FPGA, let me invite you to join that discussion here.  A short summary would be that CPU's within FPGA's are not universally a good idea, but there are some significant and specific times and places where they make sense.

Dan

[imc_user1]

Thank you for your replies zygot and D@n. 

From that I believe it's not the tool or the Verilog version which caused the bugs. It's interesting to see this core and alternative ways of doing things. 

For a very beginner with no background in computer science, a simulatable CPU core is very important for study purpose. Reading through the C16 on opencores.org over the weekend gave me some pointer in the direction of Bison and Lex and I managed to see some good lectures online. 

Again, thank you both! 

 

[D@n]

@imc_user1,

You found the C16 on open cores?  Nice!  Did you check out the os_book.pdf in that repository?  I loved it--it's worth a read.

Dan

[imc_user1]

On 5/28/2018 at 6:25 PM, D@n said:

@imc_user1,

You found the C16 on open cores?  Nice!  Did you check out the os_book.pdf in that repository?  I loved it--it's worth a read.

Dan

Yes that's an interesting book! 

My knowledge in OS was from reading a small RTOS source codes instead, but it covered all the concepts of an RTOS. A book like than help me examine anything missing from what I already know and reinforces my understanding.