|
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 |
question about C5502 EMIF clock rate
Started by ●January 17, 2005
Reply by ●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 http://www.zerocrossings.com/ |
Reply by ●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 ●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 ●January 18, 20052005-01-18
|
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. 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 ●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 http://www.zerocrossings.com/ |
Reply by ●January 19, 20052005-01-19
|
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 ●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 http://www.zerocrossings.com/ |
Reply by ●January 20, 20052005-01-20
|
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 > 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 ●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 http://www.zerocrossings.com/ |
