hal
hal copied to clipboard
emsec
Cell symbol
Hi,
it would be really great if there was a way on how to display cells as symbols, not simply as rectangles. That-way the visualized circuit would functionally resemble what it actually does.
There may be two ways on how to achieve this:
- Load some type of symbol file explicitly.
There are couple of symbol formats (e.g. XSCHEM has one, then there is proprietary OA format, and other plaintext formats exist). This might easy way on getting this done, but IMHO not the best.
- Infer the symbol from the known logic function by HAL itself.
There could be set of predefined pictures for AND, OR, XOR, FF, LATCH, MUX, and HAL would form the symbol based on parsing the known logic function. If the logic function is not known (e.g. as in case of black-box macro as I was mentioning in the other issue), HAL would simply display rectangle as now.
It is an interesting idea, I like the spirit of innovation. It would need some more input and sample drawings before we can consider implementing it.
- How would the pins get aligned in a non rectangular shape?
- How can the shape gets automatically extended to make space for lengthy names and labels?
- Right now all input- and output nets connecting a gate start at the same x position. Yet wiring is a complicated task requiring a lot of CPU time. We would have to test whether it causes a huge setback in layout performance if all wires start/end at different positions.
- Will non rectangular shape have an impact on performance of zoom- or pan-operations?
And then there are some NO-GO's to consider. I have seen some FF graph representations where Set is connected from above (top side) and Reset from below (bottom side). That would screw up everything in our layout algorithm. Inputs must be on left side, outputs to the right.
Hi,
How would the pins get aligned in a non rectangular shape?
I think it can be done in rectangular shape. The symbol pins would simply extend to a rectangular bouding box. Imagine having a "normalized row height" being N. E.g. 2-input AND gate would have 2 * N height. Its pins would be located on (0, N/2) and (0, 3/2 * N). The bounding box for such AND would be (0,0) x (2N, 2N). Output would be in the middle of the "AND", at coordinates (2N, 1N). Now imagine we would have something like AOI (2 * AND followed by OR cell). The bounding box would extend both in Y direction (4N), but also in X direction, since an OR gate would need to be drawn after those two ANDs. If a cell outputs were made from multiple "stages" (e.g. output A created just from first gate - the AND gates in previous example, and output B was created from second example, the output A would simply extend to the full width by a simple line.
The arangment I have in mind would have following properties:
- Rectangular shape is kept
- Input pins are on the left, output pins are on the right.
- The output pins may potentially be non-equidistantly spaced along the Y axis at the right most edge of the bounding rectangle
I will draw some examples in the nearest days and post it here.
How can the shape gets automatically extended to make space for lengthy names and labels?
I think it would not need to necessarily extend. When having the "symbol view", the full name of the instance would not be display always, e.g. only a "canvas" would appear over it when hovering with the mouse. Or simply the last part of the name (the instance name) would be displayed only.
Right now all input- and output nets connecting a gate start at the same x position. Yet wiring is a complicated task requiring a lot of CPU time. We would have to test whether it causes a huge setback in layout performance if all wires start/end at different positions.
If the rectangular bounding box is kept, this would be still true.
Will non rectangular shape have an impact on performance of zoom- or pan-operations?
No impact since the shape would stay rectangular, only its size may change. Now it changes only in Y axis. With the new setup it would change within X axis too.
And then there are some NO-GO's to consider. I have seen some FF graph representations where Set is connected from above (top side) and Reset from below (bottom side). That would screw up everything in our layout algorithm. Inputs must be on left side, outputs to the right.
Yeah, it would be nice to have it like that, but it can be ommited. The flop picture can be drawn like that, but the R / S pin would have a wire coming out of it, right-angle degree, and head to the left bounding box of a cell. The same would be valid for clock, only from bottom.
I made some hand-drawings:
The idea is that everything would stick to some grid. The picture above shows N with grid dimension and each pin is placed either at N or at N /2. If halving the grid, everything would stick to N -> All pins at known positions. The bounding box (the dashed red), is always rectangle, and it is a place where the wires would stick.
If there are more complex combo cells, their "picture" can be assembled from the primitive "AND", "OR", "XOR" and the "inverting circle" before / after a pin. Such cells can be assembled in "stages" as they propagate through the primitive cells (e.g. AOI cells). I am sure there will be some corner-cases, where the sub-cell placement within complex cell may be problem, but IMHO this would cover 95 percent of cells available.
Some topics that may be TODO in this concept:
- How to handle multi-bit flops ?
- An "ADD" and "SUB" drawing with + / - in the middle may be good to add, I have seen those in some PDKs.
- How to handle "power" pins ? Should we display them or not ?
We appear to have external interest in at least the icons part of this FR. Having a way to assign a (pre-defined or custom) icon to a gate or module allows you to see the function of that component at a glance, vs. having only text-based labels. It is also more in line with how schematics would traditionally be done, and may improve UX for users coming from those EDA tools.
@joern274 what's your current timeline on this feature?
@RenWal : It looks like you are going to join the efforts 😺 , this will definitively speed up things. So far I did only prestudies to find a way to have gate specific icons implemented without throwing 10 years of HAL development away. One of the major obstacles to overcome is the connecting of pins and wires since it cannot be placed at any location. Because the routing knows only integer values all connection points must be located on a grid. I might have a plan for that (rectangular virtual box around the gate specific icon).
Other question where I would need a counterpart to develop ideas :
- How to deal with lengthy gate names
- How to deal with module colors
- How to deal with group highlighting by grouping colors
- How to implement pin highlighting upon key-arrow navigation
So thanks again for joining the efforts.
Thanks Jörn! I'll put this on the agenda for our next meeting, let's have a quick chat on how we can build this together :)
Dear issue subscriber (@Blebowski ?!) , I have submitted a prototype for testing. Please checkout the branch feature/gate_icons. A simple, silly example netlist featuring a variety of gate types can be found under example/gateicon_demo.zip.