KiCad Spice, Anyone Tried It?

Tough cookies, buttercup.

I design electronics that works and sells, and you don't.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

This does not sound correct. What problem are you trying to solve?

If I recall, one could choose threads to have local (to the process) scheduling scope, or global scheduling scope (at the level of processes, in effect. I'm pretty sure that POSIX provides that, and Linux and Posix largely overlap in such things.

Absolutely. It's an embedded computer, not a general-purpose computer.

The way I've seen this done in big radars is by use of Linux/Posix realtime scheduling policies:

.

And yes, shared memory windows are widely used.

Joe Gwinn

If an operational amplifier is the processing unit, this is already the case for a large category of applications.

So, a firmware EPROM (that has to be yanked and physically replaced in order to change the firmware) is... hardware?

And a bug in the firmware is a hardware bug if 't s EPROM, but a software bug if it's a flash ROM?

:)

And somebody once calculated that about 10% of the top glider pilots had died, far more than the general glider pilot population. That's unsurprising when you realise they choose to fly close to the edge of the envelope.

Or fuse programmable logic, or programmed/unprogrammed FPGAs, or the one time programmable MCUs costing $0.03 each, or a microcoded processor, or...

Clearly neither of you guys can tell the difference between a computer (which can break your toe if you drop it) and the programs that it runs (which can't.)

Too much abstraction has that effect on people. Nuance creates paralysis.

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

Correct :)

False.

Wait what! The compiler determined that big calc had no side-effects somehow?

--
  Jasen.

I had an interesting discussion once about whether FPGAs used software, firmeware or something else. It lasted quite a while with strong opinions.

It's silly to even talk about software and hardware separately. Neither is much good without the other. But then many of the points Larkin makes are silly whether or not they are accurate.

--

  Rick C. 

  -+-- Get 1,000 miles of free Supercharging 
  -+-- Tesla referral code - https://ts.la/richard11209

Well I learned some things from your posts, so thank you!

There are old pilots and bold pilots, but no old bold pilots. I'm old.

--

-TV

And I'm too old :(

Here are a couple of envelope-pushing videos. The first is hooning around doing a "Thomas Crown Affair (1968)", the second using ground effect to get home in a competition.

Some droll comment on the latter, e.g. "thats not where I would have started my circuit but keep going" :)

I appreciate that feedback.

(I've learned a few things from other peoples' posts in this group too. Not many - the noise to signal ratio is very high here - but a few.)

Yes. It can see the definition of "big_calc", and thus knows all about it - including that it has no side-effects or observable behaviour. So it can be inlined in foo() and optimised in a variety of ways, including inter-weaving with other code in foo().

(The compiler must also generate a function "big_calc" that can be called from other units - I didn't bother pasting that into the post. I recommend playing around with these things in if you want to see what happens. Don't forget compiler flags like "-O2

-Wall -Wextra" to help out.)

Not necessarily.

Consider one aspect of intel chipsets, the System Management Interrupt (SMI).

Those have delightful characteristics:

- generated by power management hardware, so unless you include "hot and high" tests, one might not occur

- higher priority than NMI

- invisible to the operating system and software

- can't intercept them because they don't have a vector in the CPU

- when generated, the CPU goes into a special mode

- can last hundreds of microseconds

You can disable them, but that risks the processor burning.

Did you know those existed? Does something equivalent exist in other chipsets?

FFI,

See my other post about intel processors' System Management Interrupt.

SMIs wouldn't have been noticed in my application, but they could screw applications running nearer the metal and with tighter time constraints.

20 billion is enough for me. Every interrupt is visible, and I can add. We avoid dynamic memory allocation and garbage collection and such as much as we can. Once I get a risk so low that it doesn't materially affect MTBF, I can ignore it. As far as we know, the Zynq/Linux things are reliable in the field. It wouldn't explode if it missed a few interrupts per week anyhow.

What would you do? Analyze the source code of Linux for a decade or two? Formally prove the system to be correct?

Some of our products are just the Zynq on a board with parts, some are MicroZeds, and I just got a couple of PicoZeds to play with.

Intel for anything real? For anything reliable? You are joking, of course.

One of our friends had the Liniux kernel re-written to make it more real-time. We don't need to do that, because we have the option to move time-critical stuff into the FPGA fabric.

--

John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 

  Claude Bernard

And that is the sensible part of your response, and one of the many reasons why people need to understand hardware and software, their tradeoffs, and where to set the boundary between them.