This would be great to have. I can check with one of my students to see if he's interested. He's already working on some improvements for netlistsvg (busses & hierarchical designs)

• https://github.com/djwubs/netlistsvg

GitHub

djwubs/netlistsvg

draws an SVG schematic from a JSON netlist. Contribute to djwubs/netlistsvg development by creating an account on GitHub.

netlistsvg is the great step into right direction. We need more of such projects.

@nturley (the author of netlistsvg) has signed up to be a Google Summer of Code mentor for SymbiFlow.

We need more students now!

@drom I think I can help you with that. I'd love to work on something related to netlist visualization for GSoC. Here's some ideas I want to bounce off of you before writing a formal proposal.

-An RTL schematic view (this issue)

-A potential visual simulation in RTL view (so one can see which wires are on/off & step through clock cycles.) There's a LOT of potential for visualizing testbenches or failure traces.

-Would this be an extension of netlistsvg, icedrom, or its own project?

-Issue #42 (Render LUTs as gates) would probably be a part of this

-Algorithms, perhaps in Yosys to make a netlist more human-readable before displaying (I'm thinking of possible use in reverse-engineering cases, but how helpful would it be for development?)

-Could also work on #45 (Improve Wavedrom)

I was looking for Symbiflow GSoC ideas and came across this the other day. I've already been working on things within the same vein in my obsolete IC emulation project (I gave a talk about this at LatchUp 2019) (RIP LatchUp 2020 ;'/ ) and would love to finally contribute to SymbiFlow. Much of your existing code is in JavaScript, which I've got experience in. I also have a little experience in C-based WASM, which is a language option if we create a new project.

@TheProgrammerIncarnate great to hear from you. I was super impressed with your work and presentation at LatchUp 2019. I would be glad to be your GSoC mentor for any of the ideas you have mentioned above. I am sure @nturley would love your participation too. Have you registered for GSoC?

Python or Javascript would both be acceptable for a new project. I'm sure that @drom would prefer you write it in Javascript and I would prefer you write it in Python -- ultimately it is up to what you are more comfortable in.

Hi @TheProgrammerIncarnate !

I'm not too afraid of a rewrite of netlistsvg especially if you abandon the idea of using it for board level schematics because that made a mess of the code. It was hard to write because I didn't know what I was doing more than it being a lot of code, so with the benefit of hindsight and clear objectives it would be pretty straightforward to write. Of course you are welcome to steal pieces of it or refer to it for inspiration. Hierarchical designs practically necessitate a complete rewrite anyway. The key elements that I believe make netlistsvg successful are using a separate library to solve for layout and the concept of using an SVG skin template file. Many similar projects get bogged down fiddling with poor layout algorithms or drawing all of the symbols in code.

There are some pieces of diagram layout that it is much easier to find JS libraries for and some parts that are much easier to find python libraries for. For instance, ELKjs was very useful and I don't know of any python libraries that are as powerful as ELK for layout. Ive been doing experiments for months on trying to use constraint solver based layout and python has dozens of easy to use libraries for constraint solvers whereas the JS landscape is a bit more sparse in that area.

My python skills are a little stronger than my JS skills but I've worked with both in commercial code bases at this point so I'm fine with either one. Demoing via web browser is a little flashier than trying to teach someone how to use pip, but theres a lot of advantages to python as well.

So if you are doing netlist visualization, the TLDR is

1. Start from scratch instead of building on netlistsvg but make sure you understand enough about how it works to make yours at least as good. :)
2. The layout parameters and symbols are going to be the bike shed of the design so they should be the easiest part to tweak, modify, and replace.
3. I'm happy with Python or JS

I want to add a few points here:

Good automatic rendering of big schematic sheets is pretty hard technically and useless.

• hard -- because of the absence of adequate rendering algorithms, implementations. ELK.js is one of the best but still so so.
• useless -- cognitive load on the user is growing with the size of the schematic. Users becoming overwhelming at some point. Abandoning the whole idea of the schematic view.

In order to make a schematic view useful, it must be interactive.

The user must be able to select and filter a subset of the schematic. With multiple ways of filtering, tracing towards source/destination, to the driver, showing/hiding details, highlighting wires and gates.

The User must be able to jump between schematic, waveform, and source code views.

A good tool would provide smart filters, to present relevant pieces of the schematic. Like a critical path, test case failure, etc.

Interactive, responsive, Web-based view is a key to success. IMHO

Exactly what I was thinking. I put a design equivalent to a few hundred LUTs into netlistsvg a while back and had these exact issues. Filtering, netlist formatting (basically anti-flatten), integration of waveform viewer & source code, etc would all very useful to help mitigate apparent complexity.

On language, I'm leaning towards some form of WebAssembly (compiled to that is, I'm not writing an application in WASM bytecode.) It should run everywhere JS does, but be much faster. Speed hasn't been much of a bottleneck so far, but it could become one if someone tries to debug an entire core or IP block. There should be a few weeks before we have to decide on one though.

