suggestions on 32-bit dsp

On 4/14/2016 8:14 AM, Roman Rumian wrote:
> Hi,
>
> W dniu 2016-04-14 o 09:31, Randy Yates pisze:
>> rickman <gnuarm@gmail.com> writes:
> (...)
>>>
>>> What *is* your definition of a digital signal processor then?
>>
>> Pretty much how Beckmann defined it on p.11 here:
>>
>>
>> http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf
>>
>>
>> I would say implied is that it is also a microprocessor, with
>> instructions for branching, conditionals, etc., an assembly language, a
>> C compiler available, etc.
>
> a true signal processor has six features:
> 1. Single cycle MAC instruction,
> 2. At least 3 data buses for parallel transfer of next instruction and
> two data operands,
> 3. Local, zero wait states RAMs or RAM blocks,
> 4. Hardware loops mechanism,
> 5. Circular and reverse carry addressing modes,
> 6. High precision result registers with guard bits.
>
> SHARC has all this features, ARMs not (see page 16 in p.Beckman
> presentation).
>
> I love signal processors programming, because can use assembler or
> C/assembler mix, everything is clear and under control, but ...
>
> .... ARM Cortex-M and -A microcontrollers are cheap, have excellent
> software tools (many of them are for free), the program code is safe in
> internal flash memory, have enough DSP power for stereo and even 5.1
> channels applications, and ARM-Cortex A15 (and higher) have 3x bigger
> power than SHARC.
> 24-bit fractional numbers comfortably fit 32-bit words and 64-bit result
> has 16 guard bits.
>
> The only problem with ARMs is the lack of fifth feature, and CMSIS
> library DSP functions are not optimal.
>
> The new, six generation SHARC is SoC having two DSP cores and ARM
> Cortex-A5. :-)

As much as anything, that is a reflection of the ability to include ever 
more transistors on a chip with little use for them other than to build 
more processors.

I believe there are a number of ARM CPU chips which include 
co-processors which can do DSP.  I know the Beagle Bone Black has such a 
chip.  I guess ADI sees which way the wind is blowing.  I wonder if DSP 
chips will be around much longer.  They have disappeared from cell 
phones by being swallowed into the SoC which is mostly a high level ARM.

I guess they still use DSP chips in cell base stations.  I believe they 
use more MCU-like DSP in "white" goods and various motor control apps. 
Where else are they used in high volume still?

-- 

Rick

On Thu, 14 Apr 2016 14:14:56 +0200, Roman Rumian
<rumian_usun_to@agh.edu.pl> wrote:

>Hi,
>
>W dniu 2016-04-14 o 09:31, Randy Yates pisze:
>> rickman <gnuarm@gmail.com> writes:
>(...)
>>>
>>> What *is* your definition of a digital signal processor then?
>>
>> Pretty much how Beckmann defined it on p.11 here:
>>
>>    http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf
>>
>> I would say implied is that it is also a microprocessor, with
>> instructions for branching, conditionals, etc., an assembly language, a
>> C compiler available, etc.
>
>a true signal processor has six features:
>1. Single cycle MAC instruction,
>2. At least 3 data buses for parallel transfer of next instruction and 
>two data operands,
>3. Local, zero wait states RAMs or RAM blocks,
>4. Hardware loops mechanism,
>5. Circular and reverse carry addressing modes,
>6. High precision result registers with guard bits.
>
>SHARC has all this features, ARMs not (see page 16 in p.Beckman 
>presentation).

Pretty close, though.   One can always use definitions or specsmanship
to isolate something, but really what you want to know is whether
something will be effective or not within the project constraints and
costs.   This can take into account total parts cost, power
consumption, etc., etc., and all those things differ with each
project.

The trend, though, is that parts like ARM-based SoCs, are providing an
awful lot of bang for the buck, and while they may not meet all of
your criteria above, they are pretty efficient and bring a lof of
other things to the table that one may need on a project.

