Closed Fatsie closed 7 years ago
Ok found first error, the following
[provider coregen]
should be
[provider]
name = coregen
With this change I still does not seem to get the right combination of fileset and this provider to in the end be able to generate the files and be used in the parent core.
Sorry for the late reply. You need to add the HDL files that are generated by coregen to a fileset in the z80rom core, as FuseSoC has no knowledge of this otherwise
Can you be more specific in how to specify them or a working .core file of a RAM done with coregen ? Either it just seems fusesoc copies the already generated files without running the coregen or it tries to run coregen but that errors out with syn/xilinx/ROM80.xco. What is actually the file_type to use for specifying the .xco file ?
ok, I looked into this a bit more and I got two answers for you. First of all, assuming it's this https://github.com/freecores/t80/ repo you're using, it's not a coregen ROM you are supposed to use. I'll send my findings in a mail, since it's a bit off-topic to this issue.
For the coregen provider in general, it works in two steps. First step is to generate the HDL code from the IP description files. The IP description files are the .xco and cgp files as you have correctly written in the [provider] section. This will only be done once, and the generated IP will be placed in your cache. Check ~/.cache/fusesoc/freecores.github.io_t80_Z80Rom_0. From now on FuseSoC will see that this directory exists and will not regenerate the IP unless you remove the directory. For the next step, FuseSoC will need to know which HDL files that were generated by coregen. I tried to launch coregen and generate a ROM IP with the "Block Memory Generator". There will be a lot of generated files, but the only file you'll likely need for ISE and ISIm is the one in the root directory which has the same name as you chose for the IP core when you generated it
I'm trying to provide the T80 as a github hosted .core. Depending on custom C++ code needing configuration of compiler + Makefiles etc. does not fit in this. That's why I am trying to generate the ROM with coregen from out of FuseSoC. In the end I think we should have even a more generic ROM generator not (directly) depending on Xilinx specific tools.
I have indeed an empty directory for the coregen core in ~/.cache, I think this should be removed if coregen fails or better check if needed files are there and redo the coregen if not. Will see what I can do and also see if I can get the coregen core working now.
Edit: after I deleted the empty directory I again get error:
File "/home/eda/.local/lib/python3.5/site-packages/fusesoc/provider/coregen.py", line 16, in fetch
self._checkout()
File "/home/eda/.local/lib/python3.5/site-packages/fusesoc/provider/coregen.py", line 32, in _checkout
shutil.copyfile(f_src, f_dst)
File "/usr/lib/python3.5/shutil.py", line 115, in copyfile
with open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: '/home/eda/.cache/fusesoc/freecores.github.io_t80_ROM80_0/syn/xilinx/coregen/ROM80.xco'
After further investigation I think this error is becuase ROM80.xco is in a subdirectory that does not exists yet. Will see how to fix it.
Agree. FuseSoC should be smarter about this and not assume the core is working if the directory exists. Cache handling needs more love in several areas
Also agree that custom c++ is really unnecessary here, and using coregen is bad too, since it limits the number of simulators we can use. I propose that we use a verilog module here that can be fed with a parameter containing the initial memory contents. This is super easy and is the way I usually do this for other systems. The reason for using verilog here is that we can use $readmemh, and VHDL doesn't have a similar standard for prepopulating memories. A simplified version of https://github.com/olofk/or1k_bootloaders/blob/master/wb_bootrom.v would work
Because even if you use coregen, you still have the problem of how to fill the contents of the ROM
Will look at pure verilog but this assumes all synthesis flow do the proper thing with $readmemh, as I also want to target ASICs I'm not sure how valid this assumption is. Another problem is that the open source synthesis flows for ASICs or simulators don't handle mixed Verilog/VHDL sources at the moment. Anyway I provided pull request #135 for the path generation of coregen anyway and this issue can be closed for the moment.
I am trying to use coregen from a core file using the coregen provider. This is the .core file:
For the t80 core I have the following depend in the [main] section:
When trying to simulate the top core with isim the files are not generated:
DebugSystem.vhd is where the Z80Rom block is used