This is normal. You must also specify a fairness property (constraint) that tells the tool to eventually assert whatever input the design is waiting for. In you case I guess that's either ready_i or ready_frame_i, if those are the correct primary inputs.
-- psl assume always ( eventually! (ready_i ='1' or ready_frame_i = '1') );
It sounds like the tool is working as it should. For a property to fail, it only takes a single example in which it turns out to be untrue, no matter how many other scenarios exist in which it is true. From the code you've shown, if ready_frame never goes high and if ready_i and busy_s never take on the correct states, the state machine will stay in the idle state forever.
Usually you need a kind of condition called a "fairness constraint" to ensure that a liveness property does not get stuck in an infinite loop waiting for something to occur. A fairness constraint says that something will occur eventually if you wait long enough. For your example, you may need to add a constraint such as:
-- psl ready_frame_fairness: assume always ( eventually! (ready_frame = '1') );