[HN Gopher] JITX (YC S18) launches general availability and anno...
       ___________________________________________________________________
        
       JITX (YC S18) launches general availability and announces Series A
       from Sequoia
        
       Author : DHaldane
       Score  : 59 points
       Date   : 2022-09-20 15:52 UTC (7 hours ago)
        
 (HTM) web link (www.jitx.com)
 (TXT) w3m dump (www.jitx.com)
        
       | robbles wrote:
       | This looks really cool, and I would love to try it out on a hobby
       | project before considering it for something more serious.
       | 
       | Are you planning to make some kind of "hobby" tier below the
       | startup pricing at a later date?
        
         | DHaldane wrote:
         | We are - there will be a free offering for hobbyists soon.
        
       | m-hilgendorf wrote:
       | We have some code examples, for anyone that wants to see what a
       | software-driven design looks like!
       | 
       | https://docs.jitx.com/tutorials/quickstart-1.html
       | 
       | https://docs.jitx.com/getting-started/example-design.html
        
       | tomas789 wrote:
       | How does this differ from VHDL? Is it in principle something
       | different?
        
         | DHaldane wrote:
         | It's similar to VHDL in that Synposys came out with Design
         | Compiler in the 80s, and people switched from drawing
         | schematics to writing code to design electronics.
         | 
         | From a language perspective it's quite different. VHDL has
         | super-limited semantics to make it easier to synthesize. JITX
         | is embedded in a general purpose programming language, which
         | makes it more productive to write, and capable of describing
         | all the weird little details that need to be handled for board
         | design.
        
       | [deleted]
        
       | karmicthreat wrote:
       | I keep wanting to try this out, but man do they put up road
       | blocks. Skidl + kicad cover the programatic schematic entry part
       | kind of.
        
         | DHaldane wrote:
         | Founder here! JITX today is pretty tightly positioned at a
         | group of professional folks that find it very valuable. We'll
         | be opening up more fully later this year, and we'll relaunch
         | then with some pretty jaw dropping stuff.
        
       | krasin wrote:
       | JITX (and the general idea of schematics / PCB generators) is one
       | of big challengers to the way hardware is designed.
       | 
       | I hope they succeed. They easier it is to make new hardware, the
       | more competition is, the better products we get as consumers.
        
       | philsnow wrote:
       | Am I understanding correctly, this is kind of like code
       | generation (which is roughly a compiler that takes some sugared
       | language and produces unsugared code that's usually incredibly
       | ugly / indecipherable), but the input is some sugared language
       | and the output is board designs?
       | 
       | Do the board designs you output look alien / weird to people who
       | have been laying out boards by hand / with conventional EDA
       | tools? If so, is it causing any resistance to JITX adoption?
       | 
       | A common creature comfort requirement for anything that
       | transpiles / codegens, is source maps so that while debugging you
       | can see the lines of code that _you(r team)_ typed, rather than
       | harder-to-read generated code. Have you thought of trying to
       | bring that concept to JITX?
       | 
       | Super interesting, thanks for posting this.
        
         | DHaldane wrote:
         | Code generation is a good analogy - nice high-level code in,
         | CAD design out. The 'sugaring' is implemented in a macro system
         | that generates an Intermediate representation we designed for
         | electrical systems (kinda like LLVM for hardware).
         | 
         | JITX only produces weird-looking designs when they are provably
         | correct and of high-performance. You can't throw an
         | indecipherable mess to an EE and ask them to spend time
         | understanding it. That's just not a productive way to design.
         | There's a lot of work we do to make a design legible, including
         | generating a schematic for the user to read.
         | 
         | Yes! Our 'source-maps' connect the generated design checks,
         | board, and schematic back to the originating line of code. So
         | the user sees the output they are familiar with (e.g.
         | schematic), and can trace it back to the line of code it came
         | from. Collaboration in a team happens more at the source-code
         | level, and we make sure that the same CAD design gets generated
         | when that code is run.
        
           | philsnow wrote:
           | Thanks, this is amazing work!
        
       | gaze wrote:
       | Is schematic entry where most of the effort and complexity is
       | when doing board design? Will JITX address the layout part of the
       | design pipeline as well down the line?
        
       | kanwisher wrote:
       | Looks super cool to bad no remote roles
        
       | Archit3ch wrote:
       | I will be monitoring this and hope they succeed.
        
       | gswdh wrote:
       | Looks awesome and for sure will be the future. Most ECAD software
       | has a circuit 'library' function you can design something once
       | and use it many times so it's not completely fair to claim that's
       | something really novel.
        
       | wizwit999 wrote:
       | Like CDK for circuit boards, sounds pretty cool.
        
       | dang wrote:
       | Related:
       | 
       |  _Launch HN: JITX (YC S18) - Automating Circuit Board Design_ -
       | https://news.ycombinator.com/item?id=17654865 - July 2018 (54
       | comments)
        
       | tmitchel2 wrote:
       | Hoping for the following:
       | 
       | - Fully automated place and routing up to 3d PCB level, with
       | constraints including locked item positions, orientations and
       | board stackup. Most likely ML based and fairly quick and trained
       | on a simulator that takes into account various design rules,
       | realistic physics, etc . Zero input from a GUI.
       | 
       | - Datasheet semantics implemented directly into code / logic and
       | rules checking and analog simulation
       | 
       | - Use typescript, jsx to create the simplest way to implement
       | components and sub circuits. (I know this isn't going to happen)
       | 
       | - Use a cloud package manager so people can share thier sub
       | circuits and ICs
       | 
       | - Interactive heirarcical schematic
        
         | krasin wrote:
         | Generally in agreement, but two minor questions:
         | 
         | > Use typescript, jsx to create the simplest way to implement
         | components and sub circuits. (I know this isn't going to
         | happen)
         | 
         | I can see why not many people would be willing the learn a new
         | language from JITX (stanza?), but why typescript/jsx instead of
         | python?
         | 
         | > Use a cloud package manager so people can share thier sub
         | circuits and ICs
         | 
         | Why not just a github repository? Kind of like
         | https://github.com/NixOS/nixpkgs
        
           | tmitchel2 wrote:
           | Personal preference but I would say typescript because,
           | performance is not overly a concern when doing something like
           | infrastructure as code, great static type checking /
           | development integration already provided when using something
           | like vscode and lastly because it has jsx / tsx....And so why
           | jsx, I know that designing a circuit is more akin to a graph
           | data structure and jsx is really more suited to a tree data
           | structure but if you can get over that by defining your nets
           | separately up above the components in the jsx structure then
           | I feel like you can really harness a lot of the benefits that
           | jsx brings to regular UI design. Again this is personal and
           | I've mucked about with this very thing a bit myself.
           | 
           | Im not familiar with pulling a github repo to get at a
           | package, if it allows anybody to make their circuits publicly
           | available, forkable, etc then all good..
        
             | tmitchel2 wrote:
             | BTW definitely wouldnt recommend jsx it for something like
             | a digital design / verilog replacement. Hard for me to
             | reason even to myself why I would treat that differently to
             | discrete component domain...
        
       | yaseer wrote:
       | This is a really technologically interesting problem to solve,
       | congrats!
       | 
       | The GitHub analogy is particularly captivating.
       | 
       | The potential for applying code re-use and other programming
       | principles in hardware could create a 'Cambrian explosion' of
       | activity there.
       | 
       | I'll be monitoring this with some excitement!
        
       | noncoml wrote:
       | You know an idea is great when it makes you say, "How didn't I
       | think of it!"
       | 
       | Godspeed JITX
        
       | eatonphil wrote:
       | Nice work, congrats!
        
       | 650REDHAIR wrote:
       | I'm not an EE, but I've heard plenty of horror stories over the
       | last 2 years where a component is unavailable and an entire new
       | design needs to be configured with new available components only
       | for the redux to take too long and components are unavailable
       | again...
       | 
       | Can someone smarter than me tell me if jitx solves that problem?
        
         | DHaldane wrote:
         | Don't know that I'm at all smarter, but I have some domain
         | knowledge. Yes, JITX makes it easier to source/design in
         | replacement components and the circuits around them.
         | 
         | It's a major use cases these days with all the churn coming
         | from supply chain volatility.
        
       ___________________________________________________________________
       (page generated 2022-09-20 23:01 UTC)