e.g., with a BBB or a Pi you can run your DSP app reasonably
efficiently on the same processor as a Linux app that may be using the
results.    So you can co-develop, on the same low-cost platform, with
other apps collaboratively, as well as make native use of the broader
field of Linux tools/apps (or other OSs) that also live on the
platform.   Likewise, both those platforms have native Ethernet and
USB ports, etc., etc., driven from the same low-cost SoC.   This is
not insignificant, and the economic trend is pretty clear to see.

I think there will continue to be niches for DSPs, but they seem to be
getting smaller.

>I love signal processors programming, because can use assembler or 
>C/assembler mix, everything is clear and under control, but ...
>
>... ARM Cortex-M and -A microcontrollers are cheap, have excellent 
>software tools (many of them are for free), the program code is safe in 
>internal flash memory, have enough DSP power for stereo and even 5.1 
>channels applications, and ARM-Cortex A15 (and higher) have 3x bigger 
>power than SHARC.
>24-bit fractional numbers comfortably fit 32-bit words and 64-bit result 
>has 16 guard bits.
>
>The only problem with ARMs is the lack of fifth feature, and CMSIS 
>library DSP functions are not optimal.

One issue is that the GPU cores differ from vendor to vendor on the
SoCs.   This creates a bit of a barrier to somebody creating a gnarly
DSP library that is easily accessible and runs on the GPU core.   The
NEON has a lot of fans, but making a DSP library for it easily
accessible doesn't seem to be there yet.   I suspect it may be before
too long, though.

>The new, six generation SHARC is SoC having two DSP cores and ARM 
>Cortex-A5. :-)

That'll help, but I'm not sure it'll be enough.

>Regards
>
>Roman
>
>
>

On Thu, 14 Apr 2016 13:20:54 -0400, rickman <gnuarm@gmail.com> wrote:

>On 4/14/2016 3:31 AM, Randy Yates wrote:
>> rickman <gnuarm@gmail.com> writes:
>>
>>> On 4/13/2016 3:33 PM, Randy Yates wrote:
>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>>
>>>>> On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates wrote:
>>>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>>
>>>>>>> problem is with the Sigma is that it's too much like an FPGA or some
>>>>>>> hardware solution. no branch instruction or conditional branch
>>>>>>> instruction. so you can't really process samples in blocks and you
>>>>>>> can't have processing modes like you need to efficiently do processing
>>>>>>> alongside analysis. like what happens in a pitch shifter.
>>>>>>
>>>>>> I've heard of that device but didn't know all this about it. I still
>>>>>> prefer the cozy familiarity of a DSP.
>>>>>
>>>>> well, it *is* a DSP, it's just that all of the instructions are
>>>>> inline.
>>>>
>>>> In my book that's not a DSP. If you want to call it one, then we'll have
>>>> to disagree. It is a device that performs digital signal processing, but
>>>> it's not a "digital signal processor" in the classical sense (IMO).
>>>
>>> What *is* your definition of a digital signal processor then?
>>
>> Pretty much how Beckmann defined it on p.11 here:
>>
>>    http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf
>>
>> I would say implied is that it is also a microprocessor, with
>> instructions for branching, conditionals, etc., an assembly language, a
>> C compiler available, etc.
>
>"The Test:  Can you do an FIR filter in roughly 1 cycle/tap?"
>
>I thought the ARM CM4 and higher would pass this test?  Do I have it wrong?
>-- 
>
>Rick

I'll challenge the premiss of the test.

The test:  can you do the FIR filter and meet throughput for the
lowest cost and power consumption?

I don't think people will care how many cycles it takes if the cost
and power are lower.   The test you cite is from the days when clock
frequency was hard to attain without adding a lot of cost, now we have
$3 cores with tons of integrated peripherals and multiple CPUs that
run at 1.2GHz.    If that gets the job done "better" (in the context
of the project) than a machine with a single-cycle MAC, you probably
ought to go that way.

