[J-core] Raise ice40 issues on GitHub or via the mailing list?
D. Jeff Dionne
jeff at coresemi.io
Tue Oct 22 03:58:17 UTC 2019
On Oct 21, 2019, at 8:36 PM, Joh-Tob Schäg <johtobsch at gmail.com> wrote:
>
> Hello,
Hi Joh-Tob,
> i downloaded the most recent release of the j-core-ice40 repo on GitHub.
> It turns out that there are files that are not checked in that are
> necessary to execute ghdl.sh and ghdl_up5k.sh.
>
> ghdl.sh throws these errors:
> cpu_pure_tb.vhh:104:17:error: no declaration for "dev_ddr"
> cpu_pure_tb.vhh:104:16:error: target is not a signal name
This particular ghdl.sh script is for a larger and more generic target, based on the J2 SoC. It should probably be removed.
> and the first one multiple times for different lines
>
> ghdl_up5k.sh lacks a folder/file describing the display controller.
> error: cannot open ../disp_drv/disp_drv_pkg.vhd
>
This is actually a target we are preparing for release. The LCD controller is in a separate repo, i need to upload it. That controller is an example of how to glue new IP cores into the minimal J1 SoC... but it is therefore application specific.
The ghdl_lattice.sh target should give you a very simple, and self contained simulation, however.
> This causes more errors in things that depend on the content of this file:
> ghdl:error: compilation error
> cpu_up5k_42s.vhd:9:10:error: unit "disp_drv_pkg" not found in library "work"
> cpu_up5k_42s.vhd:31:14:error: entity 'cpu_up5k' was not analysed
> ghdl:error: compilation error
> error: cannot find entity or configuration up5k_tb
> ghdl:error: compilation error
The real problem here is that there are multiple hardware and sim targets in that repo, and its kind of a jumble. J2 is much cleaner in that regard, it builds for perhaps 10 different target board and configuration options, but the cost is a complex separation of IP cores (cpu, dma, ddr, serdes...) and target repos. It takes maybe 15 nested repos to build e.g. Turtle.
>
> Should issues about the ice40 release be raised on GitHub (to signal
> project activity) or on the mailing list?
Probably here for now. J1 is an experiment in trying to simplify the J2 repo structure and build logic. I'm not that happy with it.
> ghdl_lattice.sh seems to work but i am unsure how to replace the
> executed binary.
Do a make clean; make in testrom. You'll need the sh2-elf- toolchain with -mj2 patches.
Then, regenerate the rom init file, by running ram.sh The Lattice synthesis tool doesn't know how to read constants from a file during elaboration, so ram.sh is a nasty hack.
BTW, the next step for this experiment is eXecute In Place from SPI FLASH.
Cheers,
J.
> This is however not a priority for me since I have a dev board.
>
> Sincerely,
> Johann-Tobias Schäg
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core
More information about the J-core
mailing list