FLUX progress...

[John Larkin]

I\'ve been watching the progress of these guys...

https://tinyurl.com/m3cnszx7

Somehow I have become a registered user with no effort on my part.

Have you used Flux, or know anyone who has? I can\'t see how this can
work or, frankly, why they haven\'t run out of money yet.

 

[Three Jeeps]

On Thursday, August 17, 2023 at 2:41:17 PM UTC-4, John Larkin wrote:

I\'ve been watching the progress of these guys...

https://tinyurl.com/m3cnszx7

Somehow I have become a registered user with no effort on my part.

Have you used Flux, or know anyone who has? I can\'t see how this can
work or, frankly, why they haven\'t run out of money yet.

Thank you for the pointer. Interesting concept. At some level, I am in disagreement with the statement \'Unlike software, building hardware is still insanely difficult\' - software can be \'insanely hard\' as well. But getting past that.....
Having SPICE tightly coupled to the schematic capture is an interesting concept...it eliminates a few steps. Works nice on a highly constrained example. Wonder how it works on a larger project? The availability of a wide range of sim models is key to having this uber-design bench.

The project workflow approach reminds me of \' find as many libraries of you can that do some or all of what you want and write the least amount of glue code necessary to \'make it work\' approach\'.

The PCB layout approach tutorial left me scratching my head. So you \'lift\' the board layout for a small set of components and plop it into a larger board layout, make the necessary connections then (re)run the DRC over the entire new assembly? What you just added could potentially really disrupt a layout that was acceptable and now the new board has to be reevaluated. Seems like a lot of thrashing that would result in a lot of time (manually?) rerouting nets.
The approach is interesting but there is a heck of a lot of building blocks that have to be around to realize hardware nirvana....
Interesting business model....free and then a cost on a per editor (what ever that is)
Thanks

 

[John Larkin]

On Thu, 17 Aug 2023 13:11:59 -0700 (PDT), Three Jeeps
<jjhudak4@gmail.com> wrote:

On Thursday, August 17, 2023 at 2:41:17?PM UTC-4, John Larkin wrote:
I\'ve been watching the progress of these guys...

https://tinyurl.com/m3cnszx7

Somehow I have become a registered user with no effort on my part.

Have you used Flux, or know anyone who has? I can\'t see how this can
work or, frankly, why they haven\'t run out of money yet.

Thank you for the pointer. Interesting concept. At some level, I am in disagreement with the statement \'Unlike software, building hardware is still insanely difficult\' - software can be \'insanely hard\' as well. But getting past that.....

They seem to be mostly programmers! And are applying software methods
(collaborate, hack it, ship it, push out bug fixes online often) to
hardware design.

>Having SPICE tightly coupled to the schematic capture is an interesting concept...it eliminates a few steps. Works nice on a highly constrained example. Wonder how it works on a larger project? The availability of a wide range of sim models is key to having this uber-design bench.

Personally, I don\'t see any upside to having the Spice sims use the
same schematic file as will be used to create the PCB. Library issues
make that impractical.

The project workflow approach reminds me of \' find as many libraries of you can that do some or all of what you want and write the least amount of glue code necessary to \'make it work\' approach\'.

The PCB layout approach tutorial left me scratching my head. So you \'lift\' the board layout for a small set of components and plop it into a larger board layout, make the necessary connections then (re)run the DRC over the entire new assembly? What you just added could potentially really disrupt a layout that was acceptable and now the new board has to be reevaluated. Seems like a lot of thrashing that would result in a lot of time (manually?) rerouting nets.
The approach is interesting but there is a heck of a lot of building blocks that have to be around to realize hardware nirvana....
Interesting business model....free and then a cost on a per editor (what ever that is)
Thanks

It claims to use AI, which doesn\'t make sense to me. \"Ask a stupid
question, get a stupid answer.\" Some short number of words, or
equivalent parameters, might evoke 10^200 possible circuits, unless
actual intelligence is applied continuously all along the way.

We were just discussing engineering project management here. We agreed
that management techniques and software work at some levels, but the
lowest level of electronic design is so tangled and parallel that
micromanagement - if any - is necessary.

 

[Don Y]

On 8/17/2023 1:11 PM, Three Jeeps wrote:

