KiCad Spice, Anyone Tried It?

Now that's a keeper.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin
Loading thread data ...

what

like to

ected

t all

s,

d.

x.

t

'd

I

Yes, on the XMOS you run every process in its own processor until you run o ut of processors... then you are back to sharing like everyone else does.

--
  Rick C. 

  --++ Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Ricketty C

As long as they have other skills that complement yours, that sounds like an ideal combination. Jack Sprat could eat no fat. His wife could eat no lean. So together they scraped the platter clean.

It is always good to be able to help people step into areas where they are unsure and have things to learn.

That's easy to do with kids, less so with adults that have appearances to defend.

In hard realtime, you are only interested in the worst case; nothing else matters.

That's why "measure and hope you've spotted worst case" is so unappealing.

Sounds sane. Processors intimately coupled with FPGA are /one/ good starting point for many interesting things.

I haven't investigated real time linux on the grounds that it feels as if the proponents only have hammers in their toolkit.

Fine if the processors are grossly underused.

Reply to
Tom Gardner

Hardware is physical stuff that you buy or make, and pay for per unit. Motors, transformers, PC boards, opamps. Things that have mass.

Software is stuff that people type and that temporarily changes the states of some storage elements. It is massless.

They normally

All artificial, arbitrary, trendy constructs. None of them will drive a fuel injector.

Real men design hardware.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

Design an electronic circuit. Post it. That would be fun to see.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

All technologies have their limits. The question is whether you can do useful work within the limits.

That also applies to the GA144. I know which technology is widely used and which company continues to get new investment.

Reply to
Tom Gardner

But the worst case only occurs when Jupiter is aligned with Mars. Or during acceptance tests on a customer's site.

Reply to
Tom Gardner

True, I don't have a Boeing 777.

Reply to
Tom Gardner

I haven't done performance-critical code on Linux for a few years, but last time I checked, the thread scheduler was a mess.

In Windows and the late lamented OS/2, a given process can have user threads, real-time threads, and can set any priority it likes. Since I haven't done performance-critical code on Linux for a few years, so there's some possibility that it's improved, but as it was obviously a design choice I sort of doubt it. (Broken As Designed.)

In Windows and the late lamented OS/2, a given process can have user threads and real-time threads, and can set any priority it likes. Since those are basically single-user OSes, if you want to hog all the CPU cycles, knock yourself out. That's super useful in situations such as distributed simulations, where you can make the communications threads high priority so that one node doesn't wind up waiting while its neighbour sucks its thumb even after the data are ready to send. I have a comms library that I've used for yonks, which encapsulates a high-priority thread blocking until data are available, then waking up, sending/receiving, and then blocking again. Works great.

In Linux, this is not doable in a single process. Despite what the pthreads docs say, a user process cannot change the priority of any thread--you can't even _decrease_ it--and all threads of a realtime process are higher priority than any user thread. Thus if you try doing a compute-bound thing in a realtime process, you immediately bring the UI to its knees.

Whenever I bring this up, fanbois immediately jump on me for trying to hog the machine, as if running my own code on my own box and wanting it to do as it's damn well told qualifies me for a Scarlet Letter.

In fact, most of the time I'd be perfectly happy to have my compute threads running at niceness +20 and the communications threads at +19, but nooooo. To do it, I'd probably have to use all sorts of fuggly nonportable shared memory things between a user process doing the work and a realtime process just doing the comms. Stooopid.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Newer scopes have colour histogramming to show rare events as being rare, which is nice for that sort of thing. If I ever buy a bnew fancy scope, that and the number of traces per second will be why.

Cheers

Phil "boat anchors rule" Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Or even a Yugo, apparently. ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

No, it is not thrown away - it is written to an externally accessible variable. Please look at the code before resorting to insults.

I have never suggested that a compiler would /always/ re-order code. I have said it is always allowed to re-order it, as long as all observable behaviour has the right values and the right order. I started with an example to explain the kind of re-orderings that are allowed. I have since then shown you several examples where they are not only allowed, but where a compiler clearly does such re-ordering in practice.

I have shown that semicolons do not affect ordering, nor do function calls (when the compiler knows the definition of the function, and therefore knows all about its observable behaviour). I have shown that you are wrong in your ideas about how C is defined.

Would you like chapter and verse from the C standard? You can find the latest free version (the last draft of C18, N2346) online and look at

5.1.2.3p6 under "Program execution" :

""" The least requirements on a conforming implementation are:

? Volatile accesses to objects are evaluated strictly according to the rules of the abstract machine.

? At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced.

? The input and output dynamics of interactive devices shall take place as specified in 7.21.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input.

This is the observable behavior of the program. """

What do you consider a "toy" example, and what do you consider a "real" example? I suspect you view "toy" as "gcc re-orders the code, proving David's point" and "real" as "gcc doesn't happen to re-order the code at the moment, letting me keep my illusions".

But just as a final example, along with a local "big_calc" function I'll throw in some library maths functions, including conversions back and forth between integers and doubles.

#include

extern volatile unsigned char pin;

unsigned int t = 1;

unsigned int big_calc(unsigned int x) { unsigned int y = x * x; unsigned int z = sin(x); return sqrt(y * y + 2 * z + 3 * y + 4); }

void foo(void) { pin = 1;

t = big_calc(t);

pin = 0; }

