Just touching base! ... We felt that the most important Layout blocks were tested. This especially, since we changed CMOS process venders (<-- new DRC rules and requirements) midway through much of our IP design. Why no COGs in the Test Die? COGs are basically pure digital Boolean logic gates taken from a standard cell library of our own IP. Since the test die blocks that were put in and under test heavily rely on these standard cells i.e. the large FLIP-FLOP shift register chain, as well as the control logic to the memories and other blocks, it was a moot point at this time to place a COG in the test die structure.
That said, we are looking for an elegant solution that will let us synthesize and auto route the COG <=== LOTS of connections .... I am open to suggestions on a shape based auto router that I can throw at the highly digital block.
Here is the latest news I have heard from Chip:
Chip Gracey
Everything works, so far. ROM just checked out fine. PLL, XTAL, and OSC are all good, too. Also, power-up detector and
brown-out detector look good.
This is good news, because it means we got the layers right! (<--- another fun thing to sort out with a CMOS process change mid-way through)
The PLL tops out at 272MHz. The current Propeller goes to about 180MHz. This is as expected.
Note: Because of the process change, we are seeing about an 8% increase in speed, compared to what was originally simulated. At least for the on-board RC oscillator.
It's really cool of you to share the process with us.
This makes a lot of sense now. Basically, you've some key structures that will be used over and over, blocks on blocks style, and some specific sub-systems that are basically custom. Having tested those, the layout can be vetted, and then built. Really it's all about "the lay of the land" with the new process, and vetting the simulation results, so you know where the limits are, with your particular design characteristics. (custom polys)
Is that about right?
Did you guys test a fuse?
Edit: The planning required here is really something to appreciate. On one hand, you've got to work with some conservative estimates on what the silicon is supposed to do. Make those assumptions, and then plan out a fairly complete, but un-tested design. From there, some key elements are necessary and known, so those get tested. Based on those results, the plan then is realized with solid data, ideally eliminating a lot of those "will it do what the simulator says it will do?" questions. Then, that design is tested in various ways, which will lead to a final design?
This stuff really builds in a big way. One tiny misunderstanding, or error, leads to a huge mess!
right again... basically EVERY polygon in our design is one that I put down by hand. When I first started at Parallax, I had a completely blank canvas. The DRC library I had to work with was in the form of a paper PDF, initially I had to code all of the Boolean rules that are applied to the CMOS process we started out with, and then later compare all of those rules to the new process we are currently using. So in a sense everything in this design is custom layout. Once the DRC rules had been coded, the first step was creating a Standard cell library. This library consists of all of your basic structures (AND,OR,NAND,XOR, etc), but you need to build it in a way that each cell block can be stepped, flipped, and mirrored. So all of our standard cells have a fixed pitch height where power and ground is run horizontally, the pitch for the width is variable depending on the cell block. Another requirement is to keep the routing within each Standard cell so that it only uses the lower metals. For the most part the metal layer doesn't go above Metal layer1 , but in some cases that rule is broken. This isn't a drc rule, but an engineers rule to allow for escapement. Also an engineers rule, each metal layer has a specific direction that it is allowed to be routed, otherwise you can paint yourself into a corner. M1 is typically any direction, M2, M4 is horizontal, and M3,M5 is vertical. obviously there are exceptions to this rule as well, what if you rotate the block 90 Deg? .... anyway, point is every detail must be considered.
right again... basically EVERY polygon in our design is one that I put down by hand. When I first started at Parallax, I had a completely blank canvas. The DRC library I had to work with was in the form of a paper PDF, initially I had to code all of the Boolean rules that are applied to the CMOS process we started out with, and then later compare all of those rules to the new process we are currently using. So in a sense everything in this design is custom layout. Once the DRC rules had been coded, the first step was creating a Standard cell library. This library consists of all of your basic structures (AND,OR,NAND,XOR, etc), but you need to build it in a way that each cell block can be stepped, flipped, and mirrored. So all of our standard cells have a fixed pitch height where power and ground is run horizontally, the pitch for the width is variable depending on the cell block. Another requirement is to keep the routing within each Standard cell so that it only uses the lower metals. For the most part the metal layer doesn't go above Metal layer1 , but in some cases that rule is broken. This isn't a drc rule, but an engineers rule to allow for escapement. Also an engineers rule, each metal layer has a specific direction that it is allowed to be routed, otherwise you can paint yourself into a corner. M1 is typically any direction, M2, M4 is horizontal, and M3,M5 is vertical. obviously there are exceptions to this rule as well, what if you rotate the block 90 Deg? .... anyway, point is every detail must be considered.
There are 'some' capacitive effects from layer to layer, but there is more concern with parallel effects and fringe capacitance effects from the same layer of metal.
The 180nm CMOS process allows for 280nm spacing between wires on the same metal level. From layer to layer the distance is closer to 600nm.
Thanks for clarification ... --- I never worked on IC Layouts --- But as You maybe sen have some experience of PCB Layouts.
On Silicon Layouts I have only some theoretical Knowledge.
There are 'some' capacitive effects from layer to layer, but there is more concern with parallel effects and fringe capacitance effects from the same layer of metal.
The 180nm CMOS process allows for 280nm spacing between wires on the same metal level. From layer to layer the distance is closer to 600nm.
On CPU's, some heat can be traded for multiple instruction execution, tossing computations that are rendered moot by a result, for a net gain in speed. This process could work the same way, with teams iterating on several paths, based on the probable outcomes. The result would be a faster overall design, but teams who work on essentially nothing. One does wonder about the larger companies, and how they end up doing things... Maybe that speaks to some of why, along with using licensed blocks and just doing interconnect work on what is largely set pieces.
I am open to suggestions on a shape based auto router that I can throw at the highly digital block.
I assume, given that they cost more than my house, that Cadence or Synopsis aren't the answers you're looking for? They're what we use (well, one of them is - can't remember which at the moment, we seem to switch back and forth), though, presumably, our ASIC's are much larger than Prop II. Prior to that, we had a proprietary system (written in, of all things, Cray Assembler) that we scrapped due to lack of portability to architectures that don't need to be immersed in a vat of Flourinert to run
I've not heard of an open source or cheap router designed for chip layout.
One area you may want to look to for a tool that could be adapted is architecture. I know there are shape based placement tools to do things like laying out rooms on floors in a building. Perhaps with enough massaging of power traces to plumbing or HVAC systems one could be adapted to place standard cells?
I once did a layout with a parametric cad system. In my case, it was a test structure layout, one layer. Structures for a laser test and "burn the fuse" system. No active components on this one. Just 100 micron probe pads, and smaller, say 10 micron features that would carry current loads, and that could be hit with a laser to break the path. There were lots of different shapes, each placed on different grids. Once one was done, changing some parameters, and making a small edit to a copy of the source object was all it took to drop a lot of stuff into the layout.
Built one shape as a simple solid model, 100x scale, due to tolerance issues with solid modelers, then made a assembly, and a pattern to replicate those. Output was DXF, which I converted to the GDSII format, after scaling down 100x.
That's similar to how the architecture programs work.
One thing that strikes me is a "0" and "1" cell could be essentially built as a assembly with two configurations, some features suppressed, for each state. Placing them could be done with coordinates in a file, or with a macro, as could changing the state. That could get you a nice grid with all the right values. Some work would need to be done from there, but it may be some 80 / 20 kind of automation.
Some CAD systems cannot handle the massive number of component bodies needed to build the output file though. The one I was using could, and was pretty high end. The "middle" systems will top out on a very large structure. If you have some access to one of the "big three" systems, this may be possible. And some of the architecture systems don't have the strong parametrics associated with the design. Where that's true, the number of objects possible is considerably higher.
Boy, I haven't been on this forum in forever. Happy New Year everyone!!
Way to go Parallax in achieving another milestone in the Prop II. I've come to the forum because I am looking for a faster processor for a potential project. I'd love to use the Prop II, but I'd guess it may be too far off. But boy or boy I can't wait!
Hopefully soon I can be back to being a regular on the forum.
Comments
Just touching base! ... We felt that the most important Layout blocks were tested. This especially, since we changed CMOS process venders (<-- new DRC rules and requirements) midway through much of our IP design. Why no COGs in the Test Die? COGs are basically pure digital Boolean logic gates taken from a standard cell library of our own IP. Since the test die blocks that were put in and under test heavily rely on these standard cells i.e. the large FLIP-FLOP shift register chain, as well as the control logic to the memories and other blocks, it was a moot point at this time to place a COG in the test die structure.
That said, we are looking for an elegant solution that will let us synthesize and auto route the COG <=== LOTS of connections .... I am open to suggestions on a shape based auto router that I can throw at the highly digital block.
Here is the latest news I have heard from Chip:
Chip Gracey
Everything works, so far. ROM just checked out fine. PLL, XTAL, and OSC are all good, too. Also, power-up detector and
brown-out detector look good.
This is good news, because it means we got the layers right! (<--- another fun thing to sort out with a CMOS process change mid-way through)
The PLL tops out at 272MHz. The current Propeller goes to about 180MHz. This is as expected.
Note: Because of the process change, we are seeing about an 8% increase in speed, compared to what was originally simulated. At least for the on-board RC oscillator.
This makes a lot of sense now. Basically, you've some key structures that will be used over and over, blocks on blocks style, and some specific sub-systems that are basically custom. Having tested those, the layout can be vetted, and then built. Really it's all about "the lay of the land" with the new process, and vetting the simulation results, so you know where the limits are, with your particular design characteristics. (custom polys)
Is that about right?
Did you guys test a fuse?
Edit: The planning required here is really something to appreciate. On one hand, you've got to work with some conservative estimates on what the silicon is supposed to do. Make those assumptions, and then plan out a fairly complete, but un-tested design. From there, some key elements are necessary and known, so those get tested. Based on those results, the plan then is realized with solid data, ideally eliminating a lot of those "will it do what the simulator says it will do?" questions. Then, that design is tested in various ways, which will lead to a final design?
This stuff really builds in a big way. One tiny misunderstanding, or error, leads to a huge mess!
right again... basically EVERY polygon in our design is one that I put down by hand. When I first started at Parallax, I had a completely blank canvas. The DRC library I had to work with was in the form of a paper PDF, initially I had to code all of the Boolean rules that are applied to the CMOS process we started out with, and then later compare all of those rules to the new process we are currently using. So in a sense everything in this design is custom layout. Once the DRC rules had been coded, the first step was creating a Standard cell library. This library consists of all of your basic structures (AND,OR,NAND,XOR, etc), but you need to build it in a way that each cell block can be stepped, flipped, and mirrored. So all of our standard cells have a fixed pitch height where power and ground is run horizontally, the pitch for the width is variable depending on the cell block. Another requirement is to keep the routing within each Standard cell so that it only uses the lower metals. For the most part the metal layer doesn't go above Metal layer1 , but in some cases that rule is broken. This isn't a drc rule, but an engineers rule to allow for escapement. Also an engineers rule, each metal layer has a specific direction that it is allowed to be routed, otherwise you can paint yourself into a corner. M1 is typically any direction, M2, M4 is horizontal, and M3,M5 is vertical. obviously there are exceptions to this rule as well, what if you rotate the block 90 Deg? .... anyway, point is every detail must be considered.
As I understand it ---- Some of Vertical/Horizontal trace rules are for holding Capacitive impact from one trace to other as SMALL as possible ?.
There are 'some' capacitive effects from layer to layer, but there is more concern with parallel effects and fringe capacitance effects from the same layer of metal.
The 180nm CMOS process allows for 280nm spacing between wires on the same metal level. From layer to layer the distance is closer to 600nm.
Thanks for clarification ... --- I never worked on IC Layouts --- But as You maybe sen have some experience of PCB Layouts.
On Silicon Layouts I have only some theoretical Knowledge.
On CPU's, some heat can be traded for multiple instruction execution, tossing computations that are rendered moot by a result, for a net gain in speed. This process could work the same way, with teams iterating on several paths, based on the probable outcomes. The result would be a faster overall design, but teams who work on essentially nothing. One does wonder about the larger companies, and how they end up doing things... Maybe that speaks to some of why, along with using licensed blocks and just doing interconnect work on what is largely set pieces.
Heh.
Has the quad interface to the Cog RAM been tested yet (suppose it's a bit early yet)?
I assume, given that they cost more than my house, that Cadence or Synopsis aren't the answers you're looking for? They're what we use (well, one of them is - can't remember which at the moment, we seem to switch back and forth), though, presumably, our ASIC's are much larger than Prop II. Prior to that, we had a proprietary system (written in, of all things, Cray Assembler) that we scrapped due to lack of portability to architectures that don't need to be immersed in a vat of Flourinert to run
I've not heard of an open source or cheap router designed for chip layout.
One area you may want to look to for a tool that could be adapted is architecture. I know there are shape based placement tools to do things like laying out rooms on floors in a building. Perhaps with enough massaging of power traces to plumbing or HVAC systems one could be adapted to place standard cells?
Built one shape as a simple solid model, 100x scale, due to tolerance issues with solid modelers, then made a assembly, and a pattern to replicate those. Output was DXF, which I converted to the GDSII format, after scaling down 100x.
That's similar to how the architecture programs work.
One thing that strikes me is a "0" and "1" cell could be essentially built as a assembly with two configurations, some features suppressed, for each state. Placing them could be done with coordinates in a file, or with a macro, as could changing the state. That could get you a nice grid with all the right values. Some work would need to be done from there, but it may be some 80 / 20 kind of automation.
Some CAD systems cannot handle the massive number of component bodies needed to build the output file though. The one I was using could, and was pretty high end. The "middle" systems will top out on a very large structure. If you have some access to one of the "big three" systems, this may be possible. And some of the architecture systems don't have the strong parametrics associated with the design. Where that's true, the number of objects possible is considerably higher.
Way to go Parallax in achieving another milestone in the Prop II. I've come to the forum because I am looking for a faster processor for a potential project. I'd love to use the Prop II, but I'd guess it may be too far off. But boy or boy I can't wait!
Hopefully soon I can be back to being a regular on the forum.