MEGA65 / mega65-core

MEGA65 FPGA core
Other
245 stars 88 forks source link

Simulate target on stable_base totally broken? #383

Closed Inkletblot closed 3 years ago

Inkletblot commented 3 years ago

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 at 420: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 at src/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 point machine.vhdl and slow_devices.vhdl were updated and cpu_test.vhdl has not been.

I say this due to the port maps under core0: entity work.machine and slow_devices0: entity work.slow_devices being the location of the mismatches and errors such as the first to appear:

src/vhdl/cpu_test.vhdl:193:17:error: can't associate 'qspidb' with port "qspidb"
src/vhdl/cpu_test.vhdl:193:17:error: (type of 'qspidb' is a subtype of std_logic_vector)
src/vhdl/slow_devices.vhdl:62:5:error: (type of port "qspidb" is a subtype of unsigned)

stemming from from the definition of qspidb being the following in cpu_test.vhdl:

signal qspidb : std_logic_vector(3 downto 0) := (others => '0');

and the following in slow_devices.vhdl:

QspiDB : inout unsigned(3 downto 0) := (others => 'H');

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.

gardners commented 3 years ago

I'd recommend using the development branch. We need to clean up the branches and collapse things together a bit.

Paul

Inkletblot commented 3 years ago

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.

gardners commented 3 years ago

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 .

gardners commented 3 years ago

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 .

gurcei commented 3 years ago

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.