Transistors are all oriented the same way

[RTimothyEdwards]

Example file:

https://www.xschem-viewer.com/?file=https://github.com/RTimothyEdwards/sky130_ef_ip__rc_osc_500k/blob/main/xschem/sky130_ef_ip__rc_osc_500k.sch

It should be obvious which devices are flipped; apparently the viewer is not capturing the component transforms?

[urish]

Thanks for reporting! M22 / M34 seem to be examples of flipped devices. Looking at the source, they both seem to have the flip flag (last number before the attributes) set to 1:

C {sky130_fd_pr/pfet_g5v0d10v5.sym} -290 -130 0 1 {name=M22

Despite being flipped, the texts inside aren't flipped. So if we simply applied a flip transform, the drawing would be correct, but texts unreadable:

@StefanSchippers how does xschem deal with it? does it automatically flip texts inside flipped components?

[RTimothyEdwards]

@urish : Here's a direct comparison from the example file, and I can enumerate all the differences: 1) Missing circles. pFETs are missing the "invert bubble" and the dots at wire junctions are missing 2) Device flips are not handled 3) labels are in white, not cyan 4) label top/middle/bottom alignment is not handled (i.e., "avdd" label should be centered on the pin, not above it) 5) label offsets are not handled correctly (i.e., "out0" is anchored at the connection point, not slightly offset from it) 6) Tcl evaluations are not handled (e.g., MiM cap C value and resistor R value aren't calculated)

You can see from the comparison that label bounding boxes are flipped (or rotated) along with the component, then the text is drawn in the box but always rendered either left to right, or bottom to top.

[StefanSchippers]

@StefanSchippers how does xschem deal with it? does it automatically flip texts inside flipped components?

for texts the bounding box (ie the text position) only is transformed but the text inside is rendered from left to right if horizontal or from low to high if vertical, to avoid mirrored texts.

When a text inside a component is rendered the text rotation and flip inside the component is evaluated, and combined with the rotation and flip of the component itself. (example you have vertical text placed inside a symbol, then you instantiate a 90deg rotated symbol in the schematic, the text is displayed horizontal).

The transformations for texts are not done with the traditional transformation matrix since I want text to remain readable.

[StefanSchippers]

[StefanSchippers]

See above the anchor point (the green '+' sign) for the default text (rot=0, flip=0) and how it changes with rotation and flip.

[RTimothyEdwards]

@urish : Additionally, if you look at this one: dccurrent_vdd.sch 1) Newlines in the "code" text aren't rendered, so multi-line code output ends up on one line 2) Symbols coming from other directories cannot be found because the renderer is not reading the xschemrc file, and in general may not be able to know where all symbol sources are coming from, since the xschemrc file may be passed on the command line and may not even be in the directory where the schematic is being viewed.

[StefanSchippers]

2. Symbols coming from other directories cannot be found because the renderer is not reading the xschemrc file, and in general may not be able to know where all symbol sources are coming from, since the xschemrc file may be passed on the command line and may not even be in the directory where the schematic is being viewed.

Regarding this item I think there is no easy and universal solution, xschem can load remote designs like for example: xschem https://raw.githubusercontent.com/yrrapt/amsat_txrx_ic/master/design/dac/dac.sch

when descending into sub blocks xschem does some heuristic to try to find the referenced schematic. It does a couple of url downloads and then gives up if not found. Designs that load fine are of course ones with all blocks in the same directory and designs where sub block references are specified as dir/schematic.sch. dir is looked up either in the same directory of the parent schematic or in the parent of that directory. Can't do much more since web probing is slow and there is no limit in how complex a design directory tree could be.

[urish]

Thanks for the detailed breakdown!

1. Missing circles. pFETs are missing the "invert bubble" and the dots at wire junctions are missing

@StefanSchippers how are wire junctions represented?

Also, circles (like the invert bubble) are now rendered correctly

[StefanSchippers]

@StefanSchippers how are wire junctions represented?

wire connecting cues are drawn with a small filled circle with same color as the wire layer. a connecting bubble is shown if 3+ wire ends land onto the same point or if 1+ wires end in the middle of another wire.

[urish]

Thanks, so they are not present in the schematic file - rather, they are automatically generated, right?

[urish]

And regarding the texts - do you happen to have the .sch file for this drawing?

[StefanSchippers]

Thanks, so they are not present in the schematic file - rather, they are automatically generated, right?

exactly.

[StefanSchippers]

And regarding the texts - do you happen to have the .sch file for this drawing?

I have recreated it here.

schematic attached. text_orient.zip

[urish]

Thanks! Regarding the junction points, do we assume all lines are either vertical or horizontal? Or do we also need to support diagonal lines?

[StefanSchippers]

Thanks! Regarding the junction points, do we assume all lines are either vertical or horizontal? Or do we also need to support diagonal lines?

xschem does not assume horizontal or vertical wires. You can use oblique wires. Connecting dots are shown if wires do "exactly" touch. In some cases you draw oblique wires, you think they touch but they don't. Xschem uses double floating point coordinate space and is set up to use coordinates that have an exact binary representation (example: x=1.0, x = 100.0, x=0.125 have exact binary representation, while x=0.1 does not).

[StefanSchippers]

of course abusing oblique wires is bad design practice. One legit case is the 2-nand latch shown above.

[urish]

Thanks! I just pushed support for drawing junctions:

https://github.com/TinyTapeout/xschem-viewer/blob/b3e2a5c95e659b9791c18dcce2c01e37e6b856cd/src/SVGRenderer.ts#L237-L259

I hope I got it right :)

Another question regarding this:

3. labels are in white, not cyan

Looking at the .sch file, the line that draws the label is:

T {@lab} -7.5 -8.125 0 1 0.33 0.33 {}

When no layer is set, I'm using layer 3 (Text color) by default, which is gray. Xschem renders this text using the Wire color, so obviously, I'm missing something.

[StefanSchippers]

Another question regarding this:

3. labels are in white, not cyan

Historically xschem did not have a specification for color in texts, there was only white text. Later this was added, so all texts were normally drawn in gray (layer 3, TextLayer), however texts inside symbols that are of type 'ipin', 'opin', 'iopin', 'label' were/are drawn in the same color as wires.

[urish]

6. Tcl evaluations are not handled (e.g., MiM cap C value and resistor R value aren't calculated)

I added some basic support for evaluating TCL expressions. Obviously, it won't cover all cases, but for now I implemented the ev proc, as I'm seeing it's commonly used. If we need other stuff, it should be pretty straightforward to add here:

https://github.com/TinyTapeout/xschem-viewer/blob/main/src/tcl/init.tcl

[urish]

Historically xschem did not have a specification for color in texts, there was only white text. Later this was added, so all texts were normally drawn in gray (layer 3, TextLayer), however texts inside symbols that are of type 'ipin', 'opin', 'iopin', 'label' were/are drawn in the same color as wires.

Thanks! I implemented this logic, and now the labels are colored correctly.

[urish]

@StefanSchippers thank you so much for providing the text_orient example. I think I finally managed to get it right:

https://xschem-viewer.com/?file=https://gist.githubusercontent.com/urish/85e51a734c53e1f8f4821cc0318bb732/raw/486c94927890649e1ee9a42c0763fa69d64dde35/text-orient.sch

and with that, now we also have proper support for flipped components!