Simplify Portability and Maintenance and unify common VHDL code

[sy2002]

One of the basic ideas of QNICE-FPGA is, that it is meant to be highly portable. For sure we are not there, yet ;-)
Currently, everything is quite Xilinx specific.

• Right now, we have two hardware targets: Nexys 4 DDR and MEGA65
• I assume that there will be more hardware targets in future, because for example the Terasic DE10-Nano dev board is becoming highly popular (and I recently bought one ;-)).
• And then, the Nexys 4 DDR is deprecated, the successor is called Nexys4 A7: I never tested on it, because I do not have one, yet. We might want to suport the Nexys A7 one day without giving up the Nexys4 DDR support.
• So the vhdl/hw as well as the hw/xilinx , hw/intel folders might grow in future, making maintenance hard: Particularly due to duplicated and mainly identical files with slight platform specific changes

Is there a way to work in VHDL a bit similar than with the C preproccessor? And then add some build system like CMAKE or the GNU build system?

E.g. in the source files as high level as #ifdef xilinx and/or as low level as #ifdef enable_hdmi and then something like

make nexys4
make MEGA65
make DE10

And the build environment is smart enough to grasp: OK, Nexys and MEGA65 are Xilinx, DE10 is intel...

Can we unite the zoo of vhdl files that right now have been doubled just because I did not know better how to do it? Like uniting MEGA65 globals and env1 globals. Uniting MEGA65_ISE.vhd with MEGA65_Vivado.vhd with env1 ISE and Vivado and so on.

Having some vhdl/hw/common folder where all the common stuff resides and then the TRULY hardware specific stuff, such as HDMI and HyperRAM for MEGA65 then in a vhdl/MEGA65 folder.

[sy2002]

