Check this link : http://www.nvidia.com/object/balancedpc.html and then scroll down and click “launch configurator”
Heres the config I came up with..its best among the given comb if choices..
2 comments June 18th, 2008
Cisco On-stage Telepresence : http://www.musion.co.uk/Cisco_TelePresence.html
Hand Cellular tech ad from QCOM ( its friggin cool) :
http://youtube.com/watch?v=oYimJPi5qJY
I’ll continue to update these links as and when I find something interesting in Hardware/Semiconductor space.
Add comment May 29th, 2008
Often there might be cases when we dont know whats the cause of congestion. You can never point at one source and this contributes to congestion. This has to be tracked from very early in the flow (logic synthesis).
I will try to highlight some of the things to check based on my experience. Also,by no means this is complete reference .
1. Does your cell count looks suspicious? even though area is comparable, but if cell count is pretty high, P&R tools might have a problem in placing and routing so many cells and leads to congestion.
2. Is synthesis tool using lot of complex gates or are there any big muxes infered from RTL itself, then you might need to recode the RTL making routing job easier.
3. If RTL is OK, and synthesis is inferring complex gates, it might help yet times to decompose those logic.
4. Some times logic restructering with cone depth greater than default set in the tool will help..
5. check if you are over contraining/are giving very agressive slack targets to logic synthesis tools..
6. See if you can flatten some smaller modules where constraints are not set..this helps all optimization commands
7. Some times dont touch/force keep attributes prevents synthesis tools from remapping
8. Check the library to see if any functionally equivalent cells with smaller area footprint should have been used…for example, if you have hidden a DFFS flop and only DFFRS (set-reset flop) is available, you are adding one more pin and higher cell area to be used..check for these..
9. Often incorrect constraints , it can be synthesis or timing or floorplanning or placement constraints also leads to the problem. If the problem is here, dont expect the tool to override these as its a user issue and the tool tries to honour the constraints
10) If you see too many level of logic, you might want to collapse them . One more point that pops up in this context is hierarchy maintainence. Check if you can do selective hierarchy maintainence and if its correctly setup.
11) Check for HFN
12) Check secondary cost function objectives
13) If DFT is already done, check the number of Testpoints (TP) inserted . you might be inserting too many TP for very small cov gain. You need to consult with your DFT team to quantify how much you can really sacrifice. It varies for every design
14) Check if a particular block/module can be optimized for area while the timing critical part of the ckt can be optimized for delay.
15) Majority of the congestion issues can be traced to floorplan.
Things to check at floorplan stage in no specific order:
a) Is the congestion around channels between macros? You might need to resize the channels sothat all macro pins can be accessed by the router.
b)See if you are wasting too much space for channel/island widths etc..you might not need channels all the times..an example could be for CAM’s where a pair macros have to be aligned and you can abut the macro pair on side where there no pins. This will save some space.
c) Check the pin density forthe overall block.
d) Check if there are routes around the macro corners
e) check the average & peak track overflows on each metal layer. This will give you hints what can be the reason.
f) Use blockages cautiously
g) did you set the highest routing layer incorrectly
h) is too much wire causing the issue ?
i) are the endpoints which are connected placed far apart. Need to check why ?
j) is it because of scan chain wirelength? Did the scan optimization happened correctly. Yet times, incorrect scan order constraints prevent the scan chain wirelength optimization.
k) check the scan repartitions (often tools like LV will print what are compatiable grps and so what can be reordered and optimized)
l) Check if the tool is buffering a lot to fix the timing issues..
m)check to see if the pre-placement of analog blocks etc are in optimal location ?
n)check to see if the floorplan grid is defined and set correctly..If incorrect, you are wasting some routing resources. Setting right and efficient routing constraints are essential to get best routing results .
o) check to see if the MBIST controllers are placed at optimal locations to the memories they control. Optimal sharing of memories and mode of MBIST sharing (whether serial/parallel) also pays siginifcant role
p) If the macro placement floorplan provided for MBIST insertion is different from the actual floorplan you are trying to comeup with, then expect congestion issues as the memories shared are not correct in the revised floorplan. Floorplan changes should be only incremental . This is bit subjective and has to reviewed on case by case basis
q) check the cell density. Are there any decent empty spaces in the floorplan while there are some spaces that are heavily congested. This happens if the tool is trying to squeeze the logic inorder to meeting timing.
r) Check for the overlaps. Is there enough space for all the macros/std cells to legalize .
s) check your power planning ( power mesh/rail creation)
If you checked all the above and you still cannot resolve, may be you are trying to stuff too much logic and you might need to expand/grow your floorplan. This often involves top level floorplanning changes.
If anyone has any other suggestions/tips for congestion anlaysis , or if you have any ideas or methods on predicting the congestion itself, I would welcome that feedback as well…
Add comment May 27th, 2008
Floorplanning is an visual art. I believe this process can never be fully automated. What I mean by this, you cannot just simply push a button and let the tool do the job and give you a production quality floorplan the very first time.
You can automate the process, but the user should still drive the process. He should be able to define all the requirements and let the tool do its job and then review the result.
The intent of automation at the floorplanning level is only to reduce TAT and arrive at your final result pretty quickly. The user has to understand that there can be never one flow/size fits all and since each design is unique, you might need provide all inputs to the tool sothat it can converge on a good quality floorplan in decent time and the user can spend just few hrs in making it a production floorplan as opposed to spending couple of days/weeks.
Add comment May 27th, 2008
For last couple of months, I want to move to personal financial SW and I’m glad to recommend yodlee money (web based). My criteria were
1. Sophisticated ,yet simple in terms of management
2. Ability to auto categorize transactions with minimal guidance
3. Easy Account setup
4. Ability to setup budgets
5. Gives me spending analysis in terms of pie charts and tables etc
6. Should be able to setup all accounts incl IRA/401K , Indian banks etc and manual real estate accounts.
7. Less expensive ( less than 30$ per yr)
With the above in mind, I tried
1. Quicken Premier deluxe 2008
2. Microsoft Money
3. wesabe (free web based)
4. mint.com (free web based)
5. yodlee (free web based)
Quicken is far too sophisticated and demands more attention/time. It cannot auto categorize all of the transactions correctly. But by far it has all the nuts and bolts if you have time ..Doesnt support Indian banks a/c . Formats supported are QFX/OFX only.
Microsoft Money also pretty much has the same features as quicken, but I didnt like the way setting up accounts , the look and feel, manageability of the accounts and SW itself.
Wesabe : You cannot setup indian bank accounts, cannot auto categorize the transactions, but gives you the ability to define the category names you want . Has best online community..it gives you tips on say groceries from other users in wesabe and if its applicable , you can implement. I didnt care for this feature as it was too generic in some cases and not for indians 
..I dont care what mr.dude from Idaho has to say on the food and dining..For me this feature was not imp.. and big minus from my side was this doesnt have auto update feature….
mint.com : By far the it has the best UI ..you should check it out just for kicks..far better management and account setup than any…it still misses in auto categorizing some transactions correctly..Limited setup for Indian banks/overseas bank. shares the same infrastructure as yodlee for transactions retrival..this site has the ability to compare your spending in a particular category vs users in particular city avg spending..it also gives you tips on saving more money..for example, it can tell you that have a checking a/c WAMU will save you an extra 50$ etc…
Yodlee: UI is not as great as mint, but better than wesabe. Supports most indian banks, some india pvt life & pension insurance accts (I expected that it would since , very minimal guidance is required for auto categorization and probably bets in class among all..you can track your airline rewards etc.. and it satifies all the 7 criteria I had and best of all its free …
for webbased finance management, all 3 of them use the same level of SSL encryption as many bank do and yodlee has extra layer of support for filtering phishing by asking you to identify a image and some extra questions you need to answer ..I think they are verisigned as well..so I’m least concerned abt security and if you want to avoid browser hijacks itself, use idvault and for firefox, use fijan secure browsing addon + adblock plus addon + noscript addon
give it a shot ……
Add comment May 27th, 2008
Recently I was talking with someone and he asks me this funny question.
What is the difference between a Field Applications Engineer and a Sales executive apart from the fact that FAE has technical responsibilties? In a broad sense, both belong to the sales organization and are part of the strategy process to win a customer. But one of the fundamental difference I think is : l the sales manager sells to the customer by saying there is donut and the job of the FAE is to say there is a hole in the center of the donut :) . I completely acknowledge that Sales is no joke and this is how it works in this world.
If we dont tell about the hole, then 80% of the time, the FAE spends fishing up the customers who fall in that hole. It is a lot support intensive task and the FAE can better spend that time else where and generate the revenue for the company.
1 comment October 1st, 2007
Lets face it. You have run the logic synthesis/physical synthesis tool and you have a problem. You havent met slack. Now what? where do you start? Each issue depends on the design/process node, I’m going to keep it simple and will list few pointers/tips as to where we should be looking for. These are just for guidance and you as Designer/CAD engineer/applications engineer have to dig deep and find the root cause. I’m assuming you have stopped the flow right after global placement and routing and havent entered CTS ( ofcourse it doesnt make sense even to do CTS when you failing timing )
Before , we start discussing about debugging timing issue/QOR, I’m assuming that the floorplan is of good quality. Please remember that a bad floorplan can give you a bad QOR no matter how hard the tool tries. Dont even both to do any debugging. Correct your floorplan first. If you are still in the early exploration phase, then dont complain about QOR, but rather concentrate on the correct by construction approach to give you best results.
Lets use the old and well known divide and conquerer approach. Ok now. lets break down the problem into 2 areas.
1. Your logic synthesis tool did the good job and its your physical synthesis which made the things worse.
2. The QOR after your logic synthesis is already bad.
Below is a sort of check list like what you want to do if you have issue with the above 2 items.
A1) What was the critical path looking like ? Is is a datapath or Register - IO path, IO-IO path or some macro-reg path?.
Look at the timing histogram and see how many paths fail .This gives you a good idea on how bad the timing looks like on your design. Check the top 15-20 critical paths. If it is a IO path, check the IO constraints. Also, relax the IO margings sothat they dont fail and become critical, do incremental timing optimization . Now check again, how the timing looks like. Is the critical path a reg-reg path? If it is a reg-reg path, then check step 1.1b
A2) For register-register path, check the detailed timing path and see
A2.1) Check if its a High Fanout issue, and if yes, whether the path has been buffered/cloned correctly?
A2.2) Also, check if the path is overbuffered/under buffered?
A2.2) Check if the tool has picked up correct drive strength cells? Yet times, tools dont upsize/down size the cells correctly and as a results, more buffers/inverters are added making the timing worse. Remember in 65nm a buffer has around 50ps delay.
A2.3) Also check if the tool has picked up a multi-stage cells. It is always a good idea to give the freedom to the tool to pick a cell and buffer it rather allowing the tool to select a available multistage cells. If you are trying to extract every pico second out of the tool, you might want to check this.
A3) Check if the tool complains about congestion. If you see congestion, then you might want to check the utilization. A quick visual inspection of the floorplan will tell you if there is more space available in the primary inner shape for the tool to move around. If this is the issue, then you have a placement issue.
A4) If Cloning/Buffering doesnt seem to the issue, then cross probe the timing path into the layout window using fly lines and see how the path is laid out. Is the path very long and jogging all around. If yes, then its a global placement/routing issue.
A5) Check the macro placement. How does it look? Does it look optimal? Did you create the halos around the macros? What about Placement blockages? If these are missing, please provide them and re-run the physical synthesis.
A6)If you are utilizing the auto floorplan capabilities of modern tools, then better check the quality of floorplan. Many tools have issue in creating a good and optimal rectilinear floorplans.
A7)If all else looks good, check the number of logic levels for register-register timing path. If this seems to high or suspicious, then check the logic levels at the of logic synthesis. IF you still the same thing there, then you have a logic synthesis issue rather than physical synthesis issue.
A8) To debug a logic synthesis issue, check the timing for the same path you see at the end of physical synthesis in front end STA. Check if it datapath or a control path or some kind of distributed logic sitting and getting shared between two modules.
A9)For datapath, check if the tool has picked the correct architecture. For example in case of adders,it might have selected ripple, but may be it could have selected carry-look ahead adder. similarly check if the tool can pick better architectures for other datapath components
A10) It is a control path, then check how the logic is being written in RTL. Whether if it is a deeply nested if-else logic with mutually exclusive conditions. should we really create a deep mux chain. How was the case logic written. May be the tool is inferring a big shifter, but only partial shiter is used. So the tool unnecessarily created the big shifter logic there.
A11) Yet times, it is problem of optimization itself. May be the tool couldnt have knocked off the extra registers by doing more agressive constant flop optimizations and dead code removal .
A12) Some times mistakenly users set unnecessary dont touch (synopsys) or force keep (magma) or they mess with the configs where they insist the tool the retain floating logic. Be careful in what you want to retain or what can be knocked off.
A13) Yes, the world is not flat always . Some users want to keep all the hierarchy. You dont want even that. Many optimization alogorithms works best when there is no hierarchy. Whenever there is a hierarchy, the scope of the optimizations is limited to within that module. So, only retain the hierarchy on which the timing contraints or present or when there are special requirements from other 3rd party tools regarding maintaining the hierarchy they introduced. So, check if any of the logic in the critical path can be flattened.
A14) Sometimes hiding the high drive strength cells in the library or preventing the tool from using very complex gates like XOR/XNOR and in some cases AOI/OAI cells helps to improve the timing. But this should not be done blidnly. Check the library and the cells the tool is picking. Then decide whether selective hiding is the way to go.
A15)Over Synthesis: Many users blindly push the tool to meet a high target slack in the design. I’m not referring to the clock uncertainity normally you account for. This target slack is applied only for front end synthesis. Be reasonable in what you want the target slack to be. Normally 15% of the clock freq is decent enough.
A16) Over Constraining : This is a setup margin you apply all across the flow till CTS is done. Again be reasonable in how much you constrain for. Over contraining can sometime break the alogorithms. The optimization alogorithms sees more negative slack that it really is and so inorder to meet slack, it tries over buffering/cloning/bad sizing and gives it up. Just for the record, this is not a bug in the tool. But it has to do more with constraining the design correctly.
A17) One more thing to check for is the slew limits and fanout limits and check if the tool is honouring them.
A18)Some times, because of the incorrect false paths or multi cycle paths set , you are mis guiding the tool. Remember folks, over exceptions kill the design. Dont set a false path unless it is needed . Perhaps setting a multi cycle path is way to go.
A19) Perhaps this should have been mentioned in the beginning. Quality of Contraints dictate your timing results. Bad constraints leads to bad QOR. So check your timing contraints before you start your timing analysis. There are many tools out there which can help you in this. As a thumb rule,
A19.1) check your IO constraints,
A19.2) check your exceptions ( multi cycle/false paths)
A19.3) Check if there are unconstrained nodes in the design? You should not have any uncontrained nodes.
A19.4) Check if there are more events happening on a given node? Say 12 or 16 timing events happening on the same node is not good sign. Check the node.
A19.5) Also check the timing event density . This will tell you if you have over lapping or conflicting contraints or if you have high number of timing events in the design.Either way, its not good. For example, some 3rd party DFT tools whether they write our post scan SDC, it some times large timing events on some nodes and this causes havoc on timing algorithms.
A19.6)Also check if there are any nodes where there are zero timing events. This is not same as uncontraining the design.
A19.7)Check the clock definitions and units .
A19.8)Check the generated clock definitions and whether the source clock is mentioned correctly.
A19.9) Check to see if there exists any cases in the design where clock becomes data. If yes, then timing analysis tools, will treat this as data node as opposed to clock node .
A19.10)Check if the case analysis contraints have been setup correctly.
A19.11). If you have a clock gating cell say CKG1 between 2 registers say FF1/Q and FF2/D , then the tool will see two paths : path from FF1/Q to CKG1/EN and CKG/OUT to FF2/D . But in reality, there is only one path FF1/D to FF2/Q and setup checks are done on FF2/Q. So, you have to tell the tool somehow to consider the delay through the clock gate and that the clock cycle time is from FF1/CK to FF2 . So the way you do it is you want to apply a negative margin at the clk pin of the clock gating cell and setup margin on the clock gating output pin and constrain the path.
A19.12) The cleaner and better the constraints are , the timing results will that much better.
Misc Tips: It is always good idea to study the library . It gives good idea on what cells and of what strengths are available in the library. It helps to fine tune your optimization and guide your implementation tools.
Add comment September 17th, 2007
Q1. Why are you creating the new product?
a) Is it because you see a gap in the current industry offerings and trying to fill in.
b) Or if there is a similar product, you see that your product changes the quality of service or life of your customers. For SW companes, comparing and improving run times is not compelling enough to face competetion. Other tools might catch up. Similarly for HW companies, high clock freq (faster speed) etc cannot be the sole distinguishing feature . Unfortunately, this is not at all a viable business plan/strategy .
c) You are creating a hybrid product or creating a entirely new market space and market is ready for this.
It is very important to realize that your product definition needs to be accomadating in a sense, that customer requirements change over time or a competitor has released a product .
Q2. What is your market segment and who are your customers .
Targeting a wrong customer base is very costly . Did you talk to your customers already ? Do you have any beta customers? Choosing a right beta customer is very important and can affect your product sucess/quality.
Q3. Can you clearly justify why the customer has to pay for the “must have” features ? If not, you need to re-consider your product definetion and features.
Q4. Can you clearly distinguish between “should and must have” features? Many make mistakes here as they dont clearly distinguish between “should” and “must” and so the sales cant focus on the value offering.
Q5. Do you have the roadmap ? Having it helps when a customer would like to see what additional (nice to have) features will be coming in future. When you bootstrap, you already have a customer who pays for your development and so they might have already defined to some degree what will be present in the roadmap.
Q6. How are customers doing without your product? How are they surviving? How is your product going to address their issues?
In general, It is not advisable to proceed unless you have answers for all the above questions.
Add comment March 2nd, 2007
Folks who wants to read my part I of the formal verification series , click this link :
www.srikiran.net/blog/2007/01/22/
I wont be elaborating much on points when they are self explanatory and some have been already covered in part I ( setting up the FV env section )
1. Check for unmapped points. Naming rules/mapping issues. Unless you all Seq elements and Black Box I/O’s in Reference and Implementation has been matched, the formal verif results are meaningless. Some tools report mapping failures when they see some objects in Reference (Golden) doesnt exists on Implementation (revised). This is one exception to this as it is quite possible that synthesis tool might have optimized them out. But if you see that Objects in Implementation netlist doesnt exists in Reference, then it means your formal tool is doing more optimization than necessary or something is worng.
2. Blackbox (BB) issues : If there is formal failure, check if BB’s are same in both the netlists are same and number of BB should be equal.
3. Debugging using hierarchical and flat approach : When hierarchical approach lists failures, dont jump to conclusions immediately. May be the context is not propagated correctly and hence the tool propagated wrong values and hence failure. Do a flat level verification either at the same failing module level or one level up the hierarchy.
4. Spare Cells :check for spare cells getting removed .
5. Port information: check if ports are getting removed like DFT test mode etc
6. Overlay/Feed Throughs : If you are loading your Implementation (Revised) netlist from your physical synthesis flow, check if there are any ovelay cells or feed throughs . Normally these dont exist in the original (RTL) or logic synthesis netlist. These are added by the physical synthesis tools during the top-down chip/block routing or integration stage. Overlay cells change the netlist by adding a hierarchy while logically/functionally the design is still same.
7. Cloning during CTS : Again in physical synthesis flow, during CTS, the place and route tool might have cloned some ports ( for example reset pin/port) and you need to tell your formal tool somehow that the cloned reset port is just an alias of original reset port .
8. Clock Gate Cloning :Another common issue is, the clock gates are cloned in physical synthesis flow and so you need to tell your FV tool about all the different clock-gates being used .
9. Power Connectivity : Some synthesis tools dont write power connectivity information of non standard cells by default , for example analog power information ( like AVDD or AVSS etc) and sometimes they write empty power connections for all blocks . This can cause formal failures tool.
Lastly , FAILURES are different from UNSOLVED points. FAILURES means the netlists differ and UNSOLVED means they are certain datapath elements like multipliers or for example ECC etc which are not verified. They can be still be verified if you can afford to wait for real looooooong times ( perhaps years..decades )
Add comment March 1st, 2007
I was recently talking to couple of design engineers at various companies and most of them want to have push button RTL-Placed Gates or RTL-GDSII flows. Though this sounds like a reasonable expectation, but in reality as many experienced designers know, this is often not practical. The issue here is right set of expectations.
We can develop a push button flow if we have a good design methodology with reasonable and manageable expectations. A designer or CAD design engineer need to understand that there are certain things they have to do like setting the synthesis env or constraints, providing good quality timing constraints etc . I have seen in numerous cases where the designers blame the tool for poor timing results , but when analyzed, they have a messed up their timing constraints or has specified timing exceptions where not necessary . Simply put, they might have over constrained their designs. While it is reasonable to expect the tool do a good job for a classical physical synthesis problems where the designers has very little to do, but it is not for a logic synthesis issues where a lot depends on the quality of RTL, constraints , DFT methodology etc.
Each chip is unique ( I’m not talking about the revisions of the same chip here) and the requirments differe from chip to chip in terms of complexity of the design, design size, number of macros used , number and freq of clock domains, DFT logic ( along with JTAG etc) , clock latencies, skew balancing ,cross-talk etc . Clearly OOTB Flow ( out of the tool box) might not always deliver the best QOR (ofcourse it means its a enhancement time for R&D ) and some amount of playing with different knobs/options is necessary to give the best QOR.
Add comment March 1st, 2007
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jun | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||