Code Monkey home page Code Monkey logo

Comments (1)

ducky64 avatar ducky64 commented on July 17, 2024

Interesting.

To clarify the use case a bit: this is mainly meant to help with waveform viewer startup cost? As in, once you get the waveform viewer started and configure the view to your liking (including adding signals), there would be very little difference between the automated proposal and your current manual workflow?

On one hand, I think there's definitely utility in making waveforms as easy as possible (one antipattern I see with novices is the tendency to debug by trial and error rather than starting up tools that give debug data and system visibility, likely because of the high perceived cost), but on the other hand, it's potentially a lot of engineering to eliminate a somewhat small startup cost (or maybe it's not as small as I'm interpreting it to be?).

That aside, I think there's a few practical details to resolve:

  • Where should the start-waveform-viewer flag be put?
    • Since the primary use case I see for chiseltest is regressions, writing it in the test case seems a bit unclean. Practically, it could be something sprinkled in during the debug phase, then removed once things are fixed. But it still feels weird...
    • Alternatively, it might make more sense to be done automatically(-ish) on a test failure, with the expectation that this is where you want to see the waveform. The devil's in the details, though, since this would balance discoverability with not being too annoying.
    • This could also be an annotation or integrated into however we do options.
  • Should it be written inline with the test (and should the positioning of this construct within the rest of the test sequence be meaningful), or as something to be done on a completed test? (and presumably, the completed test would have needed VCD dumping turned on)
  • Is there universal (or at least widespread) agreement on what the default view should be? For example, it probably makes sense to display top-level IO by default, but I could see arguments for and against internal wires or internal module IOs.
  • How would this (or would this even) support multiple tests that have the .viewWaveform()?
  • There would probably need to be some abstraction layer to support other viewers in the future.

from chiseltest.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.