Custom I/O

[tcdev]

I'm attempting to "future-proof" the designs once again, and in the process every single project in the repository will have to be updated.

The problem I'm trying to solve is that several projects have "custom" i/o requirements which break the PACE architecture as inevitably they require access to pins (eg. GPIO) at the top level. And of course the use of these pins is project-specific and in some cases not compatible with other projects on the same target.

In the past this has required custom "target_top.vhd" modules and in some cases custom "pace.vhd" modules for each project. This has become a nightmare to maintain and also requires duplicated effort when the architecture does change. :eek:

So. I've added some signals that get passed up/down to/from target_top.vhd and platform.vhd. These signals are records that are defined in target_pkg.vhd, platform_pkg.vhd and project_pkg.vhd. Not sure if the former will ever be used, but it's there just in case.

In addition, each target_top.vhd (will) instantiate a custom_io.vhd module. This module connects all "non-standard" I/O pins on the target to the target, platform and project records. A good example is the DE1 platform whose custom_io module connects the GPIO header pins.

There is a "stub" custom_io.vhd module in each target directory. This needs to be included in every project that does not use any custom I/O.

For those projects that do use custom I/O, a project-specific version of the custom_io.vhd file would be included. This module would then hook up the I/O in a project-specific fashion, using the platform/project-specific record members of the custom I/O signals defined in the project.

NOTE: I'm currently in the process of implementing all this and have yet to fully implement some custom I/O using this mechanism, so there may well need to be some "tweaks" to the architecture along the way.

The upshot of all this is - there should rarely be a need for any custom target_top.vhd module. Any project with custom I/O requirements just includes its own custom_io.vhd module. Hopefully cleaner, easier to follow, and less work to maintain. :cool:

[tcdev]

The so-called "custom_io" modifications appear to be taking real shape.

I'm using PLATFORM_IO in the C64 project to access a few different resources on different targets - for example the GPIO on the DE1/DE2 platforms.

After a few hiccups in implementation I'm pretty happy with what is there now. The GPIO can be shared between "custom" requirements of a given platform, and the "default" use for each target, such as Maple or Gamecube controllers or DE2 LCD screens. Basically, any pins used for custom i/o have priority over the "default" use.

This should mean that porting between targets is easier, quicker and cleaner now. :cool:

[FrenziedEngi]

As I am familiarizing myself with PACE, I am trying to understand/differenciate the purposes of each of these three custom_io types. I think I understand the target and platform--
- In the target_pkg you can define a record to use GPIO on your top level in a generic way. This makes porting to new targets (i.e. dev boards) easier.
- In the platform_pkg you can define a record to get GPIO piped in and out of the platform.
- What I am not sure of is the "project". I think I am fuzzy on the purpose/meaning of "project" in general.

Platform - Hardware platform to emulate (i.e. pacman)
Target - Board on which platform(s) are emulated
Device - FPGA family used by target(s)
Project - (???) This is the place where you can put stuff that is unique to the platform/target combination. But where does this connect the IO to/from -- top and platform are already covered. Is this here in case there is another level of (unexpected) abstraction needed?

[tcdev]

- What I am not sure of is the "project". I think I am fuzzy on the purpose/meaning of "project" in general.

Platform - Hardware platform to emulate (i.e. pacman)
Target - Board on which platform(s) are emulated
Device - FPGA family used by target(s)
Project - (???) This is the place where you can put stuff that is unique to the platform/target combination. But where does this connect the IO to/from -- top and platform are already covered. Is this here in case there is another level of (unexpected) abstraction needed?
A project is a unique target/platform/platform-variant combination, yes. FYI an example of a target is DE1, an example of a platform is midway8080, and an example of a platform variation is Space Invaders. An example of a project is the DE1 build of Space Invaders.

The custom I/O was added recently and is still in the "experimental" phase.

Right now, the only custom I/O that is being actively used is platform_io, which is used to connect "custom" signals from the platform core module to different I/O on different targets. A prime example is disk i/o. This need came about because I was trying to feed disk signals from the C64 and TRS-80 cores, for example, up to the top level on different targets, with completely different interfaces.

To give an actual example, I have one platform whereby the C64 disk is emulated off-board and data is fed to a FIFO within the FPGA via an LPC bus, with an LPC slave core in the top-level. On the DE2 however, the serial data from a real 1541 drive is connected to the DE2's GPIO connector. In this case, the custom_io record has a super-set of the required signals, and each project has its own custom_io.vhd module for interfacing to the real world.

So, currently, the record that describes the custom data is defined in the platform_pkg. The custom_io module - that interfaces the custom i/o signals to the target top-layer and/or pins, is generally included in the project directory. This is because projects for two different targets may use the same custom i/o signals, but interface differently to the target board. Not strictly symmetric I know...

The other 2 types, target_io and project_io, were added at the same time as "place-holders" for future development - because it's quite laborious to add more signals en-masse to the PACE project. The hope is that the combination of these three records precludes the need to ever add any other signals to PACE again! (hah!)

To be honest, I've had difficulty working out how the target_io and project_io records would actually work in practice. You couldn't use either in a platform.vhd file, for example, unless every project defined the same record elements. But you could use them in an entity instantiated within the platform.vhd file. Similarly for target_io. I'm sure some day someone will find a use.