wavedb interface tracking issues

[1024bees]

Overview

Its clear that a common pitfalls of other debuggers is the difficulty grouping signals into some higher level grouping (we will call them Interfaces moving forward).

Motivation

When an engineer opens up a vcd file to debug their design (or software on their design). They often already have insight on what parts of the design they want to look at, and how certain signals interact. If an engineer is unfamiliar with a part of a design that looks as if it may be exhibiting incorrect behaviour, then engineers can often feel hopelessly lost when navigating through the hierarchy of signals and modules.

Design

Interfaces hope to address these two use cases by doing the following:

• Allow end users to add structure to digital designs such that signals can be quickly populated in the debugger in a finegrained manner
• Allow end users to add semantic meaning to groups of signals such that other designers can quickly extract "meaningful" state from foreign blocks (IP blocks that are unfamiliar to the engineer).
• Allow end users to define interfaces once and instances of that interface should be automatically found

Implementation

Ideas within Interfaces (this may overlap with implementation):

1. Channel: A channel may be a single SignalItem or an Interface object. An interface may be composed of one or more Channels.
   • Each channel may be optionally tagged with a comment.
   • Two Channels may be 'siblings' if they are parented underneath the same Interface
   • Relationships between interfaces should be described by creating a parented interface.
2. Top Scope: The highest level of visibility an interface has within a design.
   • e.g. if we want to have have a read interface to a flip fop, the top scope would be the name of the flip flop module we're using

Implementation

Ideas within Interfaces (this may overlap with implementation):

1. Channel: A channel may be a single SignalItem or an Interface object. An interface may be composed of one or more Channels.
   • Each channel may be optionally tagged with a comment.
   • Two Channels may be 'siblings' if they are parented underneath the same Interface
   • Relationships between interfaces should be described by creating a parented interface.
2. Top Scope: The highest level of visibility an interface has within a design.
   • e.g. if we want to have have a read interface to a flip fop, the top scope would be the name of the flip flop module we're using sable and

Implementation

Ideas within Interfaces (this may overlap with implementation):

1. Channel: A channel may be a single SignalItem or an Interface object. An interface may be composed of one or more Channels.
   • Each channel may be optionally tagged with a comment.
   • Two Channels may be 'siblings' if they are parented underneath the same Interface
   • Relationships between interfaces should be described by creating a parented interface.
2. Top Scope: The highest level of visibility an interface has within a design.
   • e.g. if we want to have have a read interface to a flip fop, the top scope would be the name of the flip flop module we're using
3. Specification: Description of one or more interfaces.
   • Namespaced: should be all relative to top scope
   • Composable -- should be able to include specs from other specs
   • Incremental -- should be able to define interfaces on the fly (from any wavedb client) and save them
   • Human readable -- low friction to create interfaces and verify if an interface definition is correct