Thank you for the pointer. Interesting concept. At some level, I am in
disagreement with the statement \'Unlike software, building hardware is still
insanely difficult\' - software can be \'insanely hard\' as well. But getting
past that.....

Hardware is only difficult because there are *real* devices involved,
even after simulation.

And, difficult doesn\'t equate to *complex*. Many hardware designs
are incredibly trivial yet difficult to reify.

Having SPICE tightly coupled to the schematic capture is an interesting
concept...it eliminates a few steps. Works nice on a highly constrained
example. Wonder how it works on a larger project? The availability of a
wide range of sim models is key to having this uber-design bench.

Until we get quantum technology, more complex designs will be too
costly to completely model.

The same is true in software modeling. One can automate static and dynamic
analysis -- but, the time required to do so can easily exceed the available
market window!

The project workflow approach reminds me of \' find as many libraries of you
can that do some or all of what you want and write the least amount of glue
code necessary to \'make it work\' approach\'.

And this only works when those libraries are \"well defined\" AND the user
deploys them in cases that will fit within the libraries\' assumptions.
We conveniently call any misjudgements in this area \"bugs\" but, rather,
they are *errors* -- shortcomings of the library\'s specification,
implementation or application.

[Just like there are no car *accidents*; someone has always done something
wrong!]

If you encounter a serial port in a design, chances are it is
connected to address/data buses the same way as it is in every
other design. Is there a *rule* indicating this must be the case?
Does Data00 have to be wired to D0? Can the data *received*
register be at a different address from the data *sent* register?
(think about it!)

One can \"assist\" in a design by exploiting all of these...
\"habits\" (I am loathe to call them \"conventions\" as that
implies some reasoning behind it). But, what happens
when you ask your hardware to do something that the AI
hasn\'t previously encountered? How much help, then?

The PCB layout approach tutorial left me scratching my head. So you \'lift\'
the board layout for a small set of components and plop it into a larger
board layout, make the necessary connections then (re)run the DRC over the
entire new assembly? What you just added could potentially really disrupt a
layout that was acceptable and now the new board has to be reevaluated.
Seems like a lot of thrashing that would result in a lot of time (manually?)
rerouting nets. The approach is interesting but there is a heck of a lot of
building blocks that have to be around to realize hardware nirvana....

But, if you look at a lot of designs and don\'t get \"distracted by
all the trees\", most designs are just collections of interconnected
modules that (hopefully) previously were known to work (in some other
context).

Why reinvent each of those wheels?

And, if folks are content to purchase premade boards and glue
them together to build products, what\'s the harm in plopping
those \"components/boards\" on a single board and connecting them
in foil?

I build my symbol libraries so I can just abut two symbols on the
screen and then \"drag\" them apart to get most of the connections
that I want. I\'ve embedded my typical use of those components into
their symbol designs to save me labor. Why should I have to manually
add decoupling caps to a design? Or, manually specify how heavy
the trace should be for a specific signal? The machine has all
of the same information that *I* do, why can\'t *it* figure that out
and save me the hassle? (and, hopefully, reduce the possibility of
my making an arithmetic error in the process!)

Interesting business model....free and then a cost on a per editor (what
ever that is) Thanks

Until they change it. What do you do when you (or your staff)
have become reliant on it in your task estimates, etc.? <grin>

 

[Jan Panteltje]

On a sunny day (Thu, 17 Aug 2023 11:41:00 -0700) it happened John Larkin
<jlarkin@highland_atwork_technology.com> wrote in
<54qsdit999hfra1qq2itt1eeefusluo16r@4ax.com>:

I\'ve been watching the progress of these guys...

https://tinyurl.com/m3cnszx7

Somehow I have become a registered user with no effort on my part.

Have you used Flux, or know anyone who has? I can\'t see how this can
work or, frankly, why they haven\'t run out of money yet.

Seems a silly snake oil sales pitch to me.

 

[legg]

On Thu, 17 Aug 2023 11:41:00 -0700, John Larkin
<jlarkin@highland_atwork_technology.com> wrote:

I\'ve been watching the progress of these guys...

https://tinyurl.com/m3cnszx7

Somehow I have become a registered user with no effort on my part.

Have you used Flux, or know anyone who has? I can\'t see how this can
work or, frankly, why they haven\'t run out of money yet.

Board layout stripping for future AI \'assistant\'.

RL