Gedae Advanced Course Debugging Data Flow

1
Gedae Advanced CourseDebugging Data Flow

• William I. Lundgren
• [phone]
• gedae_at_gedae.com

2
Overview

• Introduction
• Data Flow Problem Example 1
• Data Flow Problem Example 2
• Data Flow Problem Example 3
• Description of Laboratory
• Laboratory time
• Solution

3
Problem

• There are three types of data flow problems that
  can occur.
• Static data flow problems can be identified by
  Gedae and the problem reported.
• Some dynamic data flow problems can be discovered
  by Gedae during scheduling. Particularly the
  dynamic insertion or removal of tokens from an
  otherwise static schedule.
• Some dynamic data flow problems are errors in the
  graph that only show up at runtime. In these
  cases the data flow is potentially correct but
  either one of the boxes is incorrect or
  non-matching dynamic boxes are being used.

4
Approach

• GEDAE provides tools for analyzing for these
  types of problems.
• For static data flow errors Gedae will report the
  errors and then the flattened graph can be used
  to identify the problem.
• For dynamic data flow errors that are reported by
  Gedae before the scheduling is complete the
  flattened graph is the best tool.
• Once the graph has started to run but stalled
  then the tool to use is the trace table.

5
Static Data Flow Error 1

• This first example illustrates the way that a
  data flow error is identified in the flattened
  graph. The simple flow graph shown below has a
  interpolate on one branch that adds extra tokens.

6
Static Data Flow Error 2

• The flattened graph for this simple example is
  shown below. Notice that the

The orange line highlights the data flow error.
You can set the color in the gedae_resources file.
7
Mode Graph Data Flow Errors 1

• The graph for the mode control example is shown
  below. This is the actual state when debugging
  was started.

8
Mode Graph Data Flow Errors 2

• When we tried to run the graph we got the
  following message. We will look at the flattened
  graph to identify the problem.

There is a problem with the box
Controller.PlanLoading1.i_hold. It has 2 dynamic
inputs. For some reason they are internal to a
static schedule. By displaying schedules on the
flattened graph we should see the problem.
9
Mode Graph Data Flow Errors 3

• The flattened graph is shown below. Parts of it
  have been collapsed because they do not change
  the data flow.

The i_hold box is circled. The line above it that
bypasses the box and all the blue boxes to be in
the same schedule. The question is whether we
need to put a dynamic queue in the upper line or
is the data routing incorrect.
10
Mode Graph Data Flow Errors 4

• A couple of examples of the data flow parameters
  are shown below. Further investigation shows that
  all the data flow parameter on the intervening
  boxes are one.

The i_hold box takes in a mode and a count. It
holds that until it has output count tokens of
the mode. So the number of modes on the
upper/lower arcs will be in a ratio of 1/count.
So it is flagged as a problem by Gedae but is
also a real problem. The downstream mode should
be taken from the i_hold box.
11
Mode Graph Data Flow Errors 5

• So we change the downstream mode to use the
  repeated mode stream. The graph before the change
  is shown below.

12
Mode Graph Data Flow Errors 6

• The graph after the change is shown below. We
  have eliminated that error message but get a new
  one.

13
Mode Graph Data Flow Errors 7

• The new error message is shown below.

There is a problem with the box
Controller.PlanLoading1.0GetToFrom.i_replaceI_1
box. It has static data flow so it is not this
box but probably the one feeding it. We will look
at the box GetToFrom.
14
Mode Graph Data Flow Errors 8

• The box mentioned in the error message is fed by
  the box i_advance. The i_advance box is a bit
  unusual. It removes the first N tokens from the
  stream that is, it advances the stream N
  tokens.

Notice the queue on the output. This is the
source of the problem.
15
Mode Graph Data Flow Errors 9

• The flattened graph shows that all the boxes in
  GetToFrom. The highlighted connections show why
  all the boxes are in the same static schedule.

There is a queue here.
These 2 inputs are not statically connected so
the only thing connecting the blue and green is
the yellow. We will put a queue after the i_delay.
16
Mode Graph Data Flow Errors 10

• The flattened graph shows that now the i_advance
  and i_replace boxes are in different static
  schedules.

There are queues here.
17
Mode Graph Data Flow Errors 11

• When we try to run the graph now we get the error
  message and shell messages shown below. These are
  a little confusing because there are 2 outputs
  from the demux connected to 2 inputs on the
  i_hold box and no other boxes involved. We will
  look at the boxes involved.

18
Mode Graph Data Flow Errors 12

• The flattened graph with the 2 boxes is shown
  below. It doesnt make sense that this should be
  a problem. Actually we have discovered a bug in
  the Gedae scheduler. We will look at the
  primitives.

The error message in the shell is complaining
about these connections.
19
Mode Graph Data Flow Errors 13

• The interface declarations from the 2 primitives
  are shown below. The only thing that sticks out
  is that a cyclic box output is connected to a
  non-det input. For lack of a better course we
  will put static copy boxes between these 2 boxes.

The outputs of a cyclic box connected to a
non-deterministic inputs.
20
Mode Graph Data Flow Errors 14

• The ModeInput flow graph with copy boxes is show
  below. When we run the graph it says that it is
  running but we still dont see any output from
  the graph. So we will again look at the flattened
  graph this time with viewing the ready state and
  queues enabled.

The copy boxes separate the cyclic box from the
non-deterministic inputs.
21
Mode Graph Data Flow Errors 15

• We see that there are queues that are filled but
  there is no token on the output of the i_advance
  box.

