Strong RNG for encryption/authentation algo I saw in the market several hardware options for creating strong RNG to produce strong KEYS:


HSM 
TPM internal TRNG
Intel RDSEED (TRNG)/RDRAND


My questions are;


What is the strength/entropy difference between them? (using intel RDSEED is much lower cost than buying an HSM)
Why feeding TRNG seed (like RDSEED) into the PRNG mechanism (RDRAND)? doesn't that lower its strength? 
Cant I use RDSEED for creating a key (using KDF) without RDRAND?
RDRAND/RDSEED is the focus of all three of your questions here.  If you're looking for truly random numbers (as indicated by the trng tag),   it's probably worth realising that there is substantial anecdotal and circumstantial evidence that RDRAND/RDSEED isn't a TRNG.  Have a look at my analysis from another question, specifically item 10. That indicates that it's not just me spouting weirdo conspiracy theories.

Since my analysis discourages the cheap Intel approach, you're left with TPMs and HSMs. Clearly a HSM costs waay more than a TPM.  You could argue that a HSM might be more secure/reliable as they tend to be build to international standards like FIPS and commonly accepted in security scenarios. 

The entropies should be identical at 8 bits/byte, but I also offer this warning.  How do you know? Computational indistinguishability means that you can't differentiate even a simple construct like $E_k(pepper||time)$ from a truly random sequence. And both hardware are designed tamper resistant, which means that you can't personally audit them. So similarly, look at this TPM criticism.

It's a tough choice as a lot of what applies to my RDRAND/RDSEED thesis also applies to TPMs and HSMs. 

As for the remaining two parts:-


Yes, feeding a PRNG from a TRNG seed does lower the mathematical strength of the output. A caveat though is that as long as you create your 128/256 bits of initial Kolmogorov randomness, it should be sufficient for most cryptographic purposes. It just means that the output entropy is no longer truly random. Those 128/256 bits remain a constant no matter the output length. Till you re-seed. This is what occurs inside *nix's \dev\urandom, just using other entropy sources.
RDSEED's raison d'être is key creation and seeding.  If you believe that the output entropy is real, then all you have to do is acquire it.  You get it in batches of 16 - 64 bits via registers. It's a bit dry, but instructions are here.  No KDF is required as it should be truly random at 8 bits/byte and therefore perfectly secure. A KDF is indicated when going from a password to a key.