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.
"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.
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 (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.
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.:)
o·ver·age 2 (vr-j)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.
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.
"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.
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.
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!
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!
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)
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.
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.
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)
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.
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.
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.
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. ^____^
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)
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.
Comments
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.
Are you still using that dual boot laptop that crashed at UPEW ?
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.
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 (
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.:)
o·ver·age 2 (
2. Older than usual for a particular position or activity.
3. Too old to be of use or service: an overage vehicle.
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.
... Tim
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:
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.
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!
KK
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.
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)
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.
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.
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)
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?
And, I am happy that Propeller II's shaping up well! Wanna to use them in my Dendou Oni supercomputer. ^____^
-> 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.
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)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.