A collection of classes providing simple hardware specification, simulation, tracing, and testing suitable for teaching and research. Simplicity, usability, clarity, and extensibility are the overarching goals, rather than performance or optimization.
For nets where the order of incoming edges matters (e.g. c, -, <, >, x, and @), it would be nice to improve the way visualizations present them.
For example, given the following netlist:
tmp6/1W <-- s -- i/8I ((4,))
tmp4/1W <-- s -- i/8I ((2,))
tmp2/1W <-- s -- i/8I ((0,))
tmp5/1W <-- s -- i/8I ((3,))
tmp7/1W <-- s -- i/8I ((5,))
o/8O <-- w -- tmp10/8W
tmp10/8W <-- c -- tmp7/1W, tmp6/1W, tmp5/1W, tmp4/1W, tmp3/1W, tmp2/1W, const_0_0_synth_1/1C, const_0_0_synth_0/1C
tmp3/1W <-- s -- i/8I ((1,))
outputting to SVG produces the following:
It would be greatly improved if [5] was furthest left, followed by [4] to the right, etc., like the actual netlist is.
This is probably an issue specifically related to using graphviz, so if that library doesn't have the capability, it might be nice to consider adding support for an output format that respects left-to-right ordering.
For nets where the order of incoming edges matters (e.g.
c
,-
,<
,>
,x
, and@
), it would be nice to improve the way visualizations present them.For example, given the following netlist:
outputting to SVG produces the following:
It would be greatly improved if
[5]
was furthest left, followed by[4]
to the right, etc., like the actual netlist is.This is probably an issue specifically related to using graphviz, so if that library doesn't have the capability, it might be nice to consider adding support for an output format that respects left-to-right ordering.