@MJoergen I am currently knee-deep in making MEGA65 work again with all the changes we made in V1.6 :-) (so I am working on issue #69 right now). While doing so, I made the mmio_mux more powerful, so that we do not need multiple versions of it while we support multiple hardware targets. I used boolean switches in a generic section:

generic (
   GD_TIL            : boolean := true;   -- support TIL leds (e.g. as available on the Nexys 4 DDR)
   GD_SWITCHES       : boolean := true;   -- support SWITCHES (e.g. as available on the Nexys 4 DDR)
   GD_HRAM           : boolean := false   -- support HyperRAM (e.g. as available on the MEGA65)
);

Could you please have a look at the changes in develop and do The Smoke Test on Nexys 4 DDR because my recent commit to develop might have broken things (even though I do not think it did) while I continue on MEGA65?

[MJoergen]

I'll have time tomorrow to check the generics in mmio_mux. By the way, I really like this, and we should probably use this even more.

Meanwhile, since this issue is about portability and refactoring, I have another issue:
I notice that whenever I've run compile_pore.sh the files pore/boot_message.asm and pore/boot_message_mega65.asm get updated. This means that I no longer can do a simple git checkout <branch> because of "local changes not committed". I then manually have to revert these two files before switching to a new branch.

I propose that we remove the two mentioned files from the repository, since they get automatically generated every time compile_pore.sh is run.

[sy2002]

By the way, I really like this, and we should probably use this even more.

Yes, for example to avoid having to make specific versions of mmio_mux for simulations. But I guess such a (bigger) change might have time until V1.7, because we then also need to update the simulation code.

I propose that we remove the two mentioned files from the repository, since they get automatically generated every time compile_pore.sh is run.

Very good point. I just did that. My next commit to develop will update this.

[bernd-ulmann]

Removing the aforementioned files from the git is a good idea, and I can relate to the problem of Michael with the files in dist_kit which force me once in a while to checkout these files before I can even perform a git pull. Shouldn't we remove those files from the git as well? :-)

[sy2002]

Removing the aforementioned files from the git is a good idea, and I can relate to the problem of Michael with the files in dist_kit which force me once in a while to checkout these files before I can even perform a git pull. Shouldn't we remove those files from the git as well? :-)

I would oppose removing the files from dist_kit because the whole point of dist_kit is to be our distribution kit, which is completely redundant (also when it comes to the bitstreams there), yet very valuable for doing our QuickStart Guide on the main README.md

[bernd-ulmann]

...but the dist_kit is created easily and automatically by running compile_and_distribute etc. Couldn't we, when we have a stable release such as the forthcoming 1.6 create a dist_kit and include it as ZIP-file in the git? This way users who can't create their own dist_kit could unpack the ZIP-file while all others would just follow the build instructions, what do you think?

[sy2002]

You are right: Everybody needs to "go through" the make-toolchain process, because otherwise he would not even have an assembler. So yes, I'll take care of this.

[sy2002]

Is there a way to work in VHDL a bit similar than with the C preproccessor?

The answer is: Usage of generic variable in unified VHDL files

And then add some build system like CMAKE or the GNU build system?

This is something we might want to move to the future; right now the IDE based approach is fully OK, so this is out of scope for the issue at hand.

[MJoergen]

I've ordered a Terasic DE10-Nano for myself (will get it in a few weeks). Then we can work on porting to that platform too!

[sy2002]

Super cool! 🚀 😃

[MJoergen]

One thing we might want to consider as part of this issue is to rename the CPU bus signals as follows:

Old name	New name
WAIT_FOR_DATA	waitrequest
ADDR	address
DATA_IN	readdata
DATA_OUT	writedata
DATA_DIR	read
DATA_VALID	write

The reason for this renaming is that the new signal names (and their semantics, i.e. the bus protocol) then conforms to the "Avalon Memory-Mapped" interface specification. Since Avalon-MM is an industry standard this might make the interface easier to understand/recognize/reuse as well as make it easier to integrate new components later on.

The Avalon-MM interface is described in detail in Chapter 3 of this link https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_avalon_spec.pdf.

Note, when it comes to the DATA_DIR and DATA_VALID signals it might be necessary to modify some of the logic in the various I/O devices and/or the CPU, since the semantics of these signals is not completely identical to the read/write signals in the Avalon-MM standard. Figure 7 in the above mentioned document shows the details. However, I consider this a minor change.

So the question is, whether this is something we want to bother with? I think it is more of a nice-to-have, but on the other hand I don't really see any down sides to it.

[sy2002]

@MJoergen Absolutely relevant and valid topic. Are we already sure, that Avalon-MM is the way to go? I am no specialist in these industry standards, but I observed that in the Open Source world (e.g. on opencores.org), also WishBone seems to be a common standard? So yes, we should do something here. But let us please move it to V1.8 as V1.7 is having a lot of loose ends currently (also on the MEGA65 side) and given my restricted time budget, I would appreciate V1.8 for that 😃 I will open a new issue and assign it to both of us.

[sy2002]

What is left here to do

• Sift through all VHDL files and extract constants that are of relevance also for issue Support the concept of SYSINFO #101

• Make PORE auto-generated for all platforms (needs Support the concept of SYSINFO #101 as a prerequisite)

• Totally minimize the amount of specific files for platforms and simulations

• Make the simulations for Nexys use a unified MMIO and other unified files using generic flags

• env1_globals.vhd: We should rename this and have only one globals file for all officially supported platforms (right now: Nexys, MEGA65) were we use a generic variable to tell the globals file which platform is active. This helps to reduce the "zoo" of files

• Unification of the PORE boot message files

• Look at the MEGA65 specific files - also the simulations - and check, if clever generic solutions such as the ones described here are possible: Simplify Portability and Maintenance and unify common VHDL code #41 (comment)

• MEGA65: Unite the ISE and Vivado top-files using ideas like ISE is not able to place and route MEGA65 any more #92 (comment) but also take care that currently there are more differences than only the clocks

• MEGA65: When uniting the ISE and top-files, take ISE is not able to place and route MEGA65 any more #92 (comment) into consideration