For the language. I would start with JavaScript.
JS is the only language that has access to the Web page DOM.
react + imutability-helper would probably be the best choice for virtual DOM.
For heavy lifting engines like parsers, constraint solvers, synthesis, simulation, we should use/develop separate library/tool. They would be written in C/C++/Rust or something else that compiles into WASM.

On pattern recognition for visualization topic: https://groups.google.com/d/msg/chisel-users/eZy2zQyvojE/FN6dc9k9AgAJ

Google Groups

Google Groups allows you to create and participate in online forums and email-based groups with a rich experience for community conversations.

Hierarchical designs seem to start getting usable with the repo I mentioned above (hierarchy branch). One of the main things that I'm seeing for improvement could be the routing of wires, these seem to take lots of detours once you get a larger design which makes tracing them quite a big problem.

This hierarchical view currently uses a JSON config file to select which modules to expand, here's an example of what it can currently generate:

@rjordans looks very good. How can we improve the routing of the wires? is it done by ELKjs?

This is done using ELKjs hierarchical drawing, for the wires I have no clue on how to get them better yet. There's a few examples in the above picture where a mux select input goes closely past the target, takes a big detour downwards, and then finally ends up at the correct point. This seems a bit silly to me but I have no clue how this works internally. The linked project is of a student that I'm supervising so I'm not completely up to date on the internals.

• https://github.com/circuitgraph/circuitgraph
• https://schemdraw.readthedocs.io/en/latest/gallery/logicgate.html

GitHub

circuitgraph/circuitgraph

Tools for working with circuits as graphs in python - circuitgraph/circuitgraph

Logic Gates — SchemDraw 0.9.1 documentation

You might be interested in the following too;

• https://hackaday.com/2021/03/30/wires-vs-words-pcb-routing-in-python/
• https://excamera.com/sphinx/article-cuflow-crossbar.html

The interesting thing is the "river routing";

Key to this project is a concept [James] calls rivers — the Dazzler board shown above contains only eight of them. Connections get to their destination by taking one or more of these rivers which can be split, joined, and merged along the way as needed in a very Pythonic manner. River navigation is performed using Turtle graphics-like commands such as left(90) and the appropriately named shimmy(d)that aligns two displaced rivers. He also makes extensive use of pin / gate swapping to make the routing smoother, and there’s a nifty shuffler feature which arbitrarily reorders signals in a crossbar manner. Routing to complex packages, like the BGA shown, is made easier by embedding signal escapes for each part’s library definition.

It feels like this could be directly suitable for schematics diagrams and even place and route too.

It feels like this could be directly suitable for schematics diagrams and even place and route too.

Agree. Schematics in 2.5D would be nice. @Nic30, any thought about multilayer algorithms vs the one used in d3-hwschematic?

@umarcor right now I think that the the multi-layer algs. are required for PCB as wires can not cross otherwise but in scheme wires can cross and having more degrees of freedom may require longer layout time.

about cuflow I am not sure how much actually is automatic and how much is done manually.
about river routing, I thing that it is beneficial for schemes on signal level, but it is possible to just replace river with some bus.
e.g. in Altium:

If you do have buses then you usually do not need river routing (now I do ignore the fact that you do not have an explicit info about buses in Verilog..).

Hi,

I came up with this thread while searching for a way to have a interactive diagram for analyzing the clock tree from RTL.
In general, the user could select a particular signal and keep tracing forward or backwards based on the RTL design instead of netlist.
Please suggest if such capability already exists in any of the tools.
Can SV -> Verible -> Kythe graph representations be used for such a representation instead of the default web UI?

Thanks in advance.

@pka88 I am using verilog -> yosys -> json and then I am viewing it in d3-hwschematic (there is also netlistsvg which can do the same thing without aggregations) I am using it often to visualize combinational loops and pipelines discovered by a simple script.
However for things like https://github.com/ultraembedded/biriscv the tool does not work out of the box (you have to limit max hierarchy level), the generated json is so big that the browser does not have enough memory. We are currently working on it.

based on the RTL design instead of netlist

You could try this in RTL and it will be doable for most of the cases but in general it is not doable and it requires conversion to netlist.

There is a library to visualize set of small, but manageable logical tree structures without large graph rendering.

This page renders random circuit: https://drom.io/firrtl/

@Nic30 : Yes, I am looking for an interactive diagram with limited scope of analysis as the design is too big for getting any useful information if analyzed as a whole. Mainly the clock tree portion which is only connectivity across hierarchies in the RTL (much similar to the netlist).
I have posted this comment in the Surelog thread from where I had reached this thread earlier.
Maybe we would continue the discussion in that post?

@drom : Is the drom.io interactive ? are there any tools to parse an RTL to generate the GraphVIZ kind of representation needed for this ?

@pka88 the demo above is just a random circuit. It can be made interactive, with left and right side path expansion.

@drom

This page renders random circuit: https://drom.io/firrtl/

Link seems to be broken

@michael-lehn

@drom

This page renders random circuit: https://drom.io/firrtl/

Link seems to be broken

Thank you for reporting. Should be fixed now.