FINAL YEAR IEEE PROJECT TRAINING IN CHENNAI

POWER SYSTEMS PROJECTS

3D PRINTING TECHNOLOGIES

http://www.spiroprojects.com/final-year-projects.php?subcat_name=Final-Year-3D-Printing-Technology-Projects-in-chennai&sub_cat_id=563D PRINING TECHNOLOGY

FINAL YEAR PROJECTS IN CHENNAI

The quest for Linux friendly embedded board makers

We used to keep a list of Linux friendly embedded board makers. When this page was created in the mid 2000s, this page was easy to maintain. Though more and more products were created with Linux, it was still difficult to find good hardware platforms that were supported by Linux. So, to help community members and system makers selecting hardware for their embedded Linux projects, we compiled a first selection of board makers that were meeting the below criteria:

• Offering attractive and competitive products
• At least one product supported Free Software operating systems (such as Linux, eCos and NetBSD.
• At least one product meeting the above requirements, with a public price (without having to register), and still available on the market.
• Specifications and documentation directly available on the website (no registration required). Engineers like to study their options on their own without having to share their contact details with salespeople who would then chase them through their entire life, trying to sell inappropriate products to them.
• Website with an English version.

In the beginning, this was enough to reduce the list to 10-20 entries. However, as Linux continued to increase in popularity, and as hardware platform makers started to understand the value of transparent pricing and technical documentation, the criteria were no longer sufficient to keep the list manageable.
Therefore, we added another prerequisite: at least one product supported (at least partially) in the official version of the corresponding Free Software operating system kernel. This was a rather strong requirement at first, but only such products bring a guarantee for long term community support, making it much easier to develop and maintain embedded systems. Compare this with hardware supporting only a very old and heavily patched Linux kernel, for example, which software can only be maintained by its original developers. This also reveals the ability of the hardware vendor to work with the community and share technical information with its users and developers.
Then, with the development of low-cost community boards, and chip manufacturers efforts to support their hardware in the mainline Linux kernel, the list again became difficult to maintain.
The next prerequisite we could add is the availability as Open-source hardware, allowing customers to modify the hardware according to their needs. Of course, hardware files should be available without registration.
However, rather than keeping our own list, the best is to contribute to Wikipedia, which has a dedicated page on Open-Source computing hardware. At least, all the boards we could find are listed there, after adding a few.
Don’t hesitate to post comments to this page to share information about hardware which could be worth adding to this Wikipedia page!
Anyway, the good news is that Linux and Open-Source friendly hardware is now easier and easier to find than it was about 10 years back. Just have a preference for hardware that is supported in the mainline Linux kernel sources, or at least from a maker with earlier products which are already supported. A git grep -i command in the sources will help.

Placement of Clock Gating Cells using VLSI

Clock Gating Cells are indispensable components to save dynamic power. However, the backend design engineers must be prudent while placing them. In this post, I'll talk about the trade-off between timing and power that underlies the placement of clock gating cells.

Consider that your SoC has two IPs, and a single clock source. These two IPs are synchronous, and might work independently (i.e. without any interaction with the other IP) in some use-case of the chip. This entails the need of two clock gating cells. Now the question arises: where to place these clock gating cells. 

• Near the sink, i.e. the clock source, or
• Near the source, i.e. the respective IPs

Let's take up pros and cons of the two placement scenarios.

1.Clock Gating Cells placed near the source: As shown in the figure, placing the clock gating cells near the clock source, can  the increase the uncommon clock path (shown in yellow). 

 

 

 

 

Recall from the post: Common Path Pessimism that while doing timing analysis, the effect of OCV derates come into picture for the uncommon clock path because the clock tree buffers in the uncommon path can behave differently and hence an STA engineer needs to take into account that extra uncertainty or pessimism while doing timing analysis. Such a scenario is therefore hostile to the timing engineers. However, from power perspective this scheme is quite favorable. Since as soon as the clock gate is turned "Off", all the clock buffers in the fanout of that clock gate are also "off" or in other words, they do not toggle and hence do not dissipate dynamic power. Like any engineering problem, there exists a trade-off between two conflicting factors, and designers often need to prioritize.

2. Clock Gating Cells placed near the sink: While this scenario, with greater common path as compared to the first scenario and hence making the timing easier to met, is not friendly from the power perspective. 

All the clock tree buffers  in the common clock path (shown tin red) lie before the clock gate and hence would always be "on" and keep on toggling at the clock frequency, thereby dissipating dynamic power.

Solution:

The pertinence of a solution is dictated on many factors. Permissible clock latencies, power dissipation specifications, timing closure challenges and also the use-case.

Let's say we had a requirement that IP 2 will function if and only if IP 1 is on. In this case we could have placed the clock gates in series like this:

 

By having the two clock gates in series, we would save the dynamic power of all the clock tree buffers in the fanout of first clock gate. Moreover, the uncommon path is significantly less as compared to the scenario 1.

Again note that this solution would not work if we had the use-case where IP 1 could be "off", while IP 2 still "on".

 

Common Path Pessimism in VLSI

Common Path Pessimism is a common source of some extra pessimism in timing analysis. Before we delve further into this, note that pessimism can be of two types:Intended and Unwanted. Intended pessimism could be like adding some extra uncertainty for clock skew before CTS stage, or some uncertainty for noise before SI (Signal Integrity) analysis. It is often prudent to have this pessimism taken upfront in your design because it will avoid any surprises when you move from one stage to another. 

Having said that, which category do you reckon should Common Path Pessimism fall? Let's define it first and then we'll take a look at it objectively.

When any pair of launching and capturing flop have a some portion of clock path as common, the difference between the max and min delay of that common clock segment is referred to as Common Path Pessimism. We discussed the rationale behind the use of timing derates briefly in the post: OCV vs PVT. Note that the entire timing analysis revolves around this intended pessimism where the basic aim is to make the timing paths more critical to avoid seeing any surprises in the silicon. EDA tools, however, themselves have quite a fair amount of pessimism, it is always prudent for the STA engineers to augment some uncertainty/pessimism in their timing analysis.

Convince yourself that:

• Setup check would be most critical when clock reaches the launching flop late and capturing flop early; and the data path takes more delay.
• Hold check would be most critical when clock reaches the launching flop early, capturing flop late and data path takes less delay.

Consider the following example with no common clock path and note that we have just applied the above principle to add pessimism in timing analysis.

 

                            

So, while doing setup analysis, the clock tree buffers in the launching path would be derated by +5% and in the capturing path would be derated by -5&. The data path would be derated by +5%.
While doing hold analysis, it would be the opposite. The clock tree buffers in the launching path would be derated by -5% and in the capturing path would be derated by +5&. The data path would be derated by -5%.

How would the situation change when there's a common clock path? Let's take a look.

 

Ideally speaking, for setup analysis, we would like to take the +5% derated value of the delay of these buffers while considering launching path and -5% derated value while considering the capture path. However, here lies the catch! How can the same buffer or set of buffers be derated differently for launch and capture? Recall from the definition of OCV that it is the intra-chip variation in PVT that STA engineers consider them in the first place.

However, now these buffers, they are in the same location. So at a time they would behave in a similar manner. It does not make sense to consider different delays for same buffers. And this is the origin of common path pessimism and in usually unwanted. What we can do is (or rather what EDA tools tend to do is), do the calculation considering common path to be non-existent. And in the slack, add the double derated value of the common buffers, which would be 10% of the three common buffers in this case. This is referred to as Common Path Pessimism Removal.

 

 

FINAL YEAR PROJECT TRAINING

www.spiroprojects.com/training1.php
www.stupros.com/training1.php

WE CAN ALSO IMPLEMENT YOUR OWN CONCEPT/IDEA

CORPORATE OFFICE: - SPIRO GROUP OF COMPANIES FOR ECE, EEE, E&I, E&C
MECHANICAL,CIVIL, BIO-MEDICAL, #1, C.V.R Complex, Singaravelu street,T.Nagar,Cennai-
600017,(Behind BIG BAZZAR) Mobile: 9962067067; 9176499499 Email:info@spiroprojects.com.

               FOR IT, CSE, MSC, MCA, BSC(CS), B.COM(CS) #78, 3rd Floor, Usman Road, T.Nagar, Chennai–17, (Upstairs of Hotel Saravana Bhavan) Mobile – 9791 044 044,9176 644 044. E-Mail:info1@spiroprojects.com,

Website: www.spiroprojects.com Our branches : 

SALEM – 9176 615,615,

ERODE – 9962 587 587,

KOVAI-9176 648 648,

TRICHY-9176 649 649,

 MADURAI-9176657 657,

NELLAI-9176 617 617,

NAGERCOIL – 9176 658 658,

NAMAKKAL – 9962 514 514,

VELLORE – 9176 620 620,

PONDICHERRY-9176 694 694,

 KANCHIPURAM – 9176 412 412,

TANJORE – 9176 419 419

DOMAIN : AUTOMOBILE ENGINEERING

ITMA01 Power generation by using hydraulic brakes system in automobiles

ITMA02 Electricity generation by using speed brakes

ITMA03 Air conditioning system by using vehicles suspension

ITMA04 Automatic differential locking system

ITMA05 Auto clutch for automobiles

ITMA06 Button operated gear shifting system for two wheeler

22 ITMA07 Automatic 2-wheeler side stand

23 ITMA08 Automatic braking and bumper system for automobiles

24 ITMA09 Modification of exhaust system of 2-wheeler for emission
control

25 ITMA10 Design and application of continuously variable transmission
system

26 ITMA11 Power transmission through timing belt in 2-wheeler

27 ITMA12 Moulding and fluid flow analysis of wavy fin based automotive
radiator

28 ITMA13 Design and fabrication of shaft drive for bi-cycle

29 ITMA14 Fabrication of chain tightener

30 ITMA15 Exhaust gas heat recovery for IC engines

DOMAIN : FABRICATION AND MANUFACTURING

31 ITMF01 Fabrication of energy regenerative bi-cycle using fly wheel

32 ITMF02 Fabrication of roll-to-roll fluidic assembly

33 ITMF03 Development of non-conventional portable abrasive jet machine

34 ITMF04 Coconut tree climbing and cutting machine

35 ITMF05 Salt water converted to purified drinking water by using pedal
power

36 ITMF06 Pedalling dress washing machine

37 ITMF07 Fabrication of vertical axis and horizontal axis wind turbine

38 ITMF08 Involute gear profile detector

39 ITMF09 Design and fabrication of Moto autor

40 ITMF10 Solar grass cutter with linear blades by using scotch yoke
mechanism

41 ITMF11 Development of solar Fresnel reflector and its tracking stand
using local material

MECHANICAL PROJECT TITLES
DOMAIN : THERMAL ENGINEERING
PROJECT TITLES

ITMT01 - Fabrication and testing of refrigeration using engine waste heat

ITMT02 - Cyclone separator with blower

ITMT03 - Fabrication of miniature boiler

ITMT04 - Fabrication of plate freezer

ITMT05 - Waste chill recovery heat ex changer

ITMT06 - Industrial boiler flame adjustment system

ITMT07 - Fabrication of solar air dryer

ITMT08 - Fabrication of three in one air-conditioner

ITMT09 - Fabrication of auto air conditioner generator utilizing exhaust waste energy
from a diesel engine

ITMT10 - Fabrication and performance analysis of solar water heater using porous
medium and agitator

ITMT11 - Solar aided portable vacuum desalination system

ITMT12 - Testing and validation of thermo-electric coolers

ITMT13 - Design and analysis of stress on thick walled cylinder with and without
holes

ITMT14 - Fabrication of solar power Hot and Cold Water Dispenser

ITMT15 - Augmentation of Saline Streams by Concentrated Solar Distiller with Mini
Solar Pond