Reply by Harland Christofferson●January 21, 20052005-01-21
Jeff,
Well, we're committed to this design and it is off for UL testing
and certification.
Harland
At Thursday, 20 January 2005, Jeff Brower <>
wrote:
>Harland-
>
>> i think you're right about the /3 counter not working out well.
i
>> didn't put a lot of thought into the idea.
>>
>> as far as the mcbsp and muxing, we did think about it but, at the
>> time, we were under some time pressure and it was almost a
no-brainer
>> to "waste" all of the mcbsp peripherals than to think about
muxing
>> them. i think there was a bandwidth issue as well b/c we have 6 channels >> @ 44.1Kbps.
>
>6 x 44.1 x 24-bit samples... about 6 Mbps. 12 Mbps with status words... would be >cake for a McBSP. Well, there will come a day when
you are saying "if we just had >another McBSP" :-)
>
>-Jeff
>
----------------------------------
Zero Crossings, Inc. -- Embedded and Digital Signal Processing Systems
> i think you're right about the /3 counter not
working out well. i
> didn't put a lot of thought into the idea.
>
> as far as the mcbsp and muxing, we did think about it but, at the
> time, we were under some time pressure and it was almost a no-brainer
> to "waste" all of the mcbsp peripherals than to think about
muxing
> them. i think there was a bandwidth issue as well b/c we have 6 channels
> @ 44.1Kbps.
6 x 44.1 x 24-bit samples... about 6 Mbps. 12 Mbps with status words... would
be
cake for a McBSP. Well, there will come a day when you are saying "if we
just had
another McBSP" :-)
-Jeff
> At Wednesday, 19 January 2005, Jeff Brower
<>
> wrote:
>
> >Harland-
> >
> >> i think you can get a cheaper solution than an fpga. b/c we
couldn't
> >> fine tdm codecs that would sample @ 44.1KHz for the mcbsp end
of
> >> things, we used non tdm, stereo codecs (one per mcbsp).
> >
> >Yep. We previously used CS4218 but new CS (and TI) devices seem
> to lack TDM modes.
> >That's a good reason to use McASP if possible.
> >
> >> b/c of the
> >> serial bitclock and frame sync issues w/ these codecs, we used
a
> >> counter (74vhc163) to be the master for the serial bit clock
and
> >> frame sync generation. the long and the short of it is that it
was
> >> cheap, cheap, cheap, and it works, works, works.
> >
> >Yes that's workable, but I hate the idea of giving up a
valuable
> McBSP -- did you try
> >running the counter at 2x rate, running codecs on lsb, and using
> some circuitry to
> >mux data?
> >
> >> you can probably
> >> get away w/ something similar for the emif timing using the
300MHz
> >> DSP clock.
> >
> >Maybe the simple thing to try first is a counter to generate ECLKIN
> as CLKOUT3/3.
> >But I'm going to bet that won't work, otherwise /3 would be
an onchip
> DSP option.
> >There's always a reason. Feature, not bug.
> >
> >-Jeff
> >
> >> At Tuesday, 18 January 2005, Jeff Brower <>
> wrote:
> >>
> >> >Dileepan-
> >> >
> >> >> yes, it is possible to give the ECLKIN a clock of
> >> >> 100MHz as per the latest data sheet page no.58.
> >> >>
> >> >> but as mentioned here, the synchronisation is an
> >> >> issue. The ECLKIN need to keep the timing between
> >> >> ECLKOUT1 and ECLKOUT2 as shown in figures 5.6 and 5.7.
> >> >>
> >> >> Note that even the rising edge matching of ECLKIN and
> >> >> ECLOUT1 or 2 is not allowed as there exits a minimum
> >> >> delay of 3ns between the rising edges.
> >> >>
> >> >> Another problem is the stringent timings for the
> >> >> ECLKIN itself as mentioned in table 5-6.
> >> >>
> >> >> If you can somehow ensure that these 2 timings are
> >> >> matched, there should not be any issue in interfacing.
Reply by Harland Christofferson●January 20, 20052005-01-20
jeff,
i think you're right about the /3 counter not working out well. i
didn't put a lot of thought into the idea.
as far as the mcbsp and muxing, we did think about it but, at the
time, we were under some time pressure and it was almost a no-brainer
to "waste" all of the mcbsp peripherals than to think about muxing
them. i think there was a bandwidth issue as well b/c we have 6 channels
@ 44.1Kbps.
At Wednesday, 19 January 2005, Jeff Brower <>
wrote:
>Harland-
>
>> i think you can get a cheaper solution than an fpga. b/c we
couldn't
>> fine tdm codecs that would sample @ 44.1KHz for the mcbsp end of
>> things, we used non tdm, stereo codecs (one per mcbsp).
>
>Yep. We previously used CS4218 but new CS (and TI) devices seem to lack TDM modes. >That's a good reason to use McASP if
possible.
>
>> b/c of the
>> serial bitclock and frame sync issues w/ these codecs, we used a
>> counter (74vhc163) to be the master for the serial bit clock and
>> frame sync generation. the long and the short of it is that it was
>> cheap, cheap, cheap, and it works, works, works.
>
>Yes that's workable, but I hate the idea of giving up a valuable McBSP -- did you try >running the counter at 2x rate, running codecs on
lsb, and using some circuitry to >mux data?
>
>> you can probably
>> get away w/ something similar for the emif timing using the 300MHz
>> DSP clock.
>
>Maybe the simple thing to try first is a counter to generate ECLKIN as CLKOUT3/3. >But I'm going to bet that won't work,
otherwise /3 would be an onchip DSP option. >There's always a reason. Feature, not bug.
>
>-Jeff
>
>> At Tuesday, 18 January 2005, Jeff Brower <> wrote: >>
>> >Dileepan-
>> >
>> >> yes, it is possible to give the ECLKIN a clock of
>> >> 100MHz as per the latest data sheet page no.58.
>> >>
>> >> but as mentioned here, the synchronisation is an
>> >> issue. The ECLKIN need to keep the timing between
>> >> ECLKOUT1 and ECLKOUT2 as shown in figures 5.6 and 5.7.
>> >>
>> >> Note that even the rising edge matching of ECLKIN and
>> >> ECLOUT1 or 2 is not allowed as there exits a minimum
>> >> delay of 3ns between the rising edges.
>> >>
>> >> Another problem is the stringent timings for the
>> >> ECLKIN itself as mentioned in table 5-6.
>> >>
>> >> If you can somehow ensure that these 2 timings are
>> >> matched, there should not be any issue in interfacing.
>
> o To
----------------------------------
Zero Crossings, Inc. -- Embedded and Digital Signal Processing Systems
> i think you can get a cheaper solution than an
fpga. b/c we couldn't
> fine tdm codecs that would sample @ 44.1KHz for the mcbsp end of
> things, we used non tdm, stereo codecs (one per mcbsp).
Yep. We previously used CS4218 but new CS (and TI) devices seem to lack TDM
modes.
That's a good reason to use McASP if possible.
> b/c of the
> serial bitclock and frame sync issues w/ these codecs, we used a
> counter (74vhc163) to be the master for the serial bit clock and
> frame sync generation. the long and the short of it is that it was
> cheap, cheap, cheap, and it works, works, works.
Yes that's workable, but I hate the idea of giving up a valuable McBSP --
did you try
running the counter at 2x rate, running codecs on lsb, and using some circuitry
to
mux data?
> you can probably
> get away w/ something similar for the emif timing using the 300MHz
> DSP clock.
Maybe the simple thing to try first is a counter to generate ECLKIN as
CLKOUT3/3.
But I'm going to bet that won't work, otherwise /3 would be an onchip
DSP option.
There's always a reason. Feature, not bug.
-Jeff
> At Tuesday, 18 January 2005, Jeff Brower <>
wrote:
>
> >Dileepan-
> >
> >> yes, it is possible to give the ECLKIN a clock of
> >> 100MHz as per the latest data sheet page no.58.
> >>
> >> but as mentioned here, the synchronisation is an
> >> issue. The ECLKIN need to keep the timing between
> >> ECLKOUT1 and ECLKOUT2 as shown in figures 5.6 and 5.7.
> >>
> >> Note that even the rising edge matching of ECLKIN and
> >> ECLOUT1 or 2 is not allowed as there exits a minimum
> >> delay of 3ns between the rising edges.
> >>
> >> Another problem is the stringent timings for the
> >> ECLKIN itself as mentioned in table 5-6.
> >>
> >> If you can somehow ensure that these 2 timings are
> >> matched, there should not be any issue in interfacing.
Reply by Harland Christofferson●January 19, 20052005-01-19
i think you can get a cheaper solution than an fpga. b/c we couldn't
fine tdm codecs that would sample @ 44.1KHz for the mcbsp end of
things, we used non tdm, stereo codecs (one per mcbsp). b/c of the
serial bitclock and frame sync issues w/ these codecs, we used a
counter (74vhc163) to be the master for the serial bit clock and
frame sync generation. the long and the short of it is that it was
cheap, cheap, cheap, and it works, works, works. you can probably
get away w/ something similar for the emif timing using the 300MHz
DSP clock.
At Tuesday, 18 January 2005, Jeff Brower <> wrote:
>Dileepan-
>
>> yes, it is possible to give the ECLKIN a clock of
>> 100MHz as per the latest data sheet page no.58.
>>
>> but as mentioned here, the synchronisation is an
>> issue. The ECLKIN need to keep the timing between
>> ECLKOUT1 and ECLKOUT2 as shown in figures 5.6 and 5.7.
>>
>> Note that even the rising edge matching of ECLKIN and
>> ECLOUT1 or 2 is not allowed as there exits a minimum
>> delay of 3ns between the rising edges.
>>
>> Another problem is the stringent timings for the
>> ECLKIN itself as mentioned in table 5-6.
>>
>> If you can somehow ensure that these 2 timings are
>> matched, there should not be any issue in interfacing.
> ----------------------------------
Zero Crossings, Inc. -- Embedded and Digital Signal Processing Systems
> yes, it is possible to give the ECLKIN a clock
of
> 100MHz as per the latest data sheet page no.58.
>
> but as mentioned here, the synchronisation is an
> issue. The ECLKIN need to keep the timing between
> ECLKOUT1 and ECLKOUT2 as shown in figures 5.6 and 5.7.
>
> Note that even the rising edge matching of ECLKIN and
> ECLOUT1 or 2 is not allowed as there exits a minimum
> delay of 3ns between the rising edges.
>
> Another problem is the stringent timings for the
> ECLKIN itself as mentioned in table 5-6.
>
> If you can somehow ensure that these 2 timings are
> matched, there should not be any issue in interfacing.
Thanks for the suggestions. Initially we will run 75 MHz using CPU clock/4, but
we
are leaving ECLKIN as a test-point so we can attempt 100 MHz at some future
point.
It sounds like one method might be to run ECLKOUTn, 100 MHz clock, and /CEn
signals
into an FPGA, then use a state-machine to "adjust" ECLKIN signal and
give to DSP.
Although in our low cost design, there is no FPGA, so we will have to think
of
something else :-)
-Jeff
> --- Jeff Brower <> wrote:
>
> > All-
> >
> > We are doing a C5502 design, with emphasis on low
> > cost. One issue that we still have
> > not resolved is EMIF clock rate -- we would normally
> > use 7 or 8 nsec external SRAM,
> > and try to get as close to 100 MHz EMIF clock rate
> > as possible. But C5502 running at
> > 300 MHz naturally provides only 75 MHz rate.
> >
> > My question is: has anyone tried used 100 MHz
> > external EMIF clock? Or is it better
> > to stick with 75 MHz rate, generated from internal
> > clock?
> >
> > -Jeff
> >
>
> __________________________________________________
>
Reply by Jeff Brower●January 18, 20052005-01-18
Harland-
> we're using the 5502 @ 200MHz CPU clock and
100MHz internal EMIF
> clock. all of our external devices are async and much slower than
> your sync. devices.
>
> i assume your question is due to the 100MHz clock not being easily
> obtained internally at 300MHZ
Yes.
> (again, an assumption, it is late,
> and i am too lazy to look at the data sheet) so perhaps there are
> jitter timing issues?
Well... under section 3.10.3, EMIF Input Clock Selection, the C5502 data sheet
says
"The data throughput performance may be degraded due to synchronization
issues when
an external clock source is used for the EMIF."
I'm guessing the same thing that made TI not provide a /3 option to get 100
MHz is
causing them to say this, but they don't want to be specific about it. It
seems that
at 300 MHz CPU clock, the fastest EMIF rate they support is 75 MHz, although in
all
the documents I've read, they don't come out and just say it.
-Jeff
> At Monday, 17 January 2005, Jeff Brower <>
wrote:
>
> >All-
> >
> >We are doing a C5502 design, with emphasis on low cost. One issue
> that we still have
> >not resolved is EMIF clock rate -- we would normally use 7 or 8
> nsec external SRAM,
> >and try to get as close to 100 MHz EMIF clock rate as possible.
> But C5502 running at
> >300 MHz naturally provides only 75 MHz rate.
> >
> >My question is: has anyone tried used 100 MHz external EMIF clock?
> Or is it better
> >to stick with 75 MHz rate, generated from internal clock?
> >
> >-Jeff
Reply by Dileepan C●January 18, 20052005-01-18
hi,
yes, it is possible to give the ECLKIN a clock of
100MHz as per the latest data sheet page no.58.
but as mentioned here, the synchronisation is an
issue. The ECLKIN need to keep the timing between
ECLKOUT1 and ECLKOUT2 as shown in figures 5.6 and 5.7.
Note that even the rising edge matching of ECLKIN and
ECLOUT1 or 2 is not allowed as there exits a minimum
delay of 3ns between the rising edges.
Another problem is the stringent timings for the
ECLKIN itself as mentioned in table 5-6.
If you can somehow ensure that these 2 timings are
matched, there should not be any issue in interfacing.
regards,
Dileepan.
--- Jeff Brower <> wrote:
> All-
>
> We are doing a C5502 design, with emphasis on low
> cost. One issue that we still have
> not resolved is EMIF clock rate -- we would normally
> use 7 or 8 nsec external SRAM,
> and try to get as close to 100 MHz EMIF clock rate
> as possible. But C5502 running at
> 300 MHz naturally provides only 75 MHz rate.
>
> My question is: has anyone tried used 100 MHz
> external EMIF clock? Or is it better
> to stick with 75 MHz rate, generated from internal
> clock?
>
> -Jeff
>
Reply by Harland Christofferson●January 18, 20052005-01-18
we're using the 5502 @ 200MHz CPU clock and 100MHz internal EMIF
clock. all of our external devices are async and much slower than
your sync. devices.
i assume your question is due to the 100MHz clock not being easily
obtained internally at 300MHZ (again, an assumption, it is late,
and i am too lazy to look at the data sheet) so perhaps there are
jitter timing issues?
At Monday, 17 January 2005, Jeff Brower <> wrote:
>All-
>
>We are doing a C5502 design, with emphasis on low cost. One issue that we still have >not resolved is EMIF clock rate -- we would
normally use 7 or 8 nsec external SRAM, >and try to get as close to 100 MHz EMIF clock rate
as possible. But C5502 running at >300 MHz naturally provides only 75 MHz rate.
>
>My question is: has anyone tried used 100 MHz external EMIF clock? Or is it better >to stick with 75 MHz rate, generated from internal
clock?
>
>-Jeff
>
----------------------------------
Zero Crossings, Inc. -- Embedded and Digital Signal Processing Systems
We are doing a C5502 design, with emphasis on low cost. One issue that we still
have
not resolved is EMIF clock rate -- we would normally use 7 or 8 nsec external
SRAM,
and try to get as close to 100 MHz EMIF clock rate as possible. But C5502
running at
300 MHz naturally provides only 75 MHz rate.
My question is: has anyone tried used 100 MHz external EMIF clock? Or is it
better
to stick with 75 MHz rate, generated from internal clock?