On 4/14/2016 3:18 PM, Eric Jacobsen wrote:
> On Thu, 14 Apr 2016 13:20:54 -0400, rickman <gnuarm@gmail.com> wrote:
>
>> On 4/14/2016 3:31 AM, Randy Yates wrote:
>>> rickman <gnuarm@gmail.com> writes:
>>>
>>>> On 4/13/2016 3:33 PM, Randy Yates wrote:
>>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>>>
>>>>>> On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates wrote:
>>>>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>>>
>>>>>>>> problem is with the Sigma is that it's too much like an FPGA or some
>>>>>>>> hardware solution. no branch instruction or conditional branch
>>>>>>>> instruction. so you can't really process samples in blocks and you
>>>>>>>> can't have processing modes like you need to efficiently do processing
>>>>>>>> alongside analysis. like what happens in a pitch shifter.
>>>>>>>
>>>>>>> I've heard of that device but didn't know all this about it. I still
>>>>>>> prefer the cozy familiarity of a DSP.
>>>>>>
>>>>>> well, it *is* a DSP, it's just that all of the instructions are
>>>>>> inline.
>>>>>
>>>>> In my book that's not a DSP. If you want to call it one, then we'll have
>>>>> to disagree. It is a device that performs digital signal processing, but
>>>>> it's not a "digital signal processor" in the classical sense (IMO).
>>>>
>>>> What *is* your definition of a digital signal processor then?
>>>
>>> Pretty much how Beckmann defined it on p.11 here:
>>>
>>>     http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf
>>>
>>> I would say implied is that it is also a microprocessor, with
>>> instructions for branching, conditionals, etc., an assembly language, a
>>> C compiler available, etc.
>>
>> "The Test:  Can you do an FIR filter in roughly 1 cycle/tap?"
>>
>> I thought the ARM CM4 and higher would pass this test?  Do I have it wrong?
>> --
>>
>> Rick
>
> I'll challenge the premiss of the test.
>
> The test:  can you do the FIR filter and meet throughput for the
> lowest cost and power consumption?

You would need to discuss that with Beckmann or maybe Randy Yates.  I'm 
asking how to apply it and if it is really a good test as well.


> I don't think people will care how many cycles it takes if the cost
> and power are lower.   The test you cite is from the days when clock
> frequency was hard to attain without adding a lot of cost, now we have
> $3 cores with tons of integrated peripherals and multiple CPUs that
> run at 1.2GHz.    If that gets the job done "better" (in the context
> of the project) than a machine with a single-cycle MAC, you probably
> ought to go that way.

I don't know that "cost" and power are the only constraints as well.  A 
hearing aid goes for a lot of money.  I don't think they mind spending a 
lot more than $3 on a DSP if it makes the device a lot smaller.  Then 
there are issues of code development, debugging utility, support, 
availability, etc., etc., etc...  There are *many* issues involved in 
selecting a device for a particular task.

Not sure that is really the same as defining what a DSP is.  In fact, 
that seems to *be* the point.  Beckmann is saying that there are many 
ways to skin a processing cat, but if you want to call your choice a 
DSP, it needs specific features.  I don't agree with that myself.  A 
rose by any other name...

-- 

Rick

On Thu, 14 Apr 2016 13:19:20 -0400, rickman wrote:

> On 4/14/2016 6:06 AM, Allan Herriman wrote:
>> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>>
>> [snip]
>>> "High Reliability" is mentioned a lot in the various info, but I don't
>>> see any features (or many at least) that support this other than ones
>>> added by the chip maker.
>>
>> Oh.  I thought the 'R' stood for Real time, rather than Reliable.  The
>> Cortex-R page doesn't seem to say either way:
>>
>> http://www.arm.com/products/processors/cortex-r/index.php?
tab=Performance
>>
>> "The ARM® Cortex-R® real-time processors offer high-performance
>> computing solutions for embedded systems where reliability, high
>> availability,
>> fault tolerance, maintainability and deterministic real-time responses
>> are essential."
> 
> What processors *aren't* real-time?  For that matter, what processors
> aren't "reliable", etc.?  I am asking what features of the R series make
> them more suitable for any task than others?  As you say, they don't
> seem to give much insight.