This queue has the necessary tokens but the queue
between the boxes i_advance and i_replaceI_1
doesnt have any tokens. This is family 0. Family
2 has a token. ??
22
Mode Graph Data Flow Errors 16

• We select Mode.Controller.PlanLoading1.i_mergef_c_
  2 and the OptionsgtDisplay Schedule menu item to
  get the schedule and find they are all in the
  same schedule.

23
Mode Graph Data Flow Errors 17

• Things are a little confusing. So it is necessary
  to look again at the problem. It doesnt seem
  that this should be so confusing. Conceptually
  what we are doing is quite straightforward. The
  flow graph we have been working is shown below.

24
Mode Graph Data Flow Errors 18

• The first thing that we do is put echo boxes on
  the inst, from and to boxes. After a little
  rearranging we see the results shown below. The
  input is mode 0, count 7. The results show
  the to being set to 8 on the 6th count not the
  7th.

inst 0 from 8 to 0 inst 0 from 0 to 0 inst
0 from 0 to 0 inst 0 from 0 to 0 inst 0
from 0 to 0 inst 0 from 0 to 8 inst 0 from
0 to 0 inst 0 from 4
25
Mode Graph Data Flow Errors 19

• So we look at what the graph should be doing a
  little more closely. An example of the input and
  expected output is shown in the table below.

26
Mode Graph Data Flow Errors 20

• One problem is that there are m GetToFrom
  instances and each removes a token with the
  i_advance box. So we will just rethink this box.

This box has 3 family members in our example.
27
Mode Graph Data Flow Errors 21

• The new Controller graph is shown below.

This box makes the signals to control the state
transfers.
This box makes the signals to control which
instance gets each data set.
28
Mode Graph Data Flow Errors 22

• The new PlanLoading graph is shown below.

The instance stream is now a single stream.
Removing the lead token advances the stream.
We use a vector of times to track processor load.
29
Mode Graph Data Flow Errors 23

• A new MakeToFrom graph is shown below.

The GetToFrom graph is still a family so that the
Nisnts can be different for each mode.
The advance and delay are done on the merged
stream.
30
Mode Graph Data Flow Errors 24

• The graph now works. Would do need to verify the
  functionality but will do that in the Mode Graph
  lecture.

31
Laboratory Assignment

• Objective Work through the problems with the
  attached graph.
• Gain problem
• Granularity problem
• The student should learn to
• Identify and resolve a gain problem
• Identify and resolve a granularity problem
• Be careful not to change the functionality of the
  graph.
• If you have any question about the functionality
  please ask.

32
The Flow Graph 1

• The flow graph below runs but doesnt produce any
  data.
• The Modes flow graph is shown on the next page.

33
The Flow Graph 2

• The Modes flow graph is shown below. Notice that
  there is a branch and merge pair.

34
Solutions Follow
35
Solution 1

• The trace table is shown below. Notice that a few
  of the upfront boxes fire and then nothing more
  happens. The x_merge box is blocked.

36
Solution 2

• The flattened graph is shown below. The box Mode1
  has been collapsed to make the graph easier to
  read.

Select ready and queues from the view menu to see
if we can find the problem.
37
Solution 3

• The x_merge box is blocked.

The first box in Mode0 is starved for data.
The merge box is blocked for some reason.
38
Solution 4

• Turn on view schedules from the view menu of the
  flattened graph.

The schedule that is not producing data.
39
Solution 5

• The right mouse information screen is shown for
  the schedule input (starved) and output. The
  schedule takes in 207 tokens and outputs 206
  tokens.

40
Solution 5

• From the top level flow graph we can use the view
  menu to view the group status. The information
  for the x_merge box and the schedule that is not
  firing is shown to the right.

The schedule takes in 206 tokens from the branch
and outputs 206 to the merge.
41
Solution 6

• The schedule with the merge has an input queue to
  the x_merge that needs 1 token but doesnt have
  any.

The child schedule that is not firing has 1 token
but needs 207.
42
Solution 7

• There are two problems.
• The input takes 207 tokens but the output only
  produces 206 tokens.
• The branch and merge boxes are working with only
  one token at a time. The branch and merge must
  deal with data at the same granularity as the
  child graph they control.
• We will increase the granularity of the branch
  and merge by increasing the granularity of the
  control. We will use an interpolate box to do
  that.
• We will investigate the problem of the 207 vs 206
  tokens by looking at the graph.

43
Solution 8

• The new graph with an interpolate box that
  repeats the control token.

The interpolate box increases the granularity of
the branch and merge to N-(Len-1) 207.
44
Solution 9

• Next we look at the new flattened graph with
  schedule and queue viewing turned on.

The input queue to the schedule is satisfied but
the x_merge is still starved for data.
45
Solution 10

• Again we look at the output of the child
  schedule, the input to the x_merge box and the
  group status.

The x_merge box is failing because it needs 207
tokens but only has 206. This is exactly what we
expected based on the observation that the child
schedule was consuming 207 tokens but only
producing 206.
46
Solution 11

• We look at the information dialog for the output
  of the child schedule and the input to the
  x_merge box.

The information is the same. The x_merge box is
failing because it needs 207 tokens but only has
206.
47
Solution 12

• The flow graph for the schedule is shown below.
  It shows us the problem. We fix the problem by
  setting U to N-R-1

The vector size of the output of this box is
U-L1 N-Len-1-01 N-Len 206. The vector is
later turned into a stream giving an
interpolation of 206.
The decimation of this box is N Ovrl
N-(Len-1) 207.
48
Solution 13

• The fixed flow graph is shown below. The scope
  shows us that the graph runs. We make the same
  change in Mode1.