[Libre-soc-bugs] [Bug 510] New: check for combinatorial path through DIV FSM

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=510

            Bug ID: 510
           Summary: check for combinatorial path through DIV FSM
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl at lkcl.net
          Reporter: lkcl at lkcl.net
                CC: libre-soc-bugs at lists.libre-soc.org
   NLnet milestone: ---

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/div/fsm.py;h=befb463d0ef1f23fcbde6933e0c0e9070cf08b3f;hb=a1f8daaf0e4e2fcea1edf8b9037a2082cc1a59a2#l170

jacob when running nextpnr5 the highest reported path latency is through the
DIV FSM because the CompUnit Manager input snd output latches, controlled by
go/req from the regfiles are combinatorial *and* nextpnr5 is finding and
reporting a combinatorial through the FSM itself.

can you please take a look and see where that is, you can use "ltp" in yosys on
the compunit or pileline ilang file (after synth or synth_ecp5)

i suspect it is this:

      m.d.comb += self.n.valid_o.eq(~self.empty & self.div_state_next.o.done)

although it us likely to be more.  i think the root of the issue is that no
output should be copied excepy synchtonously or through a synchronous register.

i.e. referring to saved_state is ok because that is copied synxhronously and
thus creates a firebreak.

however referring to data.o directly and combinatorially is not.

this is a high priority issue as it will be picked up later during ASIC timing
analysis which is a month closer to the deeadline, which would be really bad to
try to "fix" with only days left before GDSII files are due.

-- 
You are receiving this mail because:
You are on the CC list for the bug.