Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
11/02/06 23:54
Read: times


 
#127289 - Pipelines revisited
Some months ago, there was a brief discussion of the pipelining used in some of the new "one-clockers" that boast realy high speed.

Earlier today, I was told about about a problem with the pipeline in the SiLabs 100-MIPS MCU's that made it work OK with up to eight (?) instructions in a loop but let it fall apart, meaning the critical timing of the loop "broke" when there were more than eight bytes in the loop.

I've been considering using one of the MCU's in this series but can't find enough in the datasheet about the pipeline. That would affect not only the timing of long loops, but also the interrupt response time.

Does anyone have precise and detailed information about this?

I need to know how the pipeline will affect loops with 300+ instructions per loop.

I've noted that the Dallas Semiconductor design used in their Maxim/Dallas DS89C4x0 series, (the '420 and '440 of which are being discontinued, according to their support person) has no such pipelining, though they do indicate they use a 4-stage pipeline, as did the original 805x (I'm not sure about that, but I do seem to recall that figure). This implies that the Dallas parts will execute a long loop faster than the SiLabs parts, despite the fact that the SiLabs parts claims a 10 ns cycle while the Maxim/Dallas parts top out with a 30 ns cycle.

This is heavily dependent on the loop length, however, and that's why I want the precise details.

Any URL's, bits of wisdom?

RE


List of 33 messages in thread
TopicAuthorDate
Pipelines revisited            01/01/70 00:00      
   You cannot say without more information            01/01/70 00:00      
      You've got it! That's the problem, for sure.            01/01/70 00:00      
         Synchronization            01/01/70 00:00      
            True enough, but in this case            01/01/70 00:00      
   So you can be happily chugging away            01/01/70 00:00      
      That renders the SiLabs architecture unuseable            01/01/70 00:00      
         Can't You Trurn it off?            01/01/70 00:00      
         Advertising.            01/01/70 00:00      
            a better term would have been "unspecified"            01/01/70 00:00      
         if what you want is to bitch, the cache stinks, if            01/01/70 00:00      
            No ... it's not just a complaint ...            01/01/70 00:00      
               experience and the other is stated already            01/01/70 00:00      
                  it's not quite that simple ...            01/01/70 00:00      
                     does not matter, in this case an advantage            01/01/70 00:00      
                        Yes, same length, irrespective of path            01/01/70 00:00      
   can you explain more?            01/01/70 00:00      
      It uses a pipeline to achieve the high speed            01/01/70 00:00      
         why pipeline??            01/01/70 00:00      
   branch cache            01/01/70 00:00      
      i dont know about slightly unpredictable            01/01/70 00:00      
      I second this.            01/01/70 00:00      
      It's called "branche cache" rather than pipeline?            01/01/70 00:00      
         They're two different things.            01/01/70 00:00      
            This flush and refill process is what I feared            01/01/70 00:00      
         you might also try something completely different            01/01/70 00:00      
            well ... maybe ...            01/01/70 00:00      
   what is the problem?            01/01/70 00:00      
      The problem is blaming the pipeline ...            01/01/70 00:00      
         oh, I wish            01/01/70 00:00      
         Exactly ...            01/01/70 00:00      
      That reference is helpful            01/01/70 00:00      
         not a "litterary masterpiece" but after reading            01/01/70 00:00      

Back to Subject List