10 Jul
2012
10 Jul
'12
7:04 p.m.
-----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.
1. 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).
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)?
Because it was on stock and is big enough for the task at hand.
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?
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.
4. 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...
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>.
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.
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?
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(a)maintech.de |
- ---------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP/GCdAAoJEHkgzUIsAWri8sgH/RJatmt6EX6azQT3esDoDFGK
OSpFDwcuNpPVthT0VUpFapn3et/HwzoW7ZHUUe0DnAorFY7oNVtEtZfj5AIOIJ4H
aPN1Pw8H+tXTZebxURjr44IGLjavVlUXlDvlzuOuMTcypysjkj8806/KbXi7gLJ0
9NfLwDPv/2kJVi1Ys6FITO1waXz8jC6qzvziGijPlNO3BHOvQecjbINhqmcLzhFO
s7g4FuNZJPMbGu/jT/YG3WkxhAb23ibipS7YA8h/DZa4osgAoEYNcVi58zt4V1yz
cDFBHm9P/a2m3WqEHar8Npd62Eqwi+0UzKoxfHjKVbeAconKQI1Xrkmu2vS9wbw=
=JCC2
-----END PGP SIGNATURE-----