In this book both Table Based methods and Cordic iterations are explained. computationally speaking i suppose the Table based is usually faster, even though it probably requires more resource, while Cordic is probably slower, but probably less resource consuming (if my understanding is correct, it should be a specific instance of shift and adds algorithm). But are there other benefits/drawback in both approach? I suppose also the CORDIC doesn't suffer of the table maker dilemma, even though it in general requires a LUT.
By reconfiguring the adders between registers slightly, the basic CORDIC hardware can compute rotations, inverse rotations, reciprocals, and a whole bunch of others. As there are few coefficients, the algorithm can be laid out from multiple iterations using serial registers (very slow and very small) to multiple ranks of wide registers in a pipeline (one result per system clock cycle, big and fast) and all tradeoffs in between.
Throwing a few more bits on for extra accuracy is straightforward, it takes another cycle per bit, and a linear increase in coefficient and working storage. Doing the same with a table based approach could require a polynomial increase in the size of the tables.
These days when most FPGAs have dedicated multipliers, the decision which to employ might often be taken by what mix of resource you have left nearing the end of the design. If there are some spare multipliers, then use Taylor series or similar because more people know about that and it's easy to synthesise. If none then implement CORDIC in the fabric.
Maybe you are missing the advantage of CORDIC vs. look up table which is the fact that the effort grows only logarithmically with accuracy with CORDIC (runtime) vs. linearly with lookup tables (size).
I.e. if you want increase accuracy from \$n\$ bits to \$n+1\$ bits
- with CORDIC you just have to do another step vs.
- with lookup table you need a table that has twice the size.