How to use coregen provider ? about fusesoc HOT 8 CLOSED

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.

from fusesoc.

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

from fusesoc.

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 ?

from fusesoc.

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

from fusesoc.

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.

from fusesoc.

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

from fusesoc.

Because even if you use coregen, you still have the problem of how to fill the contents of the ROM

from fusesoc.

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.

from fusesoc.