I don't know what you mean by "UWB" (use standard or common abbreviations, no I'm not going to look it up, it's your job to explain), but many many micros have 10 bit A/Ds and SPI hardware. Even without the SPI hardware, SPI is simple to do in firmware by controlling the I/O lines directly.
In the Microchip line, there is a wide spectrum that meet these requirements. A low end PIC 16 can be small, cheap, and very low power. A fast dsPIC33 can run up to 40 MIPS but of course will use more power. There are various PIC 18 and PIC 24 in between.
What you need to explain is how fast you need to sample the 10 bit A/D and what the micro needs to do to these 10 bit values before passing them on via SPI.
This "answer" is more of a comment because too much important information is lacking. It can be turned into a answer if you cooperate and answer the specific questions asked, not what you feel like answering or or you think is important. As it stands, this question is too vague to be reasonably answered and should be closed. People will come by and close it as they encounter it. When 5 close votes are cast, it's over. The clock is ticking. You may have only minutes to a few hours. Do what I said exactly as I said quickly and you may get your answer. Ignore it and not cooperate and you'll be sent home without a cookie.
Added:
You have now added that the A/D sample rate is 500 kHz and that this raw A/D data is to be passed on via SPI. Since the A/D is 10 bits, this is apparently where you got the 5 Mb/s SPI data requirement from.
This is doable, but will require a reasonably high end micro. The limiting factor is the 10 bit A/D at 500 kHz sample rate. That's quite fast for a micro, so that limits the available options. Another thing to consider is that there is more to SPI than just sending the bits. Bytes may need to be transferred in chunks with chip select asserted and de-asserted per chunk. For example, how will this 10 bit data be packed into 8 bit bytes, or will it at all?
The main operating loop of the firmware will be quite simple. You probably set up the A/D to do automatic periodic conversions and interrupt every 2µs with a new value. Now you've got most of 2µs to send it out the SPI. If the device really can just accept a stream of bits, then it might be easier to do the SPI in firmware. Most SPI hardware wants to send 8 or 16 bits at a time. You'd have to buffer bits and send a 16 bit word 5 out of every 8 interrupts. It might be easier to just send 10 bits each interrupt in firmware.
Sending SPI bits in firmware if you only need to control clock and data out is pretty easy. Per bit, you have to:
- Write bit value to data line.
- Raise clock
- Lower clock
It would make sense to unroll this loop with preprocessor logic or something. A PIC 24H can run at up to 40 MIPS, so you have 80 instructions per interrupt. Obviously you can't use 8 instructions to send each bit. If you can do it in 6 it should work. There is some overhead to get into and out of each interrupt, so you might make the whole thing a polling loop waiting for the A/D, but then the processor can't do anything else. I'd probably try to cram this into the A/D interrupt routine using every possible trick so that at least a few forground cycles are left over for background tasks like knowing when to stop, etc.
Check out the Microchip PIC 24H line. I think most if not all have A/Ds that can do 500 kbit/s, and they can all run at least up to 40 MIPS. The new E series is even faster, but I'm not sure how real that is yet.
There are dozens of different programmers, but they all fall into one or more of these categories:
JTAG. any JTAG programmer can program any device (not just AVRs, and not even just micros) that accepts JTAG. I have several JTAG programmers (Olimex AVR-JTAG-USB, Terasic's Blaster, Abatron BDI2000). Requires 4 or 5 lines.
PDI. AVR-specific, 2-wire protocol for programming and debugging. Many AVR programmers support PDI (Dragon, AVRISP, JTAGMkII, etc.)
ISP. AVR-specific, 5 wire protocol built on top of SPI. Most AVR programmers support this and I believe that every AVR supports this. The bus pirate also works as an AVR ISP programmer.
HVPP. This mode uses a lot of pins and uses 12V to program the device (as opposed to the normal 1.8-5V supply). I have never used this.
HVISP. AVR-specific 5 wire protocol which can be used on the ATTiny parts or other AVRs which have had their reset pin disabled. Uses 12V like HVPP, but with much fewer pins. The Dragon is one of very few programmers which support this option.
TPI. I don't know much about this method, it looks very similar to PDI to me. Used on the ATTiny devices.
For my own stuff, I use JTAG or ISP since they both work well in-circuit, but on a recent design I am using the ATTiny13A and need every pin, so I use a Dragon and HVISP for that design. HVISP isn't really meant for in-circuit programming and there are some caveats that I've had to incorporate into the design to make it work.
Which programmer is right for you? Look around for an inexpensive USB ISP programmer with a case. Get a Dragon if you really need the HV programming modes, but you probably don't need them at this point. Digikey or Mouser are the usual sources but you can build your own, use ebay or any number of sites like ladyada or sparkfun. Definitely don't spend more than $50, you can get the Dragon for $56 from Digikey.
You want a case to protect the programmer because one thing you don't want to is to start guessing whether it's your design or the programmer that's causing you grief. :-)
Edit 1
Which programmer to use for AVR32 and XMEGA? Both can use JTAG, so I'd look for a JTAG programmer. JTAG programmers can be built out of pretty much anything, there are homebrew/"free" designs available, and you could even make one out of a parallel port. I suggest looking at something like a AVR-JTAG-USB or ByteBlaster since they're both about USD$50 and well supported by avrdude (the software which programs AVRs under Linux and OSX), but as I said, any JTAG cable will work. If you're using AVR Studio then I'd check their list of supported programmers (a link to which I could not find, sadly). I know it does support the AVR-JTAG-USB, and I believe Atmel's official recommendation is the JTAGICE3.
You may want to take a look at LadyAda's AVR Tutorial -- the link goes to their "choosing a programmer" section but the whole tutorial is good.
Edit 2
Why the cost disparity between programmers? Features mostly. Some programmers can only do ISP or JTAG. Some programmers only work with a specific VCC, or make assumptions about whether the device you're programming is powered by the programmer or not. Some programmers do not take care to protect themselves against misconnection, or have "dumb" power supplies which don't shut down in the case of short circuits or overcurrent. I already mentioned that most programmers DO NOT support the high voltage (12V) programming that you may need in some cases.
For starting out with XMEGA and AVR32, I'd recommend the Olimex AVR-JTAG-USB or Terasic ByteBlaster as menitoned above. They're reasonably rugged, have level shifters to match the power supply of the device you're going to program, and reasonably priced.
Best Answer
Software Bit bang is possible. Or, Go for SPI with little changes:
Use only MOSI and SCLK of SPI to connect to DAC.
SYNC pin of DAC can be driven low by a GPIO of MCU, while SPI can be configured to transmit data to DAC.
MOSI pin sends out the data in three consecutive writes along with 24 clocks from SCLK.
Assuming CPHASE, CPOL, and LSB First requirements are taken care of in software before initiating the write. Figure 38 in http://www.ti.com/lit/ds/symlink/dac8532.pdf may help.