Getting a later start this evening than I wanted to after dinner, and putting the girls to bed ... right now it's 10pm, I'll probably work until 2:00am ish.
Should have most if not all of the main wiring done tonight or tomorrow.
BTW) evanh , Your Cancel Button actually works!! That's remarkable! I always end up killing the process manually. :-)
"I would like to know what the blocks are if you are permitted to tell us." - I can, this is just the test Die. Starting in the upper left corner and moving counter clockwise you have the COG_RAM, immediately under that (not very big, but packed, you have the DUALPORT_RAM. The large 'square' in the lower left is the HUB_RAM. The smaller 'square' in the lower right is the ROM. Following the outside perimeter at about 3'Oclock is the PLL. Above in the right most upper corner and moving left is the OSC, BOD (Brown Out Detector), and PUD(Power Up Detector).
Under the BOD and OSC are programmable fuses.
Just right of center is where everything is connecting to. Basically a chain of 8 32-bit flip flops with access to D and Q connecting to the inputs and outputs of everything I mentioned above.
32 bits x 8 shift registers x 2 (D & Q) = 512 connections.
Can you tell us how big the COG_RAM, DualPort_RAM, Hub_Ram and ROM are on this test? (I would presume the Cog_Ram is 2KB and the DualPort is 512B or 1024B from what we know). The Cog_Ram is actually Quad Port isn't it? - in order to get 1 clock access instructions the cog will need to fetch I [instr +2], fetch D & S [instr +1], and write R [instr +0] simultaneously.
--> All point to point buss routing in the Die core has been routed!! ... which means I can start the LVSing process and move towards the top level Test Die. (i.e. connecting the IO's)
--> What's involved before LVSing or DRCing? ... to speed up the process I will lobotomize the individual memory bits out of each memory cell. This eliminates over 1 million LVS and DRC checks that have already passed within individual memory blocks.
--> once the 'Die Core' is complete and passes LVS and DRC I can move up to the 'top' test Die level
--> When? ... starting Monday morning
PS - somebody just needs to remind me to put the memory bits back in before we are 'done done' with the Test Die ;-)
I'm having a bit of trouble running here in Debians IceWeasle version of Firefox. Single stepping works OK but just hitting run bogs down and then all my PC's fans fire up as it stresses out the CPU.
The Prop I is about 6mm a side making it 36 Million square microns. However the process used in the Propeller I was 350nm ... In the Propeller II the process used is 180nm. So If the Propeller I were built using 180nm process it would occupy about 1/4 of the space, so it would be slightly smaller than the current test die. But keep in mind, not all devices are scalar between processes, so it's not a direct shrink and really hard to compare the two that way.
As far as transistor count, I don't have a good way to get that info from the Prop I. I will be able to provide that number at a later time from the Prop II
The general flow for layout and getting LVS/DRC to pass when you have lots of memory bits is to...
1) Test the individual memory blocks and make sure that they pass by themselves individually.
2) Backup your database!!
3) lobotomize the bit cells within the memory in layout AND the schematic so that you don't waste the day waiting for the tool to finish LVS/DRC checks. With four memory blocks if you 'just' count the bits, that's a total of 544,768 checks that LVS has to do that essentially you have already done. 1,089,536 if you count DRC. In reality though each bit has at least 6 transistors or more, so 6,537,216 LVS/DRC checks that you can eliminate at least during the initial hookup and checking. ...Ohhh, and each transistor has 4 terminals to evaluate (Source/Drain/Gate/Bulk connection) ... Making that 26,148,864 LVS/DRC checks that you can temporarily eliminate.
4) Once the LVS/DRC passes with the lobotomized memory versions, substitute in the real deal and run a final 'sanity check' LVS/DRC with all bits in place.
A number of people have talked about a DIP-type adapter, primarily for breadboard use. Parallax has mentioned that they would have something like that available and other board providers have mentioned that they would make something like that.
The question is "what do you mean by DIP adapter?". Do you want a subset of the pins to be available to keep the adapter's pin count reasonable or do you want something that would make all the pins available? Both choices have their advantages and disadvantages. Do you mean a bare chip adapter or a module like the PropStick with some basic support circuitry included? Remember that the Prop II will need two power supply voltages.
Given the discussion to date, I suspect that there will be a variety of modules available.
There will certainly be a breadboard-able solution available, but it's going to be more expensive then a real DIP because of the assembly costs. My bet is on something like the Prop Stick, with support circuitry, xtal, etc.
It has been said by many people including the Gracey's that the Prop I will be available and used for a long time after the Prop II is available. They are different devices with overlapping applications. The Prop I is smaller, has fewer pins, and is cheaper to make and use (only 3.3V needed). Most importantly, it can idle at much much lower power levels than the Prop II. The process used to make the Prop II is inherently leakier than that used by the Prop I. The Prop II also needs two power supply voltages and the extra regulator will waste some power. Most battery powered applications will use a Prop I unless the speed and I/O capacity of the Prop II is absolutely necessary.
Why does it need two supplies? Is that a consequence of using a different process?
The newer faster semiconductor processes require a low voltage for the fast stuff in the core (1.8V or 1V are common) to minimise heating and power consumption, and just use 3.3V for the output drivers. It's not much of a problem as dual-output switchers are made by Linear and are often used with other chips with dual power supplies. A couple of linear regulators might do.
Well, at first I envisioned something that would talk all the pins and move them into headers. But, now that you bring it up and I think about it, a Propeller II development board, with some basic hardware and some through hole connectors (for direct plug in to bread boards) or header's for wire-outs to a bread board would more then likely be the best answer.
I just think the ability to bring all the pins out to the development part of the board, so that any attached hardware (like ps2 ports or eeproms) can be avoided (as in not connected) and reconstructed on the bread board environment.
Any ideas how much the propeller language is going to change, if it does at all?
Nobody really knows. The hardware isn't even finished. We don't know what the new instructions will look like or how some of the new hardware will be controlled.
You can be certain that most things will be unchanged and that some of the new capabilities will look very much like the existing ones. There will still be special registers and some things will be accessed by using statements that look like method calls.
There may be some "compatibility" functions that look like current statements, but may use some other mechanism to provide the same functionality. These are all techniques used many times in the past when a new model processor is developed, only slightly different from the old one, and there's a large existing code base.
I see. Not bad, as we may be able to program Propeller II with that Propeller I instructions in Propeller Tools. However, it would still require rewriting the whole affairs, or just recompile in Prop Tool, so you won't have a paperweight doing nothing but being stuck in NOP loop (failed execution).
And, some people said that the setup to feed 1.8V is a waste of power. Not always. See, 5 Amps of 12 V in the computer is wholly used to.... Create 96 AMPS(!!) of 1.2 V for your x86 CPU to happily munch on, so that way you can even view this webpage without CPU's voltage dropout mechanism getting all too moody. (Did that experiment - very interesting.. But I did that on tossed-out motherboard as it's very risky.)
Therefore, try to use the effecient voltage regulator - like switching regulator, so it won't eat extra ampere in the process. But please put 100uF 4V low-ESR capacitor on the output of your switching regulator so you won't have to deal with your Propeller II behaving funny.
For all of you guys out there that refuse to give up your dip chips, here is the new Propeller 2 - 128 pin dip package and special socket. A custom chip extractor is also in the works.
Comments
Getting a later start this evening than I wanted to after dinner, and putting the girls to bed ... right now it's 10pm, I'll probably work until 2:00am ish.
Should have most if not all of the main wiring done tonight or tomorrow.
BTW) evanh , Your Cancel Button actually works!! That's remarkable! I always end up killing the process manually. :-)
BTW We moved this week and I found my Intel posters of the 386 & 486 dies. If anyone is interested I can take a photo and post them.
Thanks!
"I would like to know what the blocks are if you are permitted to tell us." - I can, this is just the test Die. Starting in the upper left corner and moving counter clockwise you have the COG_RAM, immediately under that (not very big, but packed, you have the DUALPORT_RAM. The large 'square' in the lower left is the HUB_RAM. The smaller 'square' in the lower right is the ROM. Following the outside perimeter at about 3'Oclock is the PLL. Above in the right most upper corner and moving left is the OSC, BOD (Brown Out Detector), and PUD(Power Up Detector).
Under the BOD and OSC are programmable fuses.
Just right of center is where everything is connecting to. Basically a chain of 8 32-bit flip flops with access to D and Q connecting to the inputs and outputs of everything I mentioned above.
32 bits x 8 shift registers x 2 (D & Q) = 512 connections.
Reference this thread for the images:
http://forums.parallax.com/showpost.php?p=941256&postcount=114
Can you tell us how big the COG_RAM, DualPort_RAM, Hub_Ram and ROM are on this test? (I would presume the Cog_Ram is 2KB and the DualPort is 512B or 1024B from what we know). The Cog_Ram is actually Quad Port isn't it? - in order to get 1 clock access instructions the cog will need to fetch I [instr +2], fetch D & S [instr +1], and write R [instr +0] simultaneously.
The memories being tested are full size, however there may be multiple instantiations of some that contribute to the total effective size.
...Yes the COG_RAM is actually a Quad port, but operates differently than the actual memory labeled DUALPORT.
--> All point to point buss routing in the Die core has been routed!! ... which means I can start the LVSing process and move towards the top level Test Die. (i.e. connecting the IO's)
--> What's involved before LVSing or DRCing? ... to speed up the process I will lobotomize the individual memory bits out of each memory cell. This eliminates over 1 million LVS and DRC checks that have already passed within individual memory blocks.
--> once the 'Die Core' is complete and passes LVS and DRC I can move up to the 'top' test Die level
--> When? ... starting Monday morning
PS - somebody just needs to remind me to put the memory bits back in before we are 'done done' with the Test Die ;-)
http://www.bunniestudios.com/blog/?p=1309
lol - first thing I wanted to do was zoom in and get a closer look :smilewinkgrin:
I'm having a bit of trouble running here in Debians IceWeasle version of Firefox. Single stepping works OK but just hitting run bogs down and then all my PC's fans fire up as it stresses out the CPU.
heater: great link but just now having internet problems to run the video section.
Based on area, the Propeller II will be approximately six times larger than what you see in the Test-Die.
60.3 Million square microns for the Propeller verses 10.2 Million square microns for the Test-Die.
What about total transistor count (for both Prop 2 and 1)?
The Prop I is about 6mm a side making it 36 Million square microns. However the process used in the Propeller I was 350nm ... In the Propeller II the process used is 180nm. So If the Propeller I were built using 180nm process it would occupy about 1/4 of the space, so it would be slightly smaller than the current test die. But keep in mind, not all devices are scalar between processes, so it's not a direct shrink and really hard to compare the two that way.
As far as transistor count, I don't have a good way to get that info from the Prop I. I will be able to provide that number at a later time from the Prop II
--> The TestDie Core is LVS/DRC clean!
--> Currently I am at the TestDie 'TOP' level
The general flow for layout and getting LVS/DRC to pass when you have lots of memory bits is to...
1) Test the individual memory blocks and make sure that they pass by themselves individually.
2) Backup your database!!
3) lobotomize the bit cells within the memory in layout AND the schematic so that you don't waste the day waiting for the tool to finish LVS/DRC checks. With four memory blocks if you 'just' count the bits, that's a total of 544,768 checks that LVS has to do that essentially you have already done. 1,089,536 if you count DRC. In reality though each bit has at least 6 transistors or more, so 6,537,216 LVS/DRC checks that you can eliminate at least during the initial hookup and checking. ...Ohhh, and each transistor has 4 terminals to evaluate (Source/Drain/Gate/Bulk connection) ... Making that 26,148,864 LVS/DRC checks that you can temporarily eliminate.
4) Once the LVS/DRC passes with the lobotomized memory versions, substitute in the real deal and run a final 'sanity check' LVS/DRC with all bits in place.
I know a DIP package is out of the question, but how about a DIP adapter?
KK
The question is "what do you mean by DIP adapter?". Do you want a subset of the pins to be available to keep the adapter's pin count reasonable or do you want something that would make all the pins available? Both choices have their advantages and disadvantages. Do you mean a bare chip adapter or a module like the PropStick with some basic support circuitry included? Remember that the Prop II will need two power supply voltages.
Given the discussion to date, I suspect that there will be a variety of modules available.
My first board will probably have SDRAM and peripherals like SDCARD which will probably consume 64 pins leaving 32 user IO available
While a DIP may not be possible, any Propeller Platform module would fit nicely
The newer faster semiconductor processes require a low voltage for the fast stuff in the core (1.8V or 1V are common) to minimise heating and power consumption, and just use 3.3V for the output drivers. It's not much of a problem as dual-output switchers are made by Linear and are often used with other chips with dual power supplies. A couple of linear regulators might do.
I just think the ability to bring all the pins out to the development part of the board, so that any attached hardware (like ps2 ports or eeproms) can be avoided (as in not connected) and reconstructed on the bread board environment.
Any ideas how much the propeller language is going to change, if it does at all?
KK
You can be certain that most things will be unchanged and that some of the new capabilities will look very much like the existing ones. There will still be special registers and some things will be accessed by using statements that look like method calls.
There may be some "compatibility" functions that look like current statements, but may use some other mechanism to provide the same functionality. These are all techniques used many times in the past when a new model processor is developed, only slightly different from the old one, and there's a large existing code base.
And, some people said that the setup to feed 1.8V is a waste of power. Not always. See, 5 Amps of 12 V in the computer is wholly used to.... Create 96 AMPS(!!) of 1.2 V for your x86 CPU to happily munch on, so that way you can even view this webpage without CPU's voltage dropout mechanism getting all too moody. (Did that experiment - very interesting.. But I did that on tossed-out motherboard as it's very risky.)
Therefore, try to use the effecient voltage regulator - like switching regulator, so it won't eat extra ampere in the process. But please put 100uF 4V low-ESR capacitor on the output of your switching regulator so you won't have to deal with your Propeller II behaving funny.
Russ
Now that's funny... the thing is, I've seen chips like this before!