10 Jul
2012
10 Jul
'12
5:05 p.m.
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?
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
10 Jul
10 Jul
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-----
7:26 p.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11 Jul
11 Jul
5:16 p.m.
Hi,
On Tue, Jul 10, 2012 at 12:26 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Christian,
On Tue, Jul 10, 2012 at 07:04:35PM +0200, Christian Daniel -- maintech
GmbH wrote:
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?
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.
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.
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.
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.
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
4330
days inactive
4331
days old
3 comments
3 participants
participants (3)
-
Christian Daniel -- maintech GmbH -
Harald Welte -
Sandor Szilvasi