Re: [Discuss-gnuradio] SSRP update

[Eric Blossom]

On Wed, Jun 16, 2004 at 09:51:49PM -0500, David Carr wrote:
> A quick update on my progress today.  I apologize if I'm flooding the 
> list with my traffic but I hope that what I'm doing is of some interest.

Keep sending stuff!

> Thanks to Eric's help and a good night's sleep I was finally able to 
> get some basic LED flashing code running.  At first I was using the 
> Cypress supplied fx2regs.h but apparently it does not correctly define 
> the SFRs for use with sdcc.

Hence, the use of our fx2regs.h...  ;-)

As you've probably noticed by now we don't use any cypress provided
code.  Partly because some of it doesn't work, and partly because
their license prohibits redistributing the source.  firmware/lib has
sdcc compatible versions of everything that we found useful.


> More interesting is that the SFR 
> definitions are just silently borked---leading to great frustration on 
> my part.  A switch to the usrpregs.h include solved my I/O port access 
> issues.  From this point I'd like to get some basic firmware that will 
> put the GPIF into 16 bit mode and then just setup an endpoint that will 
> just continuously crank out IN data.  

A few words to the wise: Getting the GPIF to work is non-trivial.  In
fact, there are some undocumented bugs in the chip in this area.  
I highly recommend a logic analyzer so that you can see what you're
really getting.  We use the cypress gpif microprogram generator tool
(I forget what it's called), then post-process it's output to get
something that works for us.  Our source file for the cypress tool is
firmware/src/common/gpif.gpf.  Their tool generates gpif.c, then we
generate usrp_gpif.c and usrp_gpif_inline.h from it.

We configure the GPIF for "blistering fast, with bugs mode" using the
96 MB/sec "flow_state" mode.  In your case, you may want to try
something less bleeding edge.  We work around the bugs in the FPGA,
and it's not pretty.


> Hopefully I'll have this working 
> in a few days.  Some of the USRP code should be helpful here as well.  
> I'm not quite sure of all the steps required to do this yet, but with 
> enough reading and maybe a little help I'll get there.

Great.  Keep us posted.


Other sdcc landmines: Right now, with our current setup, initialized
data in the external data segment (XDAT) is properly initialized.
HOWEVER, initialized data in the 128 bytes of directly addressed DSEG
is NOT PROPERLY INITIALIZED.  The problem is that the default sdcc
memory initialization code doesn't work on the fx2 (different
definitely of the external page register).  The suggested work around
is to provide your own init code (__sdcc_external_startup, contained
in _startup.a51).  However, it only handles the XDAT segment.  Contact
me off list if you want some ideas for a brittle fix for this.  My
current work-around is to manually initialize the DSEG globals that
matter in main.

> On another front, I've changed my ADC design to use the Linear 
> Technology LTC1746 instead of a Maxim MAX1422  The new converter is 
> 14bit 25Msps instead of the previous 12bit 20Msps.  This converter also 
> comes in 48 SSOP instead of 48 TQFP which should make hand-soldering 
> and board production easier.  I plan to run the converter at 12Msps or 
> 15Msps.  The determining factor here is how much bandwidth I can 
> squeeze out of the bus.  (I have the Intel 82801DB ICH4 controller).

I have that controller too.  I sustain 32MB/sec.

Also, I hear that the VIA and Philips based PCI USB2 controllers work
well too.  I picked up a no-name (Syba) VIA based board from Fry's, but
haven't tested it yet.
 
> I placed a sample request for the converter today and I should begin the 
> schematic design and board layout relatively soon.  One thing I'm not 
> sure of is whether or not I need to use a latch inbetween the GPIF bus 
> and the converter outputs.  The ADC datasheet says that the outputs 
> should not drive more than 10pF of load capacitance and that a latch is 
> recommended but I'd really like to avoid the additional complexity.  
> Does anyone have any experience here?

I haven't looked at the LC data sheet, but the Cypress data sheet
says that the worst case input capacitance is 10pF.  I'd probably
leave the latch out.  You'll have enough GPIF timing problems without
the latch.

> Finally, I've decided to call the device the Simple Software Radio 
> Peripheral because it reflects my design goal of creating something 
> that trades some of the USRP's capability for reduced costs yet still 
> remains useful.  Hopefully the USRP folks don't have any objections to 
> this. 

Fine by me.

> Thanks again for your time and for your input,
> David Carr

You're welcome!
Eric