When the Pentium-class chips came out the consensus among the real-time 
community was that they shouldn't be considered "real time", or at least 
should be considered very problematical to work with because the amount 
of time it takes to flush the pipeline on an interrupt is not 
deterministic within the maximum time, and it's hard to find the maximum 
time by calculation.

Since "real time", by definition, means being able to assign a maximum 
duration between an external event and the processor's response, this 
made sense to me.

I haven't had problems with the Cortex M processors, but then, my "real 
time" needs don't succeed or fail on a few processor instruction cycles.

-- 
www.wescottdesign.com

On 4/14/2016 4:50 PM, Tim Wescott wrote:
> On Thu, 14 Apr 2016 13:19:20 -0400, rickman wrote:
>
>> On 4/14/2016 6:06 AM, Allan Herriman wrote:
>>> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>>>
>>> [snip]
>>>> "High Reliability" is mentioned a lot in the various info, but I don't
>>>> see any features (or many at least) that support this other than ones
>>>> added by the chip maker.
>>>
>>> Oh.  I thought the 'R' stood for Real time, rather than Reliable.  The
>>> Cortex-R page doesn't seem to say either way:
>>>
>>> http://www.arm.com/products/processors/cortex-r/index.php?
> tab=Performance
>>>
>>> "The ARM® Cortex-R® real-time processors offer high-performance
>>> computing solutions for embedded systems where reliability, high
>>> availability,
>>> fault tolerance, maintainability and deterministic real-time responses
>>> are essential."
>>
>> What processors *aren't* real-time?  For that matter, what processors
>> aren't "reliable", etc.?  I am asking what features of the R series make
>> them more suitable for any task than others?  As you say, they don't
>> seem to give much insight.
>
> When the Pentium-class chips came out the consensus among the real-time
> community was that they shouldn't be considered "real time", or at least
> should be considered very problematical to work with because the amount
> of time it takes to flush the pipeline on an interrupt is not
> deterministic within the maximum time, and it's hard to find the maximum
> time by calculation.
>
> Since "real time", by definition, means being able to assign a maximum
> duration between an external event and the processor's response, this
> made sense to me.

Pipelines can cause a large jitter in the time to execute a section of 
code, but they do not prevent an upper limit from being established. 
Does this really make sense to you?  I don't know of any processors 
which can not be assigned a maximum duration for a response.  You can 
always write code that turns off a given interrupt which means there 
will never be a response, is that what you mean?


> I haven't had problems with the Cortex M processors, but then, my "real
> time" needs don't succeed or fail on a few processor instruction cycles.

I prefer processors with a 1 clock cycle response time.  I also like 
processors that only take 1 clock cycle to perform the response task.  :)

-- 

Rick

On Thu, 14 Apr 2016 17:52:28 -0400, rickman wrote:

> On 4/14/2016 4:50 PM, Tim Wescott wrote:
>> On Thu, 14 Apr 2016 13:19:20 -0400, rickman wrote:
>>
>>> On 4/14/2016 6:06 AM, Allan Herriman wrote:
>>>> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>>>>
>>>> [snip]
>>>>> "High Reliability" is mentioned a lot in the various info, but I
>>>>> don't see any features (or many at least) that support this other
>>>>> than ones added by the chip maker.
>>>>
>>>> Oh.  I thought the 'R' stood for Real time, rather than Reliable. 
>>>> The Cortex-R page doesn't seem to say either way:
>>>>
>>>> http://www.arm.com/products/processors/cortex-r/index.php?
>> tab=Performance
>>>>
>>>> "The ARM® Cortex-R® real-time processors offer high-performance
>>>> computing solutions for embedded systems where reliability, high
>>>> availability,
>>>> fault tolerance, maintainability and deterministic real-time
>>>> responses are essential."
>>>
>>> What processors *aren't* real-time?  For that matter, what processors
>>> aren't "reliable", etc.?  I am asking what features of the R series
>>> make them more suitable for any task than others?  As you say, they
>>> don't seem to give much insight.
>>
>> When the Pentium-class chips came out the consensus among the real-time
>> community was that they shouldn't be considered "real time", or at
>> least should be considered very problematical to work with because the
>> amount of time it takes to flush the pipeline on an interrupt is not
>> deterministic within the maximum time, and it's hard to find the
>> maximum time by calculation.
>>
>> Since "real time", by definition, means being able to assign a maximum
>> duration between an external event and the processor's response, this
>> made sense to me.
> 
> Pipelines can cause a large jitter in the time to execute a section of
> code, but they do not prevent an upper limit from being established.
> Does this really make sense to you?  I don't know of any processors
> which can not be assigned a maximum duration for a response.  You can
> always write code that turns off a given interrupt which means there
> will never be a response, is that what you mean?
> 
I hear what you're saying, so I'm not sure exactly why folks were 
reluctant to consider the Intel chips to be "real time" unless Intel just 
wasn't coming forward with the value of that upper limit.
> 
>> I haven't had problems with the Cortex M processors, but then, my "real
>> time" needs don't succeed or fail on a few processor instruction
>> cycles.
> 
> I prefer processors with a 1 clock cycle response time.  I also like
> processors that only take 1 clock cycle to perform the response task. 
> :)

