It's very hard to write a converter for that, as the focus of SQL is on sets of field entries, but the focus of the predicates is on specifying filters so a subset of the complete set of objects is returned.
So instead of focussing on SQL, take a step back and define which entities you want to read, e.g.: which filter you should define to read the entities you want to load.
Then build that filter using predicates, by taking into account that each clause in the where section of a SQL statement, like Foo='10', is called a predicate. So by knowing that, you can go back to the manual and for example in the how-do-I section, check for each predicate class if your SQL predicate matches it and thus how to formulate it into code. That should give you a lot of the predicate filters you've to write.
Furthermore, because you now have an object model, you can use that to retrieve entities as well. For example if you have a Customer entity loaded, you can use that customer object to fetch its orders, without specifying any filters. In selfservicing, you can utilize lazy loading: customer.Orders, in Adapter, you can ask the customer object to formulate the filter for you: customer.GetRelationInfoOrders().
You can also fetch a graph in one go, using prefetch paths. For example 10 customers, their orders and order detail objects. This is a path: customer - order - order details. By constructing such a prefetch path, you can then order the generated code to fetch your 10 customers and at the same time their orders and order detail objects by specifying that prefetch path.