Closed Inkletblot closed 3 years ago
I'd recommend using the development branch. We need to clean up the branches and collapse things together a bit.
Paul
All good, I did try development as well and it's also broken there.
Also this brings up another potential issue as I was following the docs which recommended stable_base which probably indicates that an update is due.
Yes, make a pull request to indicate that development is the best branch.
I can get the simulate target running on that branch with make simulate
It is using the mcode variant of GHDL, but that shouldn't be a significant
difference.
Paul.
On Mon, 10 May 2021 at 12:16, Inkletblot @.***> wrote:
All good, I did try development as well and it's also broken there.
Also this brings up another potential issue as I was following the docs which recommended stable_base which probably indicates that an update is due.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/mega65-core/issues/383#issuecomment-836091072, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOTZGRNQ6Q7RFM7JMJRTTM5CH7ANCNFSM44P2Z3NA .
If you cd ghdl and then compile it, it will work. The Makefile in mega65-core could have a rule created for ghdl/ghdl_mcode that does that automatically.
Paul.
On Thu, 20 May 2021 at 00:50, Luke Waymark @.***> wrote:
If I try to do make simulate (in dev branch) it won't make at all, instead complaining that there is no target for ghdl/ghdl_mcode. Doesn't work for simulate-llvm or simulate-gcc either. Setting it to use local ghdl doesn't work as expected, should an external one be used in this case?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/mega65-core/issues/383#issuecomment-844208133, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOTYXEXMTFXOYIB7DRRTTOPJMLANCNFSM44P2Z3NA .
Ok, saw the update to 'build.md' come in and the suggestion to try 'development' branch, feel like this ticket is sorted, so will close.
I'd like to point out here that my experience with the project is limited and this could just be chalked up to that however, it seems to me that the simulate target, at least on the stable_base branch, is totally broken.
To begin with there are illegal characters in one of the comments in
matrix_to_ascii.vhdl
. These are umlauts at420:22
,435:22
,440:27
, which are easy enough to remove. (I'm not confident that this isn't a locale issue, I'm building this on ubuntu 20.04).It also seems that the unisim library must be imported as well, however I could not find any documentation about this anywhere in the project (at least anywhere I looked). Also, this is easy enough to do. In my case
ghdl -i --work=unisim /opt/Xilinx/Vivado/2018.3/data/vhdl/src/unisims/*.vhd
All of the work so far is not totally breaking or unreasonable however...
The file
cpu_test.vdhl
atsrc/vhdl/
is totally broken. There are a multitude of signals seem to be causing errors that I was not able to work out. Note this is pure guess work now as I'm no vhdl savant, it seems to me that at some pointmachine.vhdl
andslow_devices.vhdl
were updated andcpu_test.vhdl
has not been.I say this due to the port maps under
core0: entity work.machine
andslow_devices0: entity work.slow_devices
being the location of the mismatches and errors such as the first to appear:stemming from from the definition of
qspidb
being the following incpu_test.vhdl
:and the following in
slow_devices.vhdl
:i.e.: mismatching types.
I'm really not sure what to do with this as my experience is limited and I'm not entirely confident in my diagnosis . However, I spent quite some time trying to work out exactly what issues were actually occurring in the file but unfortunately my understanding of the codebase and vhdl limit me here.