nyancad / mosaic Goto Github PK

Currently opening a schematic with invalid data just crashes the app

It'd be nice if you could not only drag the whole wire, but also drag one side of it. This would also need to drag any other wires connecting to that node.

Somewhat ties into dragging components with the wires attached.

Currently there is no link between the editor/library manager and the Jupyter stuff.

In the pure client-side case there is no Jupyter stuff. It could link to binder though? That would be smooth: zero barrier to start drawing, one click to continue in a binder.

Maybe a custom init function is needed that passes the Jupyter URLs.

give feedback when stuff is saved

Matt Venn reported drawing wires skipped tiles for him, while not even moving that fast.
For me I have to go quite fast to do this, so I have to test this more on slower devices and then either optimize the code or backfill between mouse events.

Currently only shift-click is supported.

Will require some custom SVG wizardry and geometry trickery.

keep dragging when changing focus

As of #14 we now have wire labels, but some improvements are still needed:

• Logical behavior when erasing/splitting/combining wires
• Special ground node
• Supply nodes?
• rotate/mirror labels should not result in upside-down text

So we can serve JS files from jsdelivr CDN and stuff

Currently Mosaic uses PouchDB for in-browser storage, with syncs to an external DB.

When deployed as a Jupyter extension or desktop app, it is preferable to use a local CouchDB/PouchDB-server because Python can access it, unlike the in-browser database. These two cases are the primary ones. Running pure client-side creates a very low barrier to try it out, but does not support simulation. Therefore the default should be an external database.

It would be possible to make the cloud the primary database for the client-side case, but this is likely to cause latency in the UI. Worth trying though.

The UI already takes a db and sync parameter. I think the main change would be that the library manager has a name, local url, and remote url, and uses different defaults.

On the Jupyter side, it could instantiate the library manager preconfigured to use the same database Jupyter uses.

and switch rather than placing the current component mid-drag

would make sense to make elements a "tool" instead of dragging a component

• rename & delete devices in library manager
• do stuff to elements in the schematic?

Probably needs to be made selected? Or rotate-selected needs to know about staging.

the symbol itself

Mosfets are the bread and butter of IC design, so having a good icon for them is super important. There are so many styles though.

This seems to be the most common one in datasheets and papers. Nice and simple, but hides the bulk connection.

Some more variants.
I don't like the ones with the arrow/ball at the gate because it doesn't make much physical sense. It does convey the symmetric nature of a mosfet, which on the one hand is nice, but doesn't communicate design intent well in terms of the side with the high/low impedance.
The ones with the bulk line are more explicit, but more "busy"

Current design: explicit bulk connection. I choose it because it's the closest to what is physically happening. Downside: often the bulk connection isn't very "interesting"

It also prevents connections like this which are very common in current mirrors and the like

So I think ideally we'd have the first example for the common case where I suppose the bulk connection is specified in the properties pane, rather than in the schematic. And then the 4 terminal case is there if you want to do something fancy with backgates and tripple wells and such.

In the 4 terminal case you should be able to do this with a better UX than what I did here, which is draw a single segment wire, add a label to it, give it a name, and then drag it under the bulk terminal. It can still be that under the hood, but the UX should be more like a proper "label" element.

anotations

Besides the mosfet itself there is a bunch of info you might want to show in the schematic. On the one hand you want to keep the schematic as clean as in a datasheet or paper, so you can focus on the core topology, on the other hand you also want to see all the important design info at a glance.

Cadence goes for the all out verbose mode, which isn't great IMO.

Currently, no annotations are implemented at all, so even more bare than the paper "M1" label. Also not great maybe.

An amazing thing EveryCircuit does is that it shows the mosfet operating region. I would love to steal this. Not so sure about the real-time dots racing around the circuit, I think it doesn't scale very well to more complex simulations. But as discussed in #18 the little mini plots could be a useful annotation.

Another key thing to annotate might be the W/L ratio. But the range of sizes is such that literally scaling the mosfets would look quite ridiculous. But what if it had a little rectangle? Doesn't really convey the absolute size, but dunno it seems kinda cute.

For other things I think some generic templating language might be perfect. Like you just add a little textbox with gm: {op.m1.gm} and it shows you the gm from the operating point simulation or whatever. Good idea or too hacky/finicky?

The plan is that the simulation backend talks to the CouchDB database to retrieve the schematic, simulate it, and write annotations back into the database. This means the simulation can run in Python, Julia, Rust, whatever. Most likely in Jupyter or Pluto

There needs to be a flexible, extensible, configurable, intuitive way to store and display simulation results inside the schematic. Some basic use cases:

Operating point simulation that annotates the results onto the nets and devices. These are simple numbers per device.

AC simulation that could annotate things like... bandwidth and other derived properties like phase margin. But these don't belong to a specific device.

