Bug 321 - BUG: Running ltp on a pipeline gives warnings about loops
Summary: BUG: Running ltp on a pipeline gives warnings about loops
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Windows
: --- normal
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 383
  Show dependency treegraph
 
Reported: 2020-05-18 16:21 BST by Michael Nolan
Modified: 2020-06-30 19:54 BST (History)
1 user (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments
Photo of loop in yosys graph (19.78 KB, image/png)
2020-05-18 16:21 BST, Michael Nolan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Nolan 2020-05-18 16:21:33 BST
Created attachment 55 [details]
Photo of loop in yosys graph

Running `ltp` in yosys on a pipeline gives many warnings about loops being detected. For instance, running yosys -p `read_ilang logical_pipeline.il; synth; ltp` in soc/fu/logical/test gives the following output:

yosys> ltp

3. Executing LTP pass (find longest path).

Longest topological path in input (length=4):
    0: \op__input_carry [1]
    1: $abc$6362$new_n198_ (via $abc$6362$auto$blifparse.cc:377:parse_blif$6427)
    2: $abc$6362$new_n199_ (via $abc$6362$auto$blifparse.cc:377:parse_blif$6428)
    3: $abc$6362$new_n201_ (via $abc$6362$auto$blifparse.cc:377:parse_blif$6430)
    4: \carry_in$25 (via $abc$6362$auto$blifparse.cc:377:parse_blif$6432)

Longest topological path in output (length=9):
    0: \stage_o [63]
<snip>
    9: \cr0$24 [3] (via $abc$8116$auto$blifparse.cc:377:parse_blif$8261)

Longest topological path in main (length=34):
    0: \op__insn_type [5]
   <snip>
   34: \stage_o [5] (via $abc$6433$auto$blifparse.cc:377:parse_blif$7943)

Longest topological path in countz (length=27):
    0: \rs_i [47]
<snip>
   27: \result_o [0] (via $abc$6123$auto$blifparse.cc:377:parse_blif$6352)

Warning: Detected loop at \stage_o$next [63] in pipe
Warning: Detected loop at \stage_o$next [62] in pipe
Warning: Detected loop at \stage_o$next [61] in pipe
Warning: Detected loop at \stage_o$next [60] in pipe
<snip>
Warning: Detected loop at \stage_o$next [0] in pipe
Warning: Detected loop at \so$23$next in pipe
Warning: Detected loop at \r_busy$next in pipe
Warning: Detected loop at \op__insn$20$next [31] in pipe
Warning: Detected loop at \op__insn$20$next [30] in pipe
Warning: Detected loop at \op__insn$20$next [29] in pipe
Warning: Detected loop at \op__insn$20$next [28] in pipe
...


Graphing the module (show pipe) shows a couple of loops in the top level pipe object, outside of the stages
Comment 1 Luke Kenneth Casson Leighton 2020-05-18 16:57:37 BST
(In reply to Michael Nolan from comment #0)
> Created attachment 55 [details]
> Photo of loop in yosys graph

> Warning: Detected loop at \stage_o$next [63] in pipe

ok yes this is fine.

look closely at the MUXes.  note that when the front mux is set, the register is outputted (from the DFF, which is on a clock latch).

however if the MUX is not set, the input is sent through combinatorially.

so the "loop" is not a combinatoriak looo, it is a time synced loop that traps the value of the input, endlessly replaying it until such time as soneone sets the MUX to low.

there is probably a better way to do this  however it is not doing any harm.