WIP: Hierarchical netlists #92
Conversation
|
Awesome! This will take me a little bit to review. Some first impressions: Rather than using another config file, just pass configuration through the skin file. Options like color can be done in CSS of the skin file if the generated SVG elements have a class names and IDs. |
|
I agree that the styling options, like colour, are better suited for the skin file. The skin file is, as far as I know, less suited for the other options, as it is more difficult to add lists (which are used to define which modules to expand). It might also get cluttered when more options are added, because it is not possible to create sections as I did in the JSON configuration file. The main reason I've chosen for a separate JSON file for the configuration options is that it is easy to use and suitable for all options that were planned. As the options can be divided in sections, I think it would be less cluttered and easier to understand. I think it would be best to have all skin and style related options in the skin file and to have a separate file for the other configuration options. Another option that can be considered is the use of command line arguments, which would be easy to explain via an |
|
This is a great feature! When it will be available in |
|
It probably will not be available in the main branch. I am not actively developing this anymore, as this feature was part of a university project, for which this version was sufficient. The main branch is only maintained, so small bugs get fixed, but no new features are in development afaik. There are multiple reasons that netlistsvg is in maintenance mode. The main reasons are the limitations from the layout engine and a messy code base. Regarding the second question, the core functionality of hierarchical netlists is fully implemented. Some issues, which are also in the main branch, still remain (e.g. #93). The main point which may require some work are the configuration options, when it is decided that they should not be in a separate configuration file. Another point which may require some work is the routing of wires, but this is mostly done by the layout engine, and thus hard to influence. |
|
Yeah... Sorry about that. I shouldve been more on top of this and netlistsvg is quite messy and does need a cleanup. I haven't spent much time on it for the past ahem years. Thank you, @djwubs for contributing this PR and good luck on your future endeavors. The code quality for the PR looks sound from what I've looked over but I haven't reviewed it too closely. I could probably get it across the finish line. Or honestly anybody else could look it over, tell me it looks good to them, resolve the conflicts and I'd believe then and get it merged. I think it's important that code is reviewed but I'm not picky about who reviews it. So if someone else assures me it's fine and resolves the merge conflicts then I'm happy. |
|
I have merged this with the current master on my fork here, fixing merge issues. I've tested it extensively and the only issue I've run into is a stack frame overflow due to there being too many nodes/edges in a drawing. Otherwise, I think this works well. I'm not sure if I should make a new PR or have someone change this PR to that branch. |
|
I have a problem with signal names (right side in the graph).
|
Hierarchical netlists
This adds support for hierarchical netlists (#64). It is now possible to show the inner schematic of the submodules. The settings for the hierarchy are controlled by a configuration file, which is explained in the next subsection. This configuration file can be passed to netlistsvg, otherwise it selects the default configuration file, which has hierarchy turned off. This is the new command line format:
A simple example of an hierarchical netlist is shown below.
JSON Source
{ "creator": "Yosys 0.9+1706 (git sha1 e069259a, clang 6.0.0-1ubuntu2 -fPIC -Os)", "modules": { "$paramod\\submod\\c=3'111\\d=3'111": { "attributes": { "gentb_skip": "00000000000000000000000000000001", "src": "hierarchy.v:17" }, "ports": { "a": { "direction": "input", "bits": [ 2, 3, 4, 5 ] }, "b": { "direction": "input", "bits": [ 6, 7, 8, 9 ] }, "y1": { "direction": "output", "bits": [ 2, 3, 4, 5, "0", "0", "0", "0" ] }, "y2": { "direction": "output", "bits": [ 6, 7, 8, 9, "0", "0", "0", "0" ] }, "y3": { "direction": "output", "bits": [ "1", "1", "1", "1", "1", "1", "1", "1" ] }, "y4": { "direction": "output", "bits": [ "1", "1", "1", "1", "1", "1", "1", "1" ] } }, "cells": { }, "netnames": { "a": { "hide_name": 0, "bits": [ 2, 3, 4, 5 ], "attributes": { "src": "hierarchy.v:20" } }, "b": { "hide_name": 0, "bits": [ 6, 7, 8, 9 ], "attributes": { "src": "hierarchy.v:20" } }, "y1": { "hide_name": 0, "bits": [ 2, 3, 4, 5, "0", "0", "0", "0" ], "attributes": { "src": "hierarchy.v:21" } }, "y2": { "hide_name": 0, "bits": [ 6, 7, 8, 9, "0", "0", "0", "0" ], "attributes": { "src": "hierarchy.v:21" } }, "y3": { "hide_name": 0, "bits": [ "1", "1", "1", "1", "1", "1", "1", "1" ], "attributes": { "src": "hierarchy.v:21" } }, "y4": { "hide_name": 0, "bits": [ "1", "1", "1", "1", "1", "1", "1", "1" ], "attributes": { "src": "hierarchy.v:21" } } } }, "top": { "attributes": { "top": "00000000000000000000000000000001", "src": "hierarchy.v:3" }, "ports": { "a": { "direction": "input", "bits": [ 2, 3, 4, 5 ] }, "b": { "direction": "input", "bits": [ 6, 7, 8, 9 ] }, "y1": { "direction": "output", "bits": [ 10, 11, 12, 13, 14, 15, 16, 17 ] }, "y2": { "direction": "output", "bits": [ 18, 19, 20, 21, 22, 23, 24, 25 ] }, "y3": { "direction": "output", "bits": [ 26, 27, 28, 29, 30, 31, 32, 33 ] }, "y4": { "direction": "output", "bits": [ 34, 35, 36, 37, 38, 39, 40, 41 ] } }, "cells": { "foo": { "hide_name": 0, "type": "$paramod\\submod\\c=3'111\\d=3'111", "parameters": { }, "attributes": { "src": "hierarchy.v:12" }, "port_directions": { "a": "input", "b": "input", "y1": "output", "y2": "output", "y3": "output", "y4": "output" }, "connections": { "a": [ 2, 3, 4, 5 ], "b": [ 6, 7, 8, 9 ], "y1": [ 10, 11, 12, 13, 14, 15, 16, 17 ], "y2": [ 18, 19, 20, 21, 22, 23, 24, 25 ], "y3": [ 26, 27, 28, 29, 30, 31, 32, 33 ], "y4": [ 34, 35, 36, 37, 38, 39, 40, 41 ] } } }, "netnames": { "a": { "hide_name": 0, "bits": [ 2, 3, 4, 5 ], "attributes": { "src": "hierarchy.v:4" } }, "b": { "hide_name": 0, "bits": [ 6, 7, 8, 9 ], "attributes": { "src": "hierarchy.v:5" } }, "y1": { "hide_name": 0, "bits": [ 10, 11, 12, 13, 14, 15, 16, 17 ], "attributes": { "src": "hierarchy.v:6" } }, "y2": { "hide_name": 0, "bits": [ 18, 19, 20, 21, 22, 23, 24, 25 ], "attributes": { "src": "hierarchy.v:6" } }, "y3": { "hide_name": 0, "bits": [ 26, 27, 28, 29, 30, 31, 32, 33 ], "attributes": { "src": "hierarchy.v:6" } }, "y4": { "hide_name": 0, "bits": [ 34, 35, 36, 37, 38, 39, 40, 41 ], "attributes": { "src": "hierarchy.v:6" } } } } } }Configuration file
{ "hierarchy": { "enable": "modules", "expandLevel": 0, "expandModules": { "types": [], "ids": ["foo"] }, "colour": ["#e9e9e9"] }, "top": { "enable": false, "module": "" } }Besides the support for hierarchical netlists, some other minor changes have been made, which are listed in the changelog.
Configuration file
The configuration contains multiple options to customize the layout. The default configuration file turns off hierarchy and uses the top defined in the input JSON file. The default configuration file can be found in the lib directory and looks like this:
{ "hierarchy": { "enable": "off", "expandLevel": 0, "expandModules": { "types": [], "ids": [] }, "colour": ["#e9e9e9"] }, "top": { "enable": false, "module": "" } }In the
"hierarchy"subsection, hierarchical schematics can be enabled and configured. The options contained in this subsection are:"enable": In this option the hierarchy can be enabled. There are four different options."off"turns of the hierarchy,"all"expands all submodules,"level"expands all submodules until a specified level of hierarchy and"modules"expands all specified submodules."expandLevel": The maximum level until which submodules are expanded for the"level"option."expandModules": The modules which will be expanded for the"modules"option. Through the suboptions, it is possible to expand based on the module type using"types"and on the module name using"ids"."colour": This option defines the background colour used for the submodules. If there are more colours in the list, each colour is used for deeper level of hierarchy.The
"top"subsection can be used to define a different top module. If"enable"is true, then the module defined in"module"will be used as top module, instead of the top module defined in the input JSON file.Changelog
Status
Currently, this is ready for review. It has been tested on multiple inputs, ranging from small to large designs. The main functionality is working properly.
The main improvement which may be necessary before merging is the routing of wires. For the larger designs, wires take a lot of strange detours, but this is already the case for large non hierarchical designs. Since the layout is done by elkjs, it is hard to improve this.