Cider 2.0 Tracker Issue

[EclecticGriffin]

We're finally at point where we can start running programs through Cider 2 and thus it now makes sense to have a tracker for the ongoing efforts to reach parity with Cider 1.

Known issues:

• [Cider 2] Handle memory input/output #1968
• [Cider 2] Connect to fud2 and the existing test suites #2044
• Missing a bunch of primitives
  • Comb primitives are partially done ([Cider 2.0] Remaining comb prims and the seq mem implementation #1967)
  • Seq Mems ([Cider 2.0] Remaining comb prims and the seq mem implementation #1967)
  • Mult / Smult ([Cider 2] Invoke fixes, mult imp, and error messages #2128)
  • Div / Sdiv ([Cider 2] More tests #2158)
  • Sqrt ([Cider 2] More tests #2158)
  • Bit slice ([Cider 2] Arbitrary precision and signed serialization #2218)
  • Fixed Point ([Cider2] Add missing Fixed Prims #2235)
• [Cider 2] Warn when there is a memory for initialization that isn't used #2159
• Group termination takes an extra cycle due to only running convergence once. Issue: [Cider 2.0] Groups taking an extra cycle to exit #1917
• Continuous assignments ([Cider2] Continuous assigns + with #2064)
• par not supported ([Cider 2] Barebones Par #2043)
  • cross branch conflicts warnings missing Skipping in favor of more direct thinking about par stuff
• with not supported ([Cider2] Continuous assigns + with #2064)
• invoke not supported ([Cider 2] First Pass Multi-component and Invokes #2119)
• repeat not supported ([Cider 2] More tests #2158)
• multi-component programs not supported ([Cider 2] First Pass Multi-component and Invokes #2119)
• [Cider 2] Data converter cannot handle signed values #2161
• [Cider 2] Data converter cannot handle fixed-point values #2219
• (Debugger) Add watchpoint enable/disable ([Cider2] Watchpoint fixes #2250)

[rachitnigam]

For some of these issues, like with not being supported, we should resolve the long-running with discussion and decide if we want to get rid of it completely or not.

[EclecticGriffin]

@rachitnigam Agreed, this is mostly just me getting down the current state of things. Also with is annoying to implement so I've thus far avoided it oops

[sampsyo]

Wahoo; thank you for summarizing! Just capturing the synchronous discussion a little bit, on this point:

Does not generate an output JSON compatible with our testing infrastructure

I had suggested, in the spirit of trying to do the simplest possible thing here, that it might not be too hard to load/dump "raw bits," i.e., the exact bit-level contents of the memories. This is more or less what the RTL simulators already do (they are using hex-encoded text, but same difference). We could then pre-/post-process these files into our JSON format externally, alleviating the need for any serde hacking on Cider's side.

This of course omits all the non-memory results that Cider 1.0 can already produce. But I believe this is fine: all we really need to check correctness is those memory dumps.

[EclecticGriffin]

Officially closing this tracker since at this point Cider 2 has replaced Cider 1 and has passed parity in terms of programs