Well, yes.  But you can't do that even with an FPGA in a lot of cases.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 4/14/2016 6:55 PM, Tim Wescott wrote:
> On Thu, 14 Apr 2016 17:52:28 -0400, rickman wrote:
>
>> On 4/14/2016 4:50 PM, Tim Wescott wrote:
>>> On Thu, 14 Apr 2016 13:19:20 -0400, rickman wrote:
>>>
>>>> On 4/14/2016 6:06 AM, Allan Herriman wrote:
>>>>> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>>>>>
>>>>> [snip]
>>>>>> "High Reliability" is mentioned a lot in the various info, but I
>>>>>> don't see any features (or many at least) that support this other
>>>>>> than ones added by the chip maker.
>>>>>
>>>>> Oh.  I thought the 'R' stood for Real time, rather than Reliable.
>>>>> The Cortex-R page doesn't seem to say either way:
>>>>>
>>>>> http://www.arm.com/products/processors/cortex-r/index.php?
>>> tab=Performance
>>>>>
>>>>> "The ARM® Cortex-R® real-time processors offer high-performance
>>>>> computing solutions for embedded systems where reliability, high
>>>>> availability,
>>>>> fault tolerance, maintainability and deterministic real-time
>>>>> responses are essential."
>>>>
>>>> What processors *aren't* real-time?  For that matter, what processors
>>>> aren't "reliable", etc.?  I am asking what features of the R series
>>>> make them more suitable for any task than others?  As you say, they
>>>> don't seem to give much insight.
>>>
>>> When the Pentium-class chips came out the consensus among the real-time
>>> community was that they shouldn't be considered "real time", or at
>>> least should be considered very problematical to work with because the
>>> amount of time it takes to flush the pipeline on an interrupt is not
>>> deterministic within the maximum time, and it's hard to find the
>>> maximum time by calculation.
>>>
>>> Since "real time", by definition, means being able to assign a maximum
>>> duration between an external event and the processor's response, this
>>> made sense to me.
>>
>> Pipelines can cause a large jitter in the time to execute a section of
>> code, but they do not prevent an upper limit from being established.
>> Does this really make sense to you?  I don't know of any processors
>> which can not be assigned a maximum duration for a response.  You can
>> always write code that turns off a given interrupt which means there
>> will never be a response, is that what you mean?
>>
> I hear what you're saying, so I'm not sure exactly why folks were
> reluctant to consider the Intel chips to be "real time" unless Intel just
> wasn't coming forward with the value of that upper limit.
>>
>>> I haven't had problems with the Cortex M processors, but then, my "real
>>> time" needs don't succeed or fail on a few processor instruction
>>> cycles.
>>
>> I prefer processors with a 1 clock cycle response time.  I also like
>> processors that only take 1 clock cycle to perform the response task.
>> :)
>
> Well, yes.  But you can't do that even with an FPGA in a lot of cases.