Transient simulations could annotate the plotting color so that the schematic can use the plot color for a visual connection between wire/port and plotted results. These are per device, but rich data types, not just numbers.

You could even embed entire plots inside the schematic. You could go full https://falstad.com/circuit/ or have like mini icon-size plots, that give you an idea of the shape of the signal at that node, without "details" such as the axis.

So hmmm on the one hand the basic stuff is mostly per-device, which is neat. But maybe there needs to be a standalone "annotation" component? It would not be much different from any other custom component, and no reason the backend can't add components.

Maybe these should just be added in the same framework as device properties. In that they are visible in the device panel, and can be selected as visible, and have some metadata associated about how to parse and display them and such.

Would it be a flat list, or scoped per simulation? I think a flat list would mooostly work out fine, and make things easy for displaying and such. But maybe there are situations where you want to annotate, say the gm of different speed corners, in that case you'd want like ff/gm tt/gm and so forth. I guess you could leave it up to the backend to generate unique names.

But I think... it's important to not turn the schematic into a full fledged result viewer. Annotations are to provide context and aid design. Not an entire datasheet or full-sized interactive plot.

Problem

In the schematic editor, the wire preview remains when cancelling the wire drawing mode by pressing escape. After the problem occurs, the wire can not be deleted without restarting the schematic.

Reproduction

See also the attached screencast

Platform: Chrome, MacOS

• Open a new schematic
• Draw a wire by pressing w or clicking on the pencil icon
• While drawing the second segment, press the escape key
  • The hand tool should now be highlighted, but the wire preview should still be showing
  • Clicking anywhere does not place a wire or cancel the wire preview
• The mode can be cancelled with backspace
• The wire now cannot be deleted
• In addition, new wires will be drawn at locations shifted from the cursor (not shown)

Some thoughts: https://twitter.com/pepijndevos/status/1440309120070942733

I think coarse grid is working out great. Very easy to align things.

"redstone" wires prove to be a bit tricky in making neat and dense schematics. Don't support diagonal wires. Cause some unintended connections. See #16. Could be somewhat mitigated by storing vertices rather than nodes. Or completely swapped out with a more KiCad-style system.

Tetris is great for telling at a glance if a mosfet is PMOS or NMOS without wreaking your brain about which direction the arrow goes. It does seem to draw more attention to the wires, so needs some rethinking maybe. Other ways to easily tell components apart visually? See #19

This is a temporary feature until we get more full fledged simulator integration.

Two conflicting requirements: interactive feedback & long-running simulations

Feedback is everything in design. Change something, see the results. For small circuits and in particular for operating point, it's feasible to interactively run a simulation, and update the plots and annotate the operating points in the schematic.

On the other hand, for complex designs simulations can run for hours or days and you don't want to lose your results if you close the tab or something.

You want to be able to automate as much of the simulation and measurement as possible, and as little manual running and analyzing waveform plots. On the other hand analog designers aren't great programmers, so keeping it simple is paramount.

I think Jupyter Lab is a great platform to run both interactive simulations and plots, as well as long running simulations (possibly with the aid of %%capture )

so first point is: we need a simple Python API. This can use the collaboration API to just fetch the schematic from CouchDB and write annotations back to it.

Second more complicated point: how does Jupyter integrate with Mosaic? Do they just run in their own tabs? Do we embed Mosaic as a Jupyter Lab editor? Do we embed Jupyter notebook inside Mosaic?

For context, what I think is the wrong approach is the Mosaic Pluto.jl plugin in which the editor feels cramped, being embedded inside the notebook, and in which there is no good "upgrade path" to running long-running simulations outside of the notebook. This is using a JS API to send the netlist to Julia. I think using a CouchDB API will allow "upgrading" to an offline Python script much easier.

Even better would be a dedicated text editor...

Make everything pretty

https://youtu.be/g_NK7B2xfsc?t=408

Needs a refresh to show them. Probably because ratom shenanigans.

Biggest UX fail at the moment is connecting wires to the middle of another wire. The horizontal wire has 3 pieces. At the ends they connect (dots). The crossover is probably intentional, but the T junction without a dot is probably not.

The easy part is just showing that it's not a connection, but this is just yelling at the user while you damn well know what they intended to do. The hard part is having some concept of "in the middle of a line" and maintain some index and keep the option of crossing wires. Something like Bresenham's line algorithm, and then have a "weakly connected" index such that only end->mid is a connection.

And then what? Do you just consider it connected, or do you split the wire at that point? I kinda want the wire splitting logic anyway for drawing a line "through" a component.

So when committing a wire you'd check the weakly connected index for the endpoints of your wire. And if the endpoints overlap with the weak index, you split those wires in two.

