PO worried about progress in the sprint and demanding from developers

Has the Product Owner talked to the Developers?

The Product Owner and the Developers should be working closely throughout the Sprint. After all, the Product Owner is a member of the Scrum Team. It seems like the Product Owner has some visibility into the status of the Sprint Backlog, so as soon as the Product Owner had questions, they should have gone directly to the Developers to ask and get clarity. There's no need to involve the Scrum Master in this situation.

I do think it's wrong if the Scrum Master suggests anything other than going to talk to the Developers. For example, suggesting that the Product Owner join a Daily Scrum would be wrong. The Daily Scrum is by the for the Developers. Unless the Developers extend an invitation to the Product Owner, the Product Owner should not invite themselves or show up unannounced.

Regardless of what happens, the Sprint Retrospective would be an opportunity to talk, as a whole team, about what happened and how to improve in the future.

Developers forecast was about half of the sprint for that item and without this getting done, sprint goal cannot be reached.

Are the Developers accounting for this situation to themselves? Do they have that grip? Is progress in line with their plan for managing risk to the Sprint Goal?

Developers forecast was about half of the sprint for that item and without this getting done, sprint goal cannot be reached.

This statement shows that the item was probably the most critical one (a must have with respect to the sprint goal). The questions I have is 

Did the developers and PO agree during the sprint planning that this item was critical? 

-If the answer is No then there is some communication gap between the PO and the developers (could be the PO did not flag the criticality in the planning or the developers have not understood the criticality of the task). 

-If the answer is Yes then the next question is Was there some impediment/ blockers the team encountered when they started the work and did they discuss this during the daily Scrum and was this brought to the notice of the PO (remember he has set the priorities and should be informed)?

Keep in mind the PO is also a part of the Scrum team and should be kept in the loop in case something gets delayed and would impact the sprint goal. It is best to discuss this issue during the sprint retrospective and identify why this happend and what should be done to ensure this does not happen in future.

The commitment of the sprint is the sprint goal and not sprint backlog. So the focus for the team has to be the items in the sprint backlog that contribute to the sprint goal first.The tasks/stories in the sprint backlog can be ranked during the Sprint planning so the team have the priority tickets to start in the list.So this situation can be avoided.

This sounds like the Scrum Team is not sufficiently cohesive. It is a pretty common problem of many Scrum Teams struggling to act as "one team" with the PO. The SM should put more energy into coaching in this regard. Also, taking action such as socializing events to improve the team's cohesion can be very helpful. The PO is part of the team and both the PO and the developers need to feel comfortable talking directly whenever there is a need.

We are close to the end of the sprint, and PO notices that developers has not started to work on the highest value item. Developers forecast was about half of the sprint for that item and without this getting done, sprint goal cannot be reached. 

After the Sprint started and the Developers learned more, do they still think their initial forecast is correct?  Maybe they have learned new information that changed that assessment.  This is something that should be discussed between the Developers and Product Owner.  It is something that should have been done as the Sprint progressed and not something kept to one part of the team. If I were the Scrum Master, I would bring this up as a topic for discussion in the Sprint Retrospective.

One thing you need to remember about forecasts.  When most people hear the word forecast, the first thing that comes to mind is weather.  Weather professionals have been providing forecasts for a very long time.  A forecast is a best guess on the future based upon information known at the time the guess is made.  As new information is gained, the forecast is usually adjusted.  For example, how often is a 14 day weather forecast accurate to the degree and percent of rainfall expected?  Not very often and it will be adjusted every day as more information is gained.  The longer the range of the forecast, the less reliable the forecasted result can be. 

This is the same with software development.  The Developers made a forecast (i.e. guess) based upon the information they had at the time.  It is likely that once they started working, they learned more information that could impact their initial guess.  If that is not being communicated well to the Product Owner, then that is the problem the team should focus on. 

Thanks for the comments. I agree there may be communication problem and retro is the place to discuss.

"PO considers to demand developers to start the item immediately. What can SM suggest to the PO in that situation ?"

What do you think about SM's suggestion and PO's consideration ?

"PO considers to demand developers to start the item immediately. What can SM suggest to the PO in that situation ?"

PO is the one who prioritizes the backlog and if he has prioritized some item as  important, why cant the team take it in the sprint ?

However mid sprint, if the PO says to add some thing , then you need to set up a connect between the PO and the developers (who are owners so to speak of the sprint backlog). Discuss if it is so critical that it needs to be accommodated in the ongoing sprint or can we take it in the next. Also if this is to be added in the ongoing sprint what is it that can be deprioritized and removed from the sprint (how will this affect the sprint goal)

PO and Team have a symbiotic relationship. One cannot exist without the other. PO decides the next most important thing to work on. The team decides the best way to deliver it. Sprint planning is where the PO presents that next most important work, and through story point estimation and historical velocity, the team decides whether or not they can complete that work in a sprint. If they can they commit to completing it, otherwise they negotiate with the PO on what items of work they can commit to based on estimation and velocity. Sounds like that planning and negotiation is not happening in sprint planning? 

I agree with the concerns expressed in the original question.  The PO is not a project manage.

To discuss the communication in the team,  there is only one team, where everybody speaks equally. No separate dev team anymore in Scrum.  The PO cannot demand how the developers work, but can raise a point or concern any time during the sprint. A discussion should then ensue. Maybe there is a good reason the item was not picked up, or there was a misunderstanding .Encourage dialogue, not commands.

Advocate for equal participation and this include the PO. PO is an equal member in the team, thus not a project manager, but also not a silent role .

developers has not started to work on the highest value item. Developers forecast was about half of the sprint for that item and without this getting done, sprint goal cannot be reached. 

I wonder what the Sprint Goal was and how it was created. It should be the outcome of a dialogue between PO and Devs. If the Sprint Goal is dependent on a single high-value PBI, then that should be obvious when having that dialogue. 
But in my opinion, a Sprint Goal should not be too dependent on specific PBIs:

If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

When a PBI cannot be finished anymore, but finishing it was the Sprint Goal, the Sprint may become obsolete. 

While facilitating a discussion to understand why the highest value item has not been started in time, try to find Sprint Goals which provide more flexibility in regard to the scope of the Sprint Backlog, while still ensuring progress towards the Product Goal.