Eram, you need to get your terminology and concepts straight.
There's no such thing as a "clustered primary key", only a clustered index. By default, when you define and create a primary key on a table, SQL Server will automatically create a clustered index on that particular column (although you can turn off that automation if you want).
You can create a clustered index on any column. It doesn't have to be just on the primary key column (but like it was stated earlier, you can only have one clustered index per table).
There are many times when putting a clustered index on the primary key column is not the best situation, which is why you shouldn't always trust SQL Server to put a clustered index on the primary key column. It really depends on how you are going to use the table. For example, if you table has a date column, and a lot of your queries against that table use dates or date ranges, putting a clustered index on that date column might be a good idea, even if that date column cannot be considered a primary key. Therefore, in regards to your app, you'll have to look at the big picture (the types of queries hitting the table, does the table receive a lot of inserts, updates, or deletes, etc.). Choosing your primary keys and your indexes needs to be done with care. It'll do you well to read up on indexes to understand how they are structured and how they work.
Like rm said, a primary key is ony for referential integrity, not performance. Defining primary keys and foreign keys helps to eliminate things like orphaned or childless records.