I'm not sure I followed all of that, but let me at least try to look up the links and see what I can learn. Maybe they'll help me follow the concepts you are suggesting.
If you want to use it in your closed source project, give me a holler. I'm sure we could work something out. Even if we don't, I'd love to have the opportunity to hear from you, meet you, say hello, and encourage you in any way I can.
Realistically, those who've wanted to use the ZipCPU tend to just chat with me about it and we work out a handshake agreement or some such.
Were someone to want to use it in a commercial product, I'd be more interested in some form of compensation. For now it's filling the education role quite nicely -- which is somewhat of a surprise for me since I never saw that coming when I started working on it in the first place.
Basically, I was shocked when I applied SymbiYosys to the ZipCPU at how many bugs I found. Bug lists like this are typically company secrets, since no one wants to reveal how many bugs their product has. In my case, part of my success has been my openness.
Next week's project will be programming the software for a PicoRV inside the bus structure created by AutoFPGA, so I am very aware of the RISC-V architectures ... now.
I would very much like to build a RISC-V 64-bit variant (there are already many 32-bit variants), but so far the task isn't funded. Well, neither was the ZipCPU when I built it, but now such an upgrade would need to compete with other paying projects I'm working on whereas I didn't have an income when I started working on the ZipCPU.
Think of it this way, what do you need an FPGA for? Now, when budgets are tight, how do you pack more bang for your buck? Rather than placing more and more state machines on an FPGA, you can offload such task loads onto a CPU. Indeed, the more (slow, not time-sensitive, complex, etc) tasks you can off load onto the CPU, the more fabric is available for ... whatever task you actually wanted to place onto the FPGA.
I have yet to place more than two ZipCPU's on a board, mostly because I'm still working out the various bus details associated with making multiple CPUs the master of the same bus. For example, should they all have the same perspective of the address map? This I'm still working out.
The ZipCPU and several peripherals can fit within an iCE40 8k using only about 5k LUTs--and that's with the multiply unit, the divide unit, the pipelined fetch unit, and a debugging bus infrastructure. While that isn't the full pipelined implementation neither do the caches fit, it is sufficient to be competitive with the picoRV.
The specification actually mentions RISC-V, and why I didn't use it. In hind sight, it's harder to decode the RISC-V instruction set than the one for the ZipCPU--to many holes in strange places.
Yes, the GPLv3 license is applied to both the core generator and the generated code.
Copyleft is quite appropriate for simulations: they are all software, and the user is not likely to "convey" that software to another. Even if he chose to do so, Verilator is open source so this is both possible and quite appropriate. Hence the copyleft is appropriate.
Copyleft also works nicely for students, for whom the design is not "conveyed" outside of the university or the sponsor paying for the work.
The copyleft also allows you to convey it to another in source code form. Here again, there is no problem.
Beyond that, let me say that if the terms are not sufficient for you, or if you would rather it be released under a different license, I would be happy to engage in a negotiation off-line with any business who would want it released to them or others under a different license.
Dan