Hi OsmoCom,
I was going to start a home project *very similar* to yours, when I bumped into the OsmoSDR. So, I'd like to ask a few questions regarding the OsmoSDR hardware.
1. Based on the photohttp://sdr.osmocom.org/trac/chrome/common/download.pngyour fab could handle BGA packages. Why didn't you use the BGA packaged Atmel SAM3U MCU instead of the LQFP one? 2. The Lattice LatticeXP2 FPGA is available in the same package but in larger size at almost identical price. Why did you pick the smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E ($20)? 3. You are using the SAM3U SSC to transfer data from the FPGA. Before seeing your design I had the idea to use the EBI to interface with the FPGA. After all, the EBI is on the AHB and I assume you have a bunch of FPGA I/Os left. What do you think the drawbacks of using the EBI would be? 4. The differential clock output oscillator was connected in a weird way, but I can see that it has been corrected in Rev 2. 5. My understanding is that you configure the FPGA using the JTAG lines in bit-bang mode through SAM3U GPIOs. Why don't you use the sysConfig port of the Lattice FPGA? It's faster, easier to implement with the SAM3U SPI peripheral (and it's also a feature I haven't seen with other FPGAs). See Lattice TN1141 http://www.latticesemi.com/documents/TN1141.pdf. 6. The board seems to be powered from the USB only, but the oscillator already draws ~100mA and it's always enabled. Adding the consumption of the MCU and the FPGA you are already above 100mA. If it's really powered only from the USB, how is it ensured that you stay below the 100mA limit specified by the USB standard until you ask for a higher current, say 500mA?
I hope you didn't mind my questions above, I didn't mean to be nosy. I just got a little excited about this project.
Cheers,
Sandor
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Sandor,
I'll write my answers directly into your mail:
On 10.07.2012 17:05, Sandor Szilvasi wrote:
Hi OsmoCom,
I was going to start a home project /very similar/ to yours, when I bumped into the OsmoSDR. So, I'd like to ask a few questions regarding the OsmoSDR hardware.
- Based on the photo
http://sdr.osmocom.org/trac/chrome/common/download.png your fab could handle BGA packages. Why didn't you use the BGA packaged Atmel SAM3U MCU instead of the LQFP one?
That was an option, but we decided to go for a part with actual pins because these are easier to debug and we had the space (at the time).
- The Lattice LatticeXP2 FPGA is available in the same package but
in larger size at almost identical price. Why did you pick the smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E ($20)?
Because it was on stock and is big enough for the task at hand.
- You are using the SAM3U SSC to transfer data from the FPGA.
Before seeing your design I had the idea to use the EBI to interface with the FPGA. After all, the EBI is on the AHB and I assume you have a bunch of FPGA I/Os left. What do you think the drawbacks of using the EBI would be?
The SSC is too slow to handle the full 4MHz bandwith - a problem we only discovered after the first prototypes were built. We're currently investigating a redesign to switch to EBI.
- The differential clock output oscillator was connected in a
weird way, but I can see that it has been corrected in Rev 2.
Yep, embarrassing mistake that...
- My understanding is that you configure the FPGA using the JTAG
lines in bit-bang mode through SAM3U GPIOs. Why don't you use the sysConfig port of the Lattice FPGA? It's faster, easier to implement with the SAM3U SPI peripheral (and it's also a feature I haven't seen with other FPGAs). See Lattice TN1141 http://www.latticesemi.com/documents/TN1141.pdf.
Good point. Well - the current method works well and is fast (about 30 seconds to flash via USB). No need to change it again... My guess is, that it won't get much faster since the bottleneck is USB and flash write time. Perhaps we'll have to change it when we switch to EBI to free some SAM3U pins.
- The board seems to be powered from the USB only, but the
oscillator already draws ~100mA and it's always enabled. Adding the consumption of the MCU and the FPGA you are already above 100mA. If it's really powered only from the USB, how is it ensured that you stay below the 100mA limit specified by the USB standard until you ask for a higher current, say 500mA?
We violate the 100mA limit by a small amount. FPGA and E4K can be switched off and the ADC doesn't consume much when no clock is applied. I don't see a problem here - at least after we fixed the power sequence to stop it from using the full 400mA directly on power up. Also a diode for external power supply is on the board. But yes - it will not be USB certified. But so far this is not a real-world problem.
I hope you didn't mind my questions above, I didn't mean to be nosy. I just got a little excited about this project.
Just keep on asking - this is open hardware and open software and the more the merrier!
Cheers,
Sandor
Cheers, Christian
- -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 · D-97204 Höchberg | - --------------------------------------------------- | AG Würzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd@maintech.de | - ---------------------------------------------------
Hi Christian,
On Tue, Jul 10, 2012 at 07:04:35PM +0200, Christian Daniel -- maintech GmbH wrote:
We violate the 100mA limit by a small amount. FPGA and E4K can be switched off and the ADC doesn't consume much when no clock is applied. I don't see a problem here - at least after we fixed the power sequence to stop it from using the full 400mA directly on power up. Also a diode for external power supply is on the board. But yes - it will not be USB certified. But so far this is not a real-world problem.
Actually, now that you're doing a re-design for the SSC -> EBI change, it might be an idea to make the oscillator power supply switchable and controlled by a GPIO from the SAM3U or FPGA. At that point, there's no problem booting at < 100mA.
I wouldn't expect a small low-Rds_on mosefet switch to cause any problem for the oscillator, especially since it's constant current/power...
Regards, Harald
Hi,
On Tue, Jul 10, 2012 at 12:26 PM, Harald Welte laforge@gnumonks.org wrote:
Hi Christian,
On Tue, Jul 10, 2012 at 07:04:35PM +0200, Christian Daniel -- maintech GmbH wrote:
We violate the 100mA limit by a small amount. FPGA and E4K can be switched off and the ADC doesn't consume much when no clock is applied. I don't see a problem here - at least after we fixed the power sequence to stop it from using the full 400mA directly on power up. Also a diode for external power supply is on the board. But yes - it will not be USB certified. But so far this is not a real-world
problem.
Actually, now that you're doing a re-design for the SSC -> EBI change, it might be an idea to make the oscillator power supply switchable and controlled by a GPIO from the SAM3U or FPGA. At that point, there's no problem booting at < 100mA.
The Si570 has an OE pin, but even in tri-state mode it still consumes ~60mA. So, I second Harald: it makes sense to have an option to make the oscillator power supply switchable and to keep the overall consumption (including the RF IC, ADC, FPGA, TCXO and MCU) below 100mA until higher currents are negotiated. Connect the switch input to a SAM3U I/O rather than one of the FPGA.
By the way, the FPGA seems to have only one clock input, 'CLKPO'. Is this the case?
- The Lattice LatticeXP2 FPGA is available in the same package but
in larger size at almost identical price. Why did you pick the smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E ($20)?
Because it was on stock and is big enough for the task at hand.
It can never be too big for a prototype. :) The two models ought to be pin-compatible, so the upgrade might be worth it if the LFXP-8E is available.
- My understanding is that you configure the FPGA using the JTAG
lines in bit-bang mode through SAM3U GPIOs. Why don't you use the sysConfig port of the Lattice FPGA? It's faster, easier to implement with the SAM3U SPI peripheral (and it's also a feature I haven't seen with other FPGAs). See Lattice TN1141 http://www.latticesemi.com/documents/TN1141.pdf.
Good point. Well - the current method works well and is fast (about 30 seconds to flash via USB). No need to change it again... My guess is, that it won't get much faster since the bottleneck is USB and flash write time. Perhaps we'll have to change it when we switch to EBI to free some SAM3U pins.
The other advantage of using the sysConfig Port is that you can save the JTAG lines for a pin header. If the pin header is compatible with the Lattice programmer, you might be able to use the Lattice's ChipScope equivalent for debugging the FPGA.
Cheers,
Sandor
-
Christian Daniel -- maintech GmbH -
Harald Welte -
Sandor Szilvasi