On Fri, 5 Jun 2020 11:40:31 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 05/06/2020 10:54, Phil Hobbs wrote: >> On 2020-06-04 22:58, whit3rd wrote: >>> On Thursday, June 4, 2020 at 9:14:43 AM UTC-7, >>> jla...@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 16:10:35 +0100, Tom Gardner >>>> <spamjunk@blueyonder.co.uk> wrote: >>>> >>>>> On 04/06/20 15:26, David Brown wrote: >>> >>>>>> If someone asked me to make a 5th order polynomial for calibration, >>>>>> I'd say >>>>>> "No.� Let's look at the system and see how to handle it >>>>>> /properly/". �Any >>>>>> polynomial above 3rd order is likely (not guaranteed, but likely) >>>>>> to be wrong - >>>>>> over-fitted, unstable, or both. >>> >>>> The official ITS thermocouple voltage-temperature equations range from >>>> 8th order to 14th order for various thermocouples. We make both >>>> thermocouple acquisition and simulation products. If anyone refused to >>>> implement the ITS equations, of course I'd fire them, for stupidity if >>>> nothing else. >>> >>> But the ITS equations are a temperature scale, that apply to all >>> thermocouples >>> of a type.�� Calibration includes instrument peculiarities that aren't >>> known >>> except after construction of the whole instrument.��� Not >>> all calibrations have continuous, well-behaved functional� nature, >>> but all polynomials do. >>> >>> The general class of calibrations isn't automatically fit to a >>> polynomial. >>> >> >> Any actual thermocouple pair has a well-behaved, gently nonlinear >> characteristic V(T1,T2) that is a good match to any well-designed >> polynomial, spline, or rational-function fit technique.� (You can even >> use rational trig functions, knock yourself out.) >> >> It really isn't rocket science to fit a smooth nonlinearity of at most a >> few tens of percent over a wide temperature range, to any accuracy >> remotely required for temperature measurements. >> >> Of course, if you do the calibration sufficiently badly, you can make >> problems for yourself, but they aren't specifically mathematical problems. >> > >My impression of Whit's post was that the calibration in a real system >might be for compensating for tolerances of bias resistors, parasitic >effects of ESD protection devices, and other board-level effects. The >calibration is likely to remain a smooth function that (unless you've >really made a mess of the hardware), but it may no longer be a good fit >for the polynomial picked by the thermocouple manufacturer. So fitting >to a cubic spline (or other suitable function, as you mentioned) based >on real-life board measurements is going to make more sense than trying >to force usage of the original ITS polynomial. (If you are not basing >it on measurements, it is not calibration.)The ITS polynomials are for thermocouples, not thermistors. There is a simple equation that is usually used for thermistors, https://en.wikipedia.org/wiki/Thermistor#Steinhart%E2%80%93Hart_equation which is plenty good, since thermistors aren't usually very accurate. We typically measure their resistance ratiometrically against a 1% resistor, and use a fairly coarse lookup table with interpolation, generated from the S-H equation. It's useful to seed a PCB with a few surface-mount thermistors, so you can snoop things, close fan loops, shut down, or temperature compensate things. I'm about to ship a new high voltage pulse generator that had very complex voltage/duty-cycle/loading limits. Customers might drive hi-z loads, 50 ohms, a laser stack, or a short. The simple fix was to current limit the power supply and hang a thermistor on the 50 ohm output resistor. Let the resistor do the math for me. RTDs have yet another equation. The reason to use the ITS thermocouple polynomials is that they are basically the definition of temperature, and we don't want to argue with that. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 5, 20202020-06-05
Reply by ●June 5, 20202020-06-05
You're fogging, which is your usual MO when anyone calls you on your BS. In your most recent one, the return value is thrown away, which the compiler of course noticed. These are all toys, not big_calculation()s done for some actual reason other than saving your ass. How about a counterexample using the code I called you on, using actual embedded code with an actual output that gets used for something real? Cheers Phil Hobbs
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 08:49:38 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >> >>>> >>>> That's what I have to do, use an oscilloscope to show programmers what >>>> their code does. You can often relate the pulse widths to paths >>>> through the code. >>>> >>> >>> A scope can be a fine tool for measuring code performance. I like to >>> make sure there are a few test pins on our boards that can be connected >>> to an oscilloscope precisely for measuring critical code. Not all >>> programmers understand how to instrument code for such measurements, >>> unfortunately. >> >> Raise a port pin at the start of the routine, and drop it at the end. >> Maybe invert it a couple of times, at interesting points. > >Yes, it isn't rocket science.I know Fellows of big aerospace companies, software guys, who aren't sure which end of an oscilloscope goes up. They can't estimate runtines within 10:1, so they grossly overkill on compute power. One of them is playing with those raspberry pi things at home. I'm going to send him an oscilloscope.> >If the test point reflects the "idle" time, you can even >put a voltmeter (preferable moving coil!) on it to visualise >the processor utilisation. Dirty, but quick. > > >> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >> One program just toggled a pin as hard as it could, and we looked at >> that on a scope to see how much other things suspended the loop. We'd >> see occasional long highs or lows, "long" being numbers like 20 us. I >> was impressed. The linux periodic interrupt only took a few >> microseconds. > >Did you form an opinion as to what caused the pauses?There was an obvious linux timer IRQ, always there, at 1 KHz as I recall. Things like ethernet activity added less regular timeouts from the hard loop. But the worst stackup that we saw was under 40 us, and rare. Linux, I understand, allows weak suggestion of what to run on which CPU, which we did, and that seemed to help. We didn't research or document this extensively, because it became obvious that we could run our state loops and such plenty often enough, and that we should do some of our math (like summing the means and squares of ADC samples, for RMS) in the FPGA.> >Did the "other stuff" manage/avoid interfering with >the caches?Don't know. We just scoped the gross timeouts. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 10:39:00 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 10:24, Phil Hobbs wrote: >> On 2020-06-05 03:49, Tom Gardner wrote: >>> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>> <david.brown@hesbynett.no> wrote: >>>> >>>> >>>>>> >>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>> their code does. You can often relate the pulse widths to paths >>>>>> through the code. >>>>>> >>>>> >>>>> A scope can be a fine tool for measuring code performance.� I like to >>>>> make sure there are a few test pins on our boards that can be connected >>>>> to an oscilloscope precisely for measuring critical code.� Not all >>>>> programmers understand how to instrument code for such measurements, >>>>> unfortunately. >>>> >>>> Raise a port pin at the start of the routine, and drop it at the end. >>>> Maybe invert it a couple of times, at interesting points. >>> >>> Yes, it isn't rocket science. >>> >>> If the test point reflects the "idle" time, you can even >>> put a voltmeter (preferable moving coil!) on it to visualise >>> the processor utilisation. Dirty, but quick. >>> >>> >>>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >>>> One program just toggled a pin as hard as it could, and we looked at >>>> that on a scope to see how much other things suspended the loop. We'd >>>> see occasional long highs or lows, "long" being numbers like 20 us. I >>>> was impressed. The linux periodic interrupt only took a few >>>> microseconds. >>> >>> Did you form an opinion as to what caused the pauses? >>> >>> Did the "other stuff" manage/avoid interfering with >>> the caches? >> >> 20 microseconds is a long time for a cache miss on a gigahertz processor.� L1 >> cache lines are typically 64 bytes, no? > >In general, there are other caches in various forms, >and there can be many misses. > >I haven't recently checked what's in A9(?) ARMs, nor >how each processor can interfere with the other. > >If I wanted to use a Zynq (and they look like interesting >devices) for hard realtime purposes, then I'd look at >putting a traditional RTOS on one processor and a linux >on the other.There is a Xilinx appnote for implementing linux on one ARM core, and running bare-metal on the other. That's what we'd do if we had to. If we had more than one fast thing to run, we'd do a simple state machine. Even an RTOS has overhead. One could toss a bunch of soft-core processors in the FPGA too, which certain parties are eager to do. Some day we'll just run every process on its own CPU and avoid all that context switching nonsense. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 04:45:44 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 2020-06-05 04:05, David Brown wrote: >> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>> >>>>> >>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>> their code does. You can often relate the pulse widths to paths >>>>> through the code. >>>>> >>>> >>>> A scope can be a fine tool for measuring code performance.� I like to >>>> make sure there are a few test pins on our boards that can be connected >>>> to an oscilloscope precisely for measuring critical code.� Not all >>>> programmers understand how to instrument code for such measurements, >>>> unfortunately. >>> >>> Raise a port pin at the start of the routine, and drop it at the end. >>> Maybe invert it a couple of times, at interesting points. >> >> And how do you know that you are raising it at the /real/ start of the >> routine, and dropping it at the /real/ end of the routine?� I've seen >> people write code like : >> >> ����... >> ����set_pin_hi_macro(); >> ����x = big_calculation(); >> ����set_pin_lo_macro(); >> ����... >> >> without realising that the compiler (and processor, for more advanced >> cpus) can re-order a lot of that and make the timing seriously unrealistic. > >All the embedded stuff I recall doing in C/C++ defines the various port >registers as volatile, so the compiler can't play games like that.Right. If the port was treated as a local variable, both the set and the clear would be optimized out, since they obviously don't do anything. Playing with compiler optimization options can have radical effects. We had one case where it took a lot of experimenting with a c compiler to get it anywhere as fast a runtime as my PowerBasic program. It started down 4:1 and finally got about 80% as fast. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 12:26:53 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 11:12, David Brown wrote: >> On 05/06/2020 10:45, Phil Hobbs wrote: >>> On 2020-06-05 04:05, David Brown wrote: >>>> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >>>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>>> <david.brown@hesbynett.no> wrote: >>>>> >>>>> >>>>>>> >>>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>>> their code does. You can often relate the pulse widths to paths >>>>>>> through the code. >>>>>>> >>>>>> >>>>>> A scope can be a fine tool for measuring code performance.� I like to >>>>>> make sure there are a few test pins on our boards that can be connected >>>>>> to an oscilloscope precisely for measuring critical code.� Not all >>>>>> programmers understand how to instrument code for such measurements, >>>>>> unfortunately. >>>>> >>>>> Raise a port pin at the start of the routine, and drop it at the end. >>>>> Maybe invert it a couple of times, at interesting points. >>>> >>>> And how do you know that you are raising it at the /real/ start of the >>>> routine, and dropping it at the /real/ end of the routine?� I've seen people >>>> write code like : >>>> >>>> �����... >>>> �����set_pin_hi_macro(); >>>> �����x = big_calculation(); >>>> �����set_pin_lo_macro(); >>>> �����... >>>> >>>> without realising that the compiler (and processor, for more advanced cpus) >>>> can re-order a lot of that and make the timing seriously unrealistic. >>> >>> All the embedded stuff I recall doing in C/C++ defines the various port >>> registers as volatile, so the compiler can't play games like that. >>> >> >> That's the common misunderstanding. >> >> "volatile" tells the compiler (but not the processor, write buffers, cache, >> memory buffers, or any other hardware) that this particular access can't be >> omitted or re-ordered with respect to other volatile accesses or "observable >> behaviour". >> >> But it says /nothing/ about re-ordering with respect to non-observable >> behaviour, such as calculations. >> >> Supposing you want to find out how much time your cpu takes for a multiply >> instruction.� You might write code like this: >> >> >> // Obviously this would match a real register address >> extern volatile unsigned char pin; >> >> extern unsigned int testresult; >> >> void testmults(void) { >> ��� pin = 1; >> >> ��� unsigned int t = 1; >> ��� for (unsigned int x = 1; x <= 1000; x++) { >> ������� t *= x; >> ��� } >> >> ��� pin = 0; >> >> ��� testresult = t; >> } >> >> Set the pin high - it's a volatile access, and the compiler can't omit it or >> reorder it.� Do the calculations.� Set the pin low.� What can go wrong?� You've >> been smart enough to "use" the calculation result, so that the compiler doesn't >> remove the loop entirely.� (Not every programmer would think of that.) >> >> The compiler is free to re-organise this code in any way it wants, as long as >> pin is set to 1 before it is set to 0, and as long as "testresult" gets the >> right value in the end. >> >> It can generate code equivalent to: >> >> void testmults(void) { >> ��� pin = 1; >> ��� pin = 0; >> >> ��� unsigned int t = 1; >> ��� for (unsigned int x = 1; x <= 1000; x++) { >> ������� t *= x; >> ��� } >> >> ��� testresult = t; >> } >> >> or >> >> void testmults(void) { >> ��� testresult = 0;��� // Since that is the answer >> >> ��� pin = 1; >> ��� pin = 0; >> >> } >> >> or all sorts of other possibilities. >> >> The general solution to this is to make sure the calculation depends on an >> initial volatile read, and the result is used in a volatile write - that lets >> you control where the calculation is done with respect to the volatile pin >> control.� So you could use: >> >> static const volatile unsigned int vol_one = 1; >> static volatile unsigned int vol_result; >> void testmults(void) { >> ��� pin = 1; >> >> ��� unsigned int t = vol_one; >> ��� for (unsigned int x = 1; x <= 1000; x++) { >> ������� t *= x; >> ��� } >> ��� vol_result = t; >> >> ��� pin = 0; >> >> ��� testresult = t; >> } >> >> (It is possible to enforce orderings without needing extra memory reads and >> writes or instructions using empty gcc inline assembly in careful ways.) >> >> >> Do compilers do this kind of re-arrangement in practice?� Yes, they do - but >> usually only if there is a good reason for it.� I've certainly seen bits of >> "measured" code re-arranged with respect to the instrumentation. >> >> The same problem also occurs with interrupt-disable code.� A well-established >> example can be seen here: >> >> <https://www.nongnu.org/avr-libc/user-manual/optimization.html> >> >> Here, the original author had thought that a "memory barrier" would solve any >> such re-arrangement problems - but the example shows it is not the case. >> >> >> And that's all just for the compiler's viewpoint.� Hardware can have a big >> effect (I'm sure you can imagine) - are you measuring the calculation time, or >> the cache miss time, or is the time dependent on the state of the write-back >> buffers?� Usually the solution there is to do lots of samples so you have an >> average timing. >> >> >>> How would you ever make embedded code work if the compiler could randomly >>> optimize away or reorder port accesses?� You could never even poll a hardware >>> flag. >>> >> >> The compiler can't re-order the volatile parts - but it can re-order everything >> else.� A very common misunderstanding about volatile is that people often think >> volatile accesses also order other code and accesses - they do not.� (C11/C++11 >> atomic accesses can affect the order of other memory accesses, but not the order >> of code and calculations.) >> > > >Thanks, David. I knew you would have chapter and verse(!) >at your fingertips! > >Such considerations lead me to believe that most programmers >that think they know C, actually don't. > >It also makes me believe that C has become part of the >problem(s) that implementers face. I would prefer it had >remained part of the solution.Yes. One trick is to force a c calculation to include the state of a pin or something external, in a way that can't be optimized out. *We* know that the pin is always low, because we soldered it to ground. Or write an expression that is complex enough that the compiler can't figure out how to optimize it away; create a handy dirty variable. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 08:58:15 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 04/06/20 21:08, John Larkin wrote: >> On Thu, 4 Jun 2020 21:43:14 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >>> >>> All sorts of things make it difficult to calculate accurately the run >>> time of non-trivial code. You might be able to make some rough >>> estimates, but generally measurement is better. >> >> That's what I have to do, use an oscilloscope to show programmers what >> their code does. You can often relate the pulse widths to paths >> through the code. > >I've used analogous techniques in telecoms applications >running in both and out of JAIN servers and. It was >great for: > - astounding people at how fast/efficient my design > strategy and code was compared with their previous > products > - demonstrating to other companies exactly where their > code was faulty > - thus avoiding CEOs and lawyers becoming involved :) > >The biggest problem was getting softies to understand >why the mean value is so crude, and that a 95% value >was much more useful.Set the scope to infinite persistance, and run overnight. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On 05/06/20 14:50, jlarkin@highlandsniptechnology.com wrote:> On Fri, 5 Jun 2020 10:39:00 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 05/06/20 10:24, Phil Hobbs wrote: >>> On 2020-06-05 03:49, Tom Gardner wrote: >>>> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >>>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>>> <david.brown@hesbynett.no> wrote: >>>>> >>>>> >>>>>>> >>>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>>> their code does. You can often relate the pulse widths to paths >>>>>>> through the code. >>>>>>> >>>>>> >>>>>> A scope can be a fine tool for measuring code performance. I like to >>>>>> make sure there are a few test pins on our boards that can be connected >>>>>> to an oscilloscope precisely for measuring critical code. Not all >>>>>> programmers understand how to instrument code for such measurements, >>>>>> unfortunately. >>>>> >>>>> Raise a port pin at the start of the routine, and drop it at the end. >>>>> Maybe invert it a couple of times, at interesting points. >>>> >>>> Yes, it isn't rocket science. >>>> >>>> If the test point reflects the "idle" time, you can even >>>> put a voltmeter (preferable moving coil!) on it to visualise >>>> the processor utilisation. Dirty, but quick. >>>> >>>> >>>>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >>>>> One program just toggled a pin as hard as it could, and we looked at >>>>> that on a scope to see how much other things suspended the loop. We'd >>>>> see occasional long highs or lows, "long" being numbers like 20 us. I >>>>> was impressed. The linux periodic interrupt only took a few >>>>> microseconds. >>>> >>>> Did you form an opinion as to what caused the pauses? >>>> >>>> Did the "other stuff" manage/avoid interfering with >>>> the caches? >>> >>> 20 microseconds is a long time for a cache miss on a gigahertz processor. L1 >>> cache lines are typically 64 bytes, no? >> >> In general, there are other caches in various forms, >> and there can be many misses. >> >> I haven't recently checked what's in A9(?) ARMs, nor >> how each processor can interfere with the other. >> >> If I wanted to use a Zynq (and they look like interesting >> devices) for hard realtime purposes, then I'd look at >> putting a traditional RTOS on one processor and a linux >> on the other. > > There is a Xilinx appnote for implementing linux on one ARM core, and > running bare-metal on the other. That's what we'd do if we had to. If > we had more than one fast thing to run, we'd do a simple state > machine. Even an RTOS has overhead. > > One could toss a bunch of soft-core processors in the FPGA too, which > certain parties are eager to do.OK for some limited things, but an ARM+i/o+FPGA is an more general and more appealing concept to me.> Some day we'll just run every process on its own CPU and avoid all > that context switching nonsense.Some day? *I do /precisely/ that right now*. It is *precisely* the concept behind and implementation of the XMOS xCORE processors, programmed in xC (think Occam or CSP, or some of the CSP concepts appearing in Rust and golang), within a standard IDE. It works, is easy and *fun*. A *much* lower learning curve than Vivado. To kick the tyres of the concepts I had - one core counting the transitions on an input serial stream, - another doing the same on a different stream, - one core for the front panel, - several cores communicating over USB with a PC (could have been ethernet) - one core for a supervisory FSM coordinating all the above Hard realtime *guarantees* not to miss any transitions, nor comms, etc. The IDE inspects the optimised binary to calculate precise timing. None of this "measure and hope" crap :) IDE is free, buy the processors and dev boards at DigiKey.
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 08:15:42 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 02:47, Bill Sloman wrote: >> Feynman was ingenious, which is to say he did unexpected things that worked. > >I liked his metaphor of having different tools in his >toolbox, which he could whip out and use on other >people's problems. > > >> John Larkin likes to think that the unexpected aspect is crucial. > >Crucial? Not usually.Design is generating the unexpected. It pays better than copying. It's my impression that coders rarely invent anything. Hardware designers often do. Where's the electronics that you were going to post? -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Friday, June 5, 2020 at 9:50:47 AM UTC-4, jla...@highlandsniptechnology.com wrote:> On Fri, 5 Jun 2020 10:39:00 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > > >On 05/06/20 10:24, Phil Hobbs wrote: > >> On 2020-06-05 03:49, Tom Gardner wrote: > >>> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: > >>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown > >>>> <david.brown@hesbynett.no> wrote: > >>>> > >>>> > >>>>>> > >>>>>> That's what I have to do, use an oscilloscope to show programmers what > >>>>>> their code does. You can often relate the pulse widths to paths > >>>>>> through the code. > >>>>>> > >>>>> > >>>>> A scope can be a fine tool for measuring code performance. I like to > >>>>> make sure there are a few test pins on our boards that can be connected > >>>>> to an oscilloscope precisely for measuring critical code. Not all > >>>>> programmers understand how to instrument code for such measurements, > >>>>> unfortunately. > >>>> > >>>> Raise a port pin at the start of the routine, and drop it at the end. > >>>> Maybe invert it a couple of times, at interesting points. > >>> > >>> Yes, it isn't rocket science. > >>> > >>> If the test point reflects the "idle" time, you can even > >>> put a voltmeter (preferable moving coil!) on it to visualise > >>> the processor utilisation. Dirty, but quick. > >>> > >>> > >>>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. > >>>> One program just toggled a pin as hard as it could, and we looked at > >>>> that on a scope to see how much other things suspended the loop. We'd > >>>> see occasional long highs or lows, "long" being numbers like 20 us. I > >>>> was impressed. The linux periodic interrupt only took a few > >>>> microseconds. > >>> > >>> Did you form an opinion as to what caused the pauses? > >>> > >>> Did the "other stuff" manage/avoid interfering with > >>> the caches? > >> > >> 20 microseconds is a long time for a cache miss on a gigahertz processor. L1 > >> cache lines are typically 64 bytes, no? > > > >In general, there are other caches in various forms, > >and there can be many misses. > > > >I haven't recently checked what's in A9(?) ARMs, nor > >how each processor can interfere with the other. > > > >If I wanted to use a Zynq (and they look like interesting > >devices) for hard realtime purposes, then I'd look at > >putting a traditional RTOS on one processor and a linux > >on the other. > > There is a Xilinx appnote for implementing linux on one ARM core, and > running bare-metal on the other. That's what we'd do if we had to. If > we had more than one fast thing to run, we'd do a simple state > machine. Even an RTOS has overhead. > > One could toss a bunch of soft-core processors in the FPGA too, which > certain parties are eager to do. > > Some day we'll just run every process on its own CPU and avoid all > that context switching nonsense.Bingo! That's the idea behind the GA144 with 144 processors and FPGAs in general where every assignment outside of a process is a parallel task which can have its own private processor... a set of gates and/or FFs. I try to explain to people why FPGAs are easy to design and it often goes over their heads because of the FUD that has been spread about FPGAs... BIG! POWER HUNGRY! COMPLICATED!!! None of which is true any more than it is about processor chips. -- Rick C. --+- Get 1,000 miles of free Supercharging --+- Tesla referral code - https://ts.la/richard11209