Really?  You mean within an arbitrarily short clock time?  No, there is 
no technology that lets you do unlimited computing in an infinitely 
short time.  But I stand by the 1 clock statement, in fact, NO clock is 
required.  Combinatorial logic will work fine for many tasks, especially 
computations.

-- 

Rick

On Thu, 14 Apr 2016 19:14:10 -0400, rickman wrote:

> On 4/14/2016 6:55 PM, Tim Wescott wrote:
>> On Thu, 14 Apr 2016 17:52:28 -0400, rickman wrote:
>>
>>> On 4/14/2016 4:50 PM, Tim Wescott wrote:
>>>> On Thu, 14 Apr 2016 13:19:20 -0400, rickman wrote:
>>>>
>>>>> On 4/14/2016 6:06 AM, Allan Herriman wrote:
>>>>>> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>>>>>>
>>>>>> [snip]
>>>>>>> "High Reliability" is mentioned a lot in the various info, but I
>>>>>>> don't see any features (or many at least) that support this other
>>>>>>> than ones added by the chip maker.
>>>>>>
>>>>>> Oh.  I thought the 'R' stood for Real time, rather than Reliable.
>>>>>> The Cortex-R page doesn't seem to say either way:
>>>>>>
>>>>>> http://www.arm.com/products/processors/cortex-r/index.php?
>>>> tab=Performance
>>>>>>
>>>>>> "The ARM® Cortex-R® real-time processors offer high-performance
>>>>>> computing solutions for embedded systems where reliability, high
>>>>>> availability,
>>>>>> fault tolerance, maintainability and deterministic real-time
>>>>>> responses are essential."
>>>>>
>>>>> What processors *aren't* real-time?  For that matter, what
>>>>> processors aren't "reliable", etc.?  I am asking what features of
>>>>> the R series make them more suitable for any task than others?  As
>>>>> you say, they don't seem to give much insight.
>>>>
>>>> When the Pentium-class chips came out the consensus among the
>>>> real-time community was that they shouldn't be considered "real
>>>> time", or at least should be considered very problematical to work
>>>> with because the amount of time it takes to flush the pipeline on an
>>>> interrupt is not deterministic within the maximum time, and it's hard
>>>> to find the maximum time by calculation.
>>>>
>>>> Since "real time", by definition, means being able to assign a
>>>> maximum duration between an external event and the processor's
>>>> response, this made sense to me.
>>>
>>> Pipelines can cause a large jitter in the time to execute a section of
>>> code, but they do not prevent an upper limit from being established.
>>> Does this really make sense to you?  I don't know of any processors
>>> which can not be assigned a maximum duration for a response.  You can
>>> always write code that turns off a given interrupt which means there
>>> will never be a response, is that what you mean?
>>>
>> I hear what you're saying, so I'm not sure exactly why folks were
>> reluctant to consider the Intel chips to be "real time" unless Intel
>> just wasn't coming forward with the value of that upper limit.
>>>
>>>> I haven't had problems with the Cortex M processors, but then, my
>>>> "real time" needs don't succeed or fail on a few processor
>>>> instruction cycles.
>>>
>>> I prefer processors with a 1 clock cycle response time.  I also like
>>> processors that only take 1 clock cycle to perform the response task.
>>> :)
>>
>> Well, yes.  But you can't do that even with an FPGA in a lot of cases.
> 
> Really?  You mean within an arbitrarily short clock time?  No, there is
> no technology that lets you do unlimited computing in an infinitely
> short time.  But I stand by the 1 clock statement, in fact, NO clock is
> required.  Combinatorial logic will work fine for many tasks, especially
> computations.

