Shop OBEX P1 Docs P2 Docs Learn Events
Propeller II update - BLOG - Page 7 — Parallax Forums

Propeller II update - BLOG

1457910223

Comments

  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-08 16:11
    potatohead,

    With just the Test Die and all of the memory bits instantiated (remember I lobotomized them earlier for faster LVS runs), the total memory resources climb to about 12 Gigs when LVS is running.
  • BigFootBigFoot Posts: 259
    edited 2010-10-09 17:41
    Beau,

    Are you still using that dual boot laptop that crashed at UPEW ?

    Russ :)...
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-09 20:51
    BigFoot (aka Russ)

    "Are you still using that dual boot laptop that crashed at UPEW ?" - No, that laptop is more for show and just has a copy of the database for viewing. It's only got 1 Gig of RAM in it, so any overage starts to hash the hard drive.
  • Heater.Heater. Posts: 21,230
    edited 2010-10-10 01:18
    Beau,

    I've always wondered how it is possible that words can, over time, take on a meaning totally opposite to their original.

    Just now I seem to have caught one undergoing the transition transition:

    o·ver·age 1 (omacr.gifprime.gifvschwa.gifr-ibreve.gifj)n.1. An amount, as of money or goods, that is actually on hand and exceeds the listed amount in records or books.
    2. A surplus; an excess.

    In your last post you have used it to describe a situation, the lack of sufficient RAM, where there is a lack of excess or surplus. That is in a totally opposite sense to the original meaning of "overage"

    I'm not getting at you by commenting on this, I just find it fascinating.:)
  • LeonLeon Posts: 7,620
    edited 2010-10-10 03:25
    How about underage? :)
  • Heater.Heater. Posts: 21,230
    edited 2010-10-10 06:56
    Well, I'm closer to overage.

    o·ver·age 2 (omacr.giflprime.gifvschwa.gifr-amacr.gifjprime.gif)adj.1. Beyond the proper or required age.
    2. Older than usual for a particular position or activity.
    3. Too old to be of use or service: an overage vehicle.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-10-10 10:09
    @heater, I do too.

    One that I caught happening in my neck of the wood was "bleached", being used to indicate the coloring of clothes, which is actually the dye process. Bleaching removes color, and after explaining this in detail to a group of middle-schoolers, they simply responded with, "everybody says it this way now".

    They ended up not saying it around me, often pausing to deliberately say "dye" or "dyed" under my watchful eye, knowing full well all of us knew they were gonna go ahead and say "bleached" among their peers.
  • TappermanTapperman Posts: 319
    edited 2010-10-10 14:14
    I was wondering, is there by chance going to be code in the ROM to allow the chip to 'boot' from a breakout 'SD' chip?

    ... Tim
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-10 20:54
    "In your last post you have used it to describe a situation, the lack of sufficient RAM, where there is a lack of excess or surplus. That is in a totally opposite sense to the original meaning of "overage" " - Really? - I think I used it in the right context...

    by your listed definition - "o·ver·age 1 (vr-j)n.1. An amount, as of money or goods, that is actually on hand and exceeds the listed amount in records or books.
    2. A surplus; an excess."


    The listed amount being the 1 Gig of memory that I have on my laptop. If the LVS/DRC requestes more than that, in other words exceeding the listed amount then the requested memory overage in this particular sense is compensated by supplementing hard drive space as virtual memory.


    Ughh!! - trivial details :smilewinkgrin:
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-11 08:43
    Update : 10-11-2010

    I have been working on LVS at the top level off and on all weekend, and there is just one section that I have isolated as being a difficult area. There are basically three sections that I have grouped. The Core, which passes LVS/DRC, the outer pad ring minus 4 pads which passes LVS/DRC, and the remaining 4 pads in the outer pad ring. The last section with the 4 pads still has an issue, but I have at least narrowed down the focus to a relatively small area. I should have more on this later today or tomorrow.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-10-11 08:51
    I find this thread, and everything in it AMAZING.

    Name one other company that has IC engineers collaborating and informing the users of the chip on the detailed status and timeline of the latest chip design? Or letting them see details of the development process! I LOVE IT!
  • KaosKiddKaosKidd Posts: 296
    edited 2010-10-11 09:07
    Yeah, this is so cool!

    KK
  • K2K2 Posts: 691
    edited 2010-10-11 18:19
    It would be great to be at Parallax when the chip comes back from Fab and all the functional blocks are powered up and tested. But this thread is a close second. Many thanks to Parallax for providing/allowing it. Gotta agree with Clocked - it's unprecendented!
  • BigFootBigFoot Posts: 259
    edited 2010-10-17 08:58
    Beau,

    All joking aside, I agree with these guys. It is really cool to learn
    about what it takes to design a complicated chip like the Propeller 2.
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-18 09:05
    Update: 10-18-2010

    Sorry for not posting an update last Friday, I have been buried in bug chasing an LVS problem that took longer than I wanted.

    - LVS is Clean at the Top Test-Die level

    - I ran a Density Check over the weekend (This is about a 24 hour process) and I am addressing some of the areas.

    With another tool it would probably take less time for this operation, but I really don't have a good baseline to compare. The tool we have with Laker is not supposed to be capable of density checks (according to them), however it does allow you to perform a DRC on a defined window or an area of layout. Within the report file it provides statistics on the density of each layer. So awhile ago I wrote a script that will run within Laker and generate a log file with the extracted density information. A Visual Basic program (had to write that too) looks at the log file to generate what you see in the attached image.


    The attached image is a density plot for the various layers within the Test Die. Green indicates that the layer is within the recommended guidelines. Red indicates that there is more than their should be, while blue indicates there is less than there should be. The 'brighter' the Red or Blue, the more in violation it is. Each square represents 100um x 100um square. The LARGE 'yellow' square is what I'm interested in. It represents the accumulative area within a 1500um x 1500um square and must be stepped at 100um within the design. Each stepped 1500um x 1500um square must fall within the recommended guidelines.

    With the exception of the power rings, everything looks pretty good, and even then, the power rings are allowed to have a greater overall density.

    There are a couple of 'cold spots' where I need to add metal, but over all the 'hot spots' average out to within an acceptable range under the 1500um x 1500um window.


    - I still have the ROM bits to populate (with a script)

    - ...And a layer translation form I need to fill out

    - The goal right now is to have a submission by this Wednesday (October 20th)
    1440 x 900 - 393K
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-18 16:59
    Here is another 10-18-2010 update...

    attached are two images...
    1) before any density corrections were applied (NoFill.png)
    2) after density corrections applied (Fill.png)

    In the corner PADs there is a total of 307.2 thousand square microns of FILL-CAP added to the design. This basically is a way to utilize what would otherwise be unused space as decoupling capacitance.
    1280 x 976 - 207K
    1280 x 976 - 241K
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2010-10-18 17:05
    How much capacitance do you squeeze out of such a process?
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-18 17:17
    Bobb Fwed,

    Depends on the capacitors used.... I will get a number back later. Right now my PC's CPU's are tied up. ... you get about 5pF for every 1000 square microns. So About 307pF of decoupling cap, just using the corner pads. On the final Propeller II Chip there will be other techniques using the 'white space' for decoupling cap.

    The type of capacitor that I used, is designed as a 10um x 10um "Unit Cap" where actually it's just a Nmos transistor with the S/D tied together and to GND
    The transistor "Gate" is tied to VDD. The capacitor could be made more dense by adding what are called "Finger Cap" or "Fin Cap" electrically in Parallel and physically stacked on top of the Nmos transistor. The "Finger Cap" are literally close proximity "fingers" of metal on the same plane (same metal) ... If you stagger layers of metal (also with "finger Cap") then the fringe effects of the fingers can increase the capacitor density even further.
  • TubularTubular Posts: 4,620
    edited 2010-10-20 19:42
    Wow, reading this thread you can really feel the momentum. Like a rolling stone, but indeed gathering (n)mos. It sounds like you're getting close, Beau.

    I gather from the screen caps you only get two IO pins to play with initially... lucky we now have 1-pin TV for testing :smilewinkgrin:

    Out of interest, how do they pack the test chips for delivery to you? I am envisaging a metal briefcase with secret combination as commonly used for storing nuclear codes (at least in the movies)
  • william chanwilliam chan Posts: 1,326
    edited 2010-10-20 19:52
    Does this mean that Prop II will not need any external decoupling capacitors?
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-20 21:08
    You have to use common sense. Beau is talking about hundreds of pF. A typical discrete decoupling capacitor (of which there would probably be at least 2) is 0.1uF. That's a 1:1000 ratio.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2010-10-20 21:19
    Are they any hardware multipliers/dividers and floating point operations system inside? That would be better and fun. :)
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2010-10-21 08:22
    Are they any hardware multipliers/dividers and floating point operations system inside? That would be better and fun. :)
    I believe the plan is no floating point, but it will have single-cycle multiply, and multi-cycle divide, with some system to do operations while the circuitry is dividing.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2010-10-21 08:27
    Bobb Fwed wrote: »
    I believe the plan is no floating point, but it will have single-cycle multiply, and multi-cycle divide, with some system to do operations while the circuitry is dividing.

    Hmm I see. The thing that is most wanted is actually single-cycle multiply and divide - like the other DSPIC's mul/div operations.

    Surely, these supports the IEEE-754 standard? :)
  • LeonLeon Posts: 7,620
    edited 2010-10-21 08:48
    The dsPIC doesn't have single-cycle division; division is fast, though.
  • Dr. MarioDr. Mario Posts: 331
    edited 2010-10-21 11:31
    Yeah - dsPIC was made to be even simple (like Propeller I's COG), so that's even cheaper to sell... =P (PIC32 is a bit faster, though, due to pipelined MIPS32 core running at 80MHz.)

    And, I am happy that Propeller II's shaping up well! Wanna to use them in my Dendou Oni supercomputer. ^____^
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-23 22:16
    Update: 10-24-2010

    -> Metal Density is within acceptable range (see attached animation on this progression)

    -> ROM bits (hope to have them complete within the next day or so)

    -> LVS'd entire Test Chip including metal Density Fill and it passes. For those interested it took 15 Gigs of System memory to evaluate the LVS.
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-10-23 22:25
    Great news Beau... Congratulations :smilewinkgrin:
  • Beau SchwabeBeau Schwabe Posts: 6,545
    edited 2010-10-24 01:05
    Anyone want to help? ... for some reason (due to lack of recent sleep) I can't quite get my head around the code.....

    I basically need to do a matrix bit rotation with 512 Bits.

    16 Longs going in (MSL<-->LSL)

    32 Words coming out (MSW<-->LSW)

    here is the rotation...

    Starting with the first Bit, every 16th bit in the 16 Longs becomes a bit in one of the 32 Words

    Each "new Word" is a 1-bit offset of the 16 Longs


    Here is what I have and should be simple, but I'm not convinced it's doing what it is supposed to do... my logic is flawed and I have been staring at it for way to long.

    My suspicion is because the output is either "0" or "F" indicating that the word is not being written properly, but looking at it and running a few tests cases through it, the translation 'appears' to be correct.

    Big Thanks to whomever can find my dumb mistake.
    CON
      _CLKMODE = XTAL1 + PLL16X
      _XINFREQ = 5_000_000
    
    
    
      base = $8000
    
    
    OBJ
        Ser       : "FullDuplexSerial"
    
    
    VAR
    
    long    WordLineOffset
    long    WordLine
    long    PropellerROM
    long    ROM_Word_Column
    long    ROM_Longs
    word    ROM_Word[32]
    
    
    
    PUB ROM_Reader|n
    
        Ser.start(31, 30, 0, 38400)
    
        WordLine := 500                                     'Arbitrary Test location
        
    
        repeat
          ser.tx(1)
          ser.str(string("Propeller ROM Table",13,13))
    
          WordLineOffset := WordLine * 16                   'Calculate WordLine offset
    
    
          ser.str(string("16 Longs of Data from Propeller ROM     MSL <--> LSL",13))
          repeat ROM_Longs from 15 to 0
            PropellerROM := long[ Base + WordLineOffset + ROM_Longs ]   'Read LONG value from Propeller's ROM
    
            ser.hex(PropellerROM,8)
            
            repeat n from 0 to 31
              PropellerROM <-= 1                                        'Rotate The LONG value read from the Propeller
              
              ROM_Word[n] <<= 1
              ROM_Word[n] := ROM_Word[n]|(PropellerROM & 1)
    
    
          ser.str(string(13,13,"512 Bit ROM Wordline after conversion   MSB <--> LSB ",13))        
          repeat ROM_Word_Column from 0 to 31
            ser.hex(ROM_Word[ROM_Word_Column],4)
    
  • Ahle2Ahle2 Posts: 1,178
    edited 2010-10-24 05:22
    I have been testing your code and it seems to be doing what it is supposed to do.
    However, the values at the ROM location just happens to contain the same value for 4 longs in a row and then change for a new value for 4 longs.... etc ... etc... etc...
    That might be the problem. :)
Sign In or Register to comment.