Code generated with -O2 -ffast-math : (The "-ffast-math" lets the compiler use the sqrtsd instruction without checking for a safe operand.)

foo: mov eax, DWORD PTR t[rip] pxor xmm0, xmm0 push rbx mov BYTE PTR pin[rip], 1 cvtsi2sd xmm0, rax mov ebx, eax imul ebx, eax call sin lea eax, [rbx+3] mov BYTE PTR pin[rip], 0 cvttsd2si rdx, xmm0 pxor xmm0, xmm0 imul eax, ebx pop rbx lea eax, [rax+4+rdx*2] cvtsi2sd xmm0, rax sqrtsd xmm0, xmm0 cvttsd2si rax, xmm0 mov DWORD PTR t[rip], eax ret

Look at how much code is moved /after/ "pin = 0" is executed.

The "sin" function /may/ have observable behaviour or side-effects that lead to observable behaviour later, such as changing the value of "errno". Thus it must be ordered within the "pin = 1;", "pin = 0;" pair. The rest is re-ordered according to what the scheduler thinks will be most efficient use of the cpu's execution units - there is no need to relate the order to the volatile accesses.

Now, are you still going to deny what I have demonstrated, explained, and quoted from the language standards, or are you going to continue to believe that a volatile access forces an order on everything else?

Reply to
David Brown

That's it, yes. But you don't need an actual pin - make a volatile variable that you set to 0 (or whatever you like), make your calculation depend on reading it. Then write the output of the calculation to a volatile variable.

As Tom said, it's not rocket science - but you /do/ need to put something like this in place if you want reliable timing.

That's not a good idea. "Complex enough" might work on this compiler with these flags, and then fail with a different compiler or different settings. And your "complex enough" expression starts to cause more significant timing issues.

Use the volatile method described above. It is simple, cheap, and guaranteed to work. In my book, that beats complex, expensive, and merely tested to work.

Reply to
David Brown

The compiler isn't playing games with the volatile stuff. It is playing games with all the non-volatile stuff, and it's allowed to do that. Indeed, you /want/ it to do that - that's what optimisation is about.

It can have radical effects on timings and code size - but if it has any effect on program operation and correctness (except when related to timings and size), then the source code is flawed.

Reply to
David Brown

We're talking about embedded code, using _your_ original example. One square root is hardly a big_calculation().

Your square rooting function doesn't do anything useful, because once again its return value is thrown away, and is therefore invisible because it's useless. The compiler may not be smart enough to get rid of it altogether, but otherwise it's just like one of your previous examples.

If you want to get away with running down stupid knuckle-dragger embedded types in an electronics design group, you're really going to have to do better than that.

If one made a silly mistake, and coded something useless like that that could be optimized away, instrumenting it with a pin toggle would show the problem very quickly. That's one way that instrumenting it is useful.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Set the scope to infinite persistance and run over a weekend. 20 billion experiments should be enough.

One nice thing about Zynq is that the cpu-to-fpga-register accesses can be very fast, and don't need a zillion pcb traces between chips.

And a Zynq knows how to boot everything from one plug-in micro SD card.

I have one board with 13 small ARM chips, one manager and 12 isolated channel processors. The channels are LPC1754s that run my ADC/filter/control/DAC loop in an IRQ at 200 KHz. We ran the CPU clocks at 70 MHz to save power. That code was optimized by oscilloscope.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

We have the 4-ch 7 GHz $50K LeCroy box. It does wonderful things that are approximately impossible to figure out how to use.

The HELP was obviously composed by a programmer, or maybe an intern.

My favorite feature on my 500 Mhz Rigol scope is the button DEFAULT SETUP. Just be an oscilloscope, OK?

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

Or an oscilloscope.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

Show me a reference in the C standards where it explains that the ordering rules are different for big calculations and small calculations.

You can't?

You are just desperately trying to avoid learning something new. I don't get that - it really is hard to comprehend. Perhaps you feel you've invested too much in calling my posts BS, and that admitting you were wrong about this would be a blow to your ego.

I am sure I could make a "big" calculation example. When you use a modern compiler with more optimisations, especially link-time optimisation letting it pull in code from all over the place and inline it together, I'm confident I'd see at least some of it moved within the "pin = 1; pin = 0;" pair. But I'm equally confident that any such effort would be wasted on you, as you'd find new reasons to claim it was "toy" or "not big enough".

Again, did you even bother looking at the source code? The result is stored and available for other code - the compiler /can't/ throw it away. Did you look at the generated code? The square root opcode is staring you in the face. It is not invisible or thrown away, because that would be breaking the rules of C.

I don't follow you - are you describing yourself as a stupid knuckle-dragger here? I don't see anyone else in this branch who fails to understand that volatile accesses don't order other code.

One last time. Read the code. Look at the generated result. Nothing is optimised away. But the timing instrumentation does not time the calculation.

Reply to
David Brown

There seems to be a general principle that: - if you are a respected expert in field X - you have some knowledge and experience in field Y - you think you are expert in field Y

In gliding circles that is known as the "doctor syndrome"...

In middle age a successful doctor takes up gliding, becomes solo, becomes a cross country flyer. Then because they have the money and there's nothing stopping them, they buy themselves the biggest baddest glider.

Sooner or later, and despite warnings, they end up dead - because their arrogance couldn't let them admit to themselves that other people knew more.

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.