Well, yes, but saying "one clock cycle only I can make it as long as I 
want" is kind of a null statement.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 4/14/2016 8:10 PM, Tim Wescott wrote:
> On Thu, 14 Apr 2016 19:14:10 -0400, rickman wrote:
>
>> On 4/14/2016 6:55 PM, Tim Wescott wrote:
>>> On Thu, 14 Apr 2016 17:52:28 -0400, rickman wrote:
>>>
>>>> On 4/14/2016 4:50 PM, Tim Wescott wrote:
>>>>> On Thu, 14 Apr 2016 13:19:20 -0400, rickman wrote:
>>>>>
>>>>>> On 4/14/2016 6:06 AM, Allan Herriman wrote:
>>>>>>> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>>>>>>>
>>>>>>> [snip]
>>>>>>>> "High Reliability" is mentioned a lot in the various info, but I
>>>>>>>> don't see any features (or many at least) that support this other
>>>>>>>> than ones added by the chip maker.
>>>>>>>
>>>>>>> Oh.  I thought the 'R' stood for Real time, rather than Reliable.
>>>>>>> The Cortex-R page doesn't seem to say either way:
>>>>>>>
>>>>>>> http://www.arm.com/products/processors/cortex-r/index.php?
>>>>> tab=Performance
>>>>>>>
>>>>>>> "The ARM® Cortex-R® real-time processors offer high-performance
>>>>>>> computing solutions for embedded systems where reliability, high
>>>>>>> availability,
>>>>>>> fault tolerance, maintainability and deterministic real-time
>>>>>>> responses are essential."
>>>>>>
>>>>>> What processors *aren't* real-time?  For that matter, what
>>>>>> processors aren't "reliable", etc.?  I am asking what features of
>>>>>> the R series make them more suitable for any task than others?  As
>>>>>> you say, they don't seem to give much insight.
>>>>>
>>>>> When the Pentium-class chips came out the consensus among the
>>>>> real-time community was that they shouldn't be considered "real
>>>>> time", or at least should be considered very problematical to work
>>>>> with because the amount of time it takes to flush the pipeline on an
>>>>> interrupt is not deterministic within the maximum time, and it's hard
>>>>> to find the maximum time by calculation.
>>>>>
>>>>> Since "real time", by definition, means being able to assign a
>>>>> maximum duration between an external event and the processor's
>>>>> response, this made sense to me.
>>>>
>>>> Pipelines can cause a large jitter in the time to execute a section of
>>>> code, but they do not prevent an upper limit from being established.
>>>> Does this really make sense to you?  I don't know of any processors
>>>> which can not be assigned a maximum duration for a response.  You can
>>>> always write code that turns off a given interrupt which means there
>>>> will never be a response, is that what you mean?
>>>>
>>> I hear what you're saying, so I'm not sure exactly why folks were
>>> reluctant to consider the Intel chips to be "real time" unless Intel
>>> just wasn't coming forward with the value of that upper limit.
>>>>
>>>>> I haven't had problems with the Cortex M processors, but then, my
>>>>> "real time" needs don't succeed or fail on a few processor
>>>>> instruction cycles.
>>>>
>>>> I prefer processors with a 1 clock cycle response time.  I also like
>>>> processors that only take 1 clock cycle to perform the response task.
>>>> :)
>>>
>>> Well, yes.  But you can't do that even with an FPGA in a lot of cases.
>>
>> Really?  You mean within an arbitrarily short clock time?  No, there is
>> no technology that lets you do unlimited computing in an infinitely
>> short time.  But I stand by the 1 clock statement, in fact, NO clock is
>> required.  Combinatorial logic will work fine for many tasks, especially
>> computations.
>
> Well, yes, but saying "one clock cycle only I can make it as long as I
> want" is kind of a null statement.

I don't agree that it is a null statement.  Most designers think in 
terms of sequential logic which is often not required.

The point is that all the logic in an FPGA can be designed to work in 
parallel as much as possible.  CPUs are inherently sequential.  In FPGAs 
you can do more stuff in the same amount of time if you can do it in 
parallel.  Not so in CPUs where doing more takes longer.  The advantage 
of CPUs is they use the same hardware for all tasks by time 
multiplexing.  If speed is your problem, time multiplexing is counter 
productive.  That's why for really fast processors, they throw lots of 
parallel logic at it.  Then it gets complex to design and use.

-- 

Rick