Building the weak index could be a slow operation though. Are we going to loop over all the devices? Maybe we need to think about having CouchDB views for the wire indices? CouchDB is hopefully smarter about updating the indices, and can be reused on the Python side.

• Must have variable number of terminals
• Should have variable number of terminals per side
• Must have unique terminal names
• Should have user-settable terminal names
• Must have use-settable model name
• Should display display model name

Should get its own unique id

Space should change to wire tool I feel
Esc should revert to pointer tool

UX guy wanted to make space drag the view. While I agree middle mouse button is an unpopular choice, I'm not sure I agree.

What to display? Name? Value? Operating points?
Where?

• Het wordt vrij snel moeilijk om over het schema te communiceren. Ik houd van de clean look, maar een vinkje om reference designators te laten zien (binnen de blokken) oid zou het veel makkelijker maken om bij een design review een onderdeel aan te wijzen.

Zou je het volledig in het blokje van het onderdeel kunnen plaatsen? Ik denk dat je met kleine indicatoren 80% van de use cases hebt. Als je dan nog iets implementeert om componentwaardes in het eerst beschikbare blokje naast het onderdeel te laten zien heb je nog eens 15%.
Voor passives zou je misschien zelfs alles in het blokje kunnen passen, of wellicht kan je een optie hebben voor een 'expanded view'. De meeste informatie in cadence is imho onnodig, en bij alle design opdrachten krijg te horen "maak een tekening - GEEN CADTEKENING - van je circuit", omdat de CAD-tekening blijkbaar als te rommelig wordt ervaren.

An import/export function for libraries en cells would be very handy (somewhere in the future). The difficult part is that such a function should be capable of dealing with existing libraries/cells with the same name that already exist and the cell export function should have an option to include all sub cells and include them in a new library (or cell because in Mosaic a cell can contain subcells?) such that somebody can immediately simulate the top cell on a different computer.

Open question: how to avoid conflicts with browser shortcuts, or typing in text fields.

In Cadence it can sometimes happen that if you press backspace in a text field that it deletes the selected component. We don't want to be doing that.

Currently, net names aren't displayed except when selected. Create a mechanism which displays certain net names permanently. A nice to have would be to have both inline net names (like KiCAD net labels) and external ports-style net names (like KiCAD global labels in their various forms).

The line interpretation system automatically connects loops even when behind components. For instance, the MOSFET bulk and source get connected when drawn out.

Replication

Draw the following circuit.

Result

There is a line between the MOSFET bulk and source, because the wire automatically connects to itself.

On tighter loops, this causes a whole lot more unintended lines:

Workaround

The problem is only cosmetic. The problem can be minimised by drawing sufficiently large loops or drawing direct connections:

tooltips, units, etc.

Jupyter notebook version control is kind of a PITA in itself: https://nextjournal.com/schmudde/how-to-version-control-jupyter

We're using CouchDB for storing schematics, which uses an append-only log with MVCC, yet its document revisions are not a reliable history in the way git commits are: compacting the database will erase all old refs, and not all refs are replicated.

Easy solution: we need some kind of snapshot functionality to save a copy of the entire library.

Follow-up question: are snapshots hierarchical and/or editable, or just "version 4 final final" backup copies? Can you diff/merge them? I feel like cell views/entity implementations are kind of the equivalent of branches, so you would swap rather than merge them. I think snapshots should be non-editable but you could of course restore schematics from a snapshot, possibly under a new name. We do need merging for conflict resolution anyway though, and maybe also for restoring schematics. Collaborative editing is really a different and seemingly incompatible paradigm from DVCS like git. What does Google Docs/Figma do?

The real issue is reproducible simulations. I should be able to check out an old commit and run the simulations on a matching database, or take an old snapshot and find the matching code. You can go two ways in this:

Store the code with the schematic. Add a git hash to every snapshot, or even upload the code to couchdb. Downside: you might end up implementing half of git on top of couchdb.

Store the schematic with the code. Add a snapshot ID to every commit, or even commit the entire schematic. I think storing snapshots in git is the right approach. The whole thing. Use git for version control, CouchDB for collaboration. Using a daemon, or a git hook?

The core UX issue is that you want to have real-time updates while you work, and reproducible simulations after you commit. Should the library be git-aware? Does the database need to be scoped by branch name, or commit even? Or just leave it to the user to which database or local snapshot to use?

drawing the same wire should not make a new wire, but behave as if you started drawing from the other end.

Notably: it should not end the wire

• Accept text input for spice parameters like {W_in}
• Make identifier user-edditable (so the user can specify Min_p instead of nmos26)
• Add M-factor / number of fingers parameter

Something is causing invalid state to be produced...
It may have to do with the eraser, or maybe some old state is just stuck in the database, who knows.