On Fri, 28 Sep 2012 00:54:34 +0000, Nico Coesel wrote:

> Tim Wescott <tim@seemywebsite.com> wrote:
> 
>>On Thu, 27 Sep 2012 19:54:08 +0000, Nico Coesel wrote:
>>
>>> Tim Wescott <tim@seemywebsite.com> wrote:
>>> 
>>>>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>>>>
>>>>> "nba83" <3224@embeddedrelated> wrote:
>>>>> 
>>>>>>>On Mon, 24 Sep 2012 06:00:15 -0500 "nba83" <3224@embeddedrelated>
>>>>>>>wrote:
>>>>>>>
>>>>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>>>>> >
>>>>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>>>>> >> about
>>>>>>100
>>>>>>>> >> bytes, and then start to drive SPI Out. I am some how
>>>>>>>> >> concerned
>>>>>>about
>>>>>>>> the
>>>>> 
>>>>> Still, given your project requirements you probably could get by
>>>>> with a small FIFO (maybe 4 bytes deep). You need to get enough data
>>>>> from the microcontroller. OTOH it sounds like a lot of fuss to keep
>>>>> the microcontroller. If you switch to an ARM device (NXP for
>>>>> instance) you can reach >30MHz SPI easely and use DMA.
>>>>
>>>>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to
>>>>need more than 35MHz.
>>> 
>>> I guess ST is still making mediocre controllers. After an adventure
>>> with the STR700 series I switched to NXP and never looked back at ST.
>>> Appearantly a good choice :-)
>>
>>35MHz clock at the peripheral -- the ST chip he's looking at is rated
>>for 70 or 72MHz or some such.
> 
> AFAIK most ST devices can't run from flash at their rated clock speeds.
> NXP's can and some go up to 120MHz (180MHz is on its way)!

Yes, good point.  And part of my point to the OP is that once he solves 
his ADC throughput problem, is he going to be able to generate the data?

Depending on his application, a teeny bit of code running out of RAM in 
the '107 may be enough.  Or, the app may self-destruct on a ton of code 
running at 120MHz on your NXP.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

On Sep 28, 2:54=A0am, n...@puntnl.niks (Nico Coesel) wrote:
> Tim Wescott <t...@seemywebsite.com> wrote:
> >On Thu, 27 Sep 2012 19:54:08 +0000, Nico Coesel wrote:
>
> >> Tim Wescott <t...@seemywebsite.com> wrote:
>
> >>>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>
> >>>> "nba83" <3224@embeddedrelated> wrote:
>
> >>>>>>On Mon, 24 Sep 2012 06:00:15 -0500
> >>>>>>"nba83" <3224@embeddedrelated> wrote:
>
> >>>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>
> >>>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
> >>>>>>> >> about
> >>>>>100
> >>>>>>> >> bytes, and then start to drive SPI Out. I am some how concerne=
d
> >>>>>about
> >>>>>>> the
>
> >>>> Still, given your project requirements you probably could get by wit=
h
> >>>> a small FIFO (maybe 4 bytes deep). You need to get enough data from
> >>>> the microcontroller. OTOH it sounds like a lot of fuss to keep the
> >>>> microcontroller. If you switch to an ARM device (NXP for instance) y=
ou
> >>>> can reach >30MHz SPI easely and use DMA.
>
> >>>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to
> >>>need more than 35MHz.
>
> >> I guess ST is still making mediocre controllers. After an adventure wi=
th
> >> the STR700 series I switched to NXP and never looked back at ST.
> >> Appearantly a good choice :-)
>
> >35MHz clock at the peripheral -- the ST chip he's looking at is rated fo=
r
> >70 or 72MHz or some such.
>
> AFAIK most ST devices can't run from flash at their rated clock
> speeds. NXP's can and some go up to 120MHz (180MHz is on its way)!
>

STM32F4 has a flash accelerator similar to NXP and run at full speed
168MHz

the stm32f107 looks to have 2x I2S that can run at pclk/2 the ad1933
can run
dual line so I think it should be possible

-Lasse

Tim Wescott <tim@seemywebsite.com> wrote:

>On Thu, 27 Sep 2012 19:54:08 +0000, Nico Coesel wrote:
>
>> Tim Wescott <tim@seemywebsite.com> wrote:
>> 
>>>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>>>
>>>> "nba83" <3224@embeddedrelated> wrote:
>>>> 
>>>>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>>>>"nba83" <3224@embeddedrelated> wrote:
>>>>>>
>>>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>>>> >
>>>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>>>> >> about
>>>>>100
>>>>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>>>>about
>>>>>>> the
>>>> 
>>>> Still, given your project requirements you probably could get by with
>>>> a small FIFO (maybe 4 bytes deep). You need to get enough data from
>>>> the microcontroller. OTOH it sounds like a lot of fuss to keep the
>>>> microcontroller. If you switch to an ARM device (NXP for instance) you
>>>> can reach >30MHz SPI easely and use DMA.
>>>
>>>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to
>>>need more than 35MHz.
>> 
>> I guess ST is still making mediocre controllers. After an adventure with
>> the STR700 series I switched to NXP and never looked back at ST.
>> Appearantly a good choice :-)
>
>35MHz clock at the peripheral -- the ST chip he's looking at is rated for 
>70 or 72MHz or some such.

AFAIK most ST devices can't run from flash at their rated clock
speeds. NXP's can and some go up to 120MHz (180MHz is on its way)!

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Thu, 27 Sep 2012 19:54:08 +0000, Nico Coesel wrote:

> Tim Wescott <tim@seemywebsite.com> wrote:
> 
>>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>>
>>> "nba83" <3224@embeddedrelated> wrote:
>>> 
>>>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>>>"nba83" <3224@embeddedrelated> wrote:
>>>>>
>>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>>> >
>>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>>> >> about
>>>>100
>>>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>>>about
>>>>>> the
>>>>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C),
>>>>>> >> it is -10C(means 10nsec delay for IO routs), does this delay
>>>>>> >> impose any
>>>>>> problem?
>>>>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>>>>> >> and
>>>>by
>>>>>> 
>>>>>> 
>>>>>You've written behavioral VHDL that describes a dual-port block RAM.
>>>>>That's lovely and all, but have you checked the CPLD datasheet and
>>>>>confirmed that there is a block RAM resource on the chip that will do
>>>>>that?  You could also write VHDL describing a unicorn, but you'd be
>>>>>hard pressed to make it pass synthesis.
>>>>>
>>>>>--
>>>>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>>>>address domain is currently out of order.  See above to fix.
>>>>>
>>>>>
>>>>I am some how obliged to use XC95144(since I have plenty of them
>>>>purchased before), and as it was mentioned here, I omitted RAM Module
>>>>from my design and instead I would like to add a SRAM or SDRAM
>>>>chip,(and since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and
>>>>here it posed another question and  that is if this CPLD is capable of
>>>>driving a SDRAM (regarding dynamic memory timing constraints)?
>>> 
>>> I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
>>> displays with TFT. The key is to calculate the required bandwidth. In
>>> my most recent project I used a 16 bit SRAM.
>>> 
>>> Still, given your project requirements you probably could get by with
>>> a small FIFO (maybe 4 bytes deep). You need to get enough data from
>>> the microcontroller. OTOH it sounds like a lot of fuss to keep the
>>> microcontroller. If you switch to an ARM device (NXP for instance) you
>>> can reach >30MHz SPI easely and use DMA.
>>
>>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to
>>need more than 35MHz.
> 
> I guess ST is still making mediocre controllers. After an adventure with
> the STR700 series I switched to NXP and never looked back at ST.
> Appearantly a good choice :-)

35MHz clock at the peripheral -- the ST chip he's looking at is rated for 
70 or 72MHz or some such.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Tim Wescott <tim@seemywebsite.com> wrote:

>On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:
>
>> "nba83" <3224@embeddedrelated> wrote:
>> 
>>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>>"nba83" <3224@embeddedrelated> wrote:
>>>>
>>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>>> >
>>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>>> >> about
>>>100
>>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>>about
>>>>> the
>>>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it
>>>>> >> is -10C(means 10nsec delay for IO routs), does this delay impose
>>>>> >> any
>>>>> problem?
>>>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>>>> >> and
>>>by
>>>>> 
>>>>> 
>>>>You've written behavioral VHDL that describes a dual-port block RAM.
>>>>That's lovely and all, but have you checked the CPLD datasheet and
>>>>confirmed that there is a block RAM resource on the chip that will do
>>>>that?  You could also write VHDL describing a unicorn, but you'd be
>>>>hard pressed to make it pass synthesis.
>>>>
>>>>--
>>>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>>>address domain is currently out of order.  See above to fix.
>>>>
>>>>
>>>I am some how obliged to use XC95144(since I have plenty of them
>>>purchased before), and as it was mentioned here, I omitted RAM Module
>>>from my design and instead I would like to add a SRAM or SDRAM chip,(and
>>>since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and here it
>>>posed another question and  that is if this CPLD is capable of driving a
>>>SDRAM (regarding dynamic memory timing constraints)?
>> 
>> I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
>> displays with TFT. The key is to calculate the required bandwidth. In my
>> most recent project I used a 16 bit SRAM.
>> 
>> Still, given your project requirements you probably could get by with a
>> small FIFO (maybe 4 bytes deep). You need to get enough data from the
>> microcontroller. OTOH it sounds like a lot of fuss to keep the
>> microcontroller. If you switch to an ARM device (NXP for instance) you
>> can reach >30MHz SPI easely and use DMA.
>
>He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to 
>need more than 35MHz.

I guess ST is still making mediocre controllers. After an adventure
with the STR700 series I switched to NXP and never looked back at ST.
Appearantly a good choice :-)

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Wed, 26 Sep 2012 23:06:03 +0000, Nico Coesel wrote:

> "nba83" <3224@embeddedrelated> wrote:
> 
>>>On Mon, 24 Sep 2012 06:00:15 -0500
>>>"nba83" <3224@embeddedrelated> wrote:
>>>
>>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>>> >
>>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for
>>>> >> about
>>100
>>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>>about
>>>> the
>>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it
>>>> >> is -10C(means 10nsec delay for IO routs), does this delay impose
>>>> >> any
>>>> problem?
>>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input,
>>>> >> and
>>by
>>>> 
>>>> 
>>>You've written behavioral VHDL that describes a dual-port block RAM.
>>>That's lovely and all, but have you checked the CPLD datasheet and
>>>confirmed that there is a block RAM resource on the chip that will do
>>>that?  You could also write VHDL describing a unicorn, but you'd be
>>>hard pressed to make it pass synthesis.
>>>
>>>--
>>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email
>>>address domain is currently out of order.  See above to fix.
>>>
>>>
>>I am some how obliged to use XC95144(since I have plenty of them
>>purchased before), and as it was mentioned here, I omitted RAM Module
>>from my design and instead I would like to add a SRAM or SDRAM chip,(and
>>since SDRAM is much cheaper than SRAM I'm apt to SDRAM), and here it
>>posed another question and  that is if this CPLD is capable of driving a
>>SDRAM (regarding dynamic memory timing constraints)?
> 
> I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
> displays with TFT. The key is to calculate the required bandwidth. In my
> most recent project I used a 16 bit SRAM.
> 
> Still, given your project requirements you probably could get by with a
> small FIFO (maybe 4 bytes deep). You need to get enough data from the
> microcontroller. OTOH it sounds like a lot of fuss to keep the
> microcontroller. If you switch to an ARM device (NXP for instance) you
> can reach >30MHz SPI easely and use DMA.

He's using an STM32F107 which _is_ an ARM Cortex, and he's claiming to 
need more than 35MHz.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

"nba83" <3224@embeddedrelated> wrote:

>>On Mon, 24 Sep 2012 06:00:15 -0500
>>"nba83" <3224@embeddedrelated> wrote:
>>
>>> >On 09/24/2012 08:09 AM, nba83 wrote:
>>> >
>>> >> I want to feed data in parallel (8bit) to CPLD, buffer it for about
>100
>>> >> bytes, and then start to drive SPI Out. I am some how concerned
>about
>>> the
>>> >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
>>> >> -10C(means 10nsec delay for IO routs), does this delay impose any
>>> problem?
>>> >> Since I want to drive the CPLD with 100MHZ oscillator clk input, and
>by
>>> 
>>
>>You've written behavioral VHDL that describes a dual-port
>>block RAM. That's lovely and all, but have you checked the CPLD
>>datasheet and confirmed that there is a block RAM resource on the chip
>>that will do that?  You could also write VHDL describing a unicorn, but
>>you'd be hard pressed to make it pass synthesis.
>>
>>-- 
>>Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>>Email address domain is currently out of order.  See above to fix.
>>
>
>I am some how obliged to use XC95144(since I have plenty of them purchased
>before), and as it was mentioned here, I omitted RAM Module from my design
>and instead I would like to add a SRAM or SDRAM chip,(and since SDRAM is
>much cheaper than SRAM I'm apt to SDRAM), and here it posed another
>question and  that is if this CPLD is capable of driving a SDRAM (regarding
>dynamic memory timing constraints)?

I'd go for SRAM. I have used the XC95144 for replacing CRT / STN
displays with TFT. The key is to calculate the required bandwidth. In
my most recent project I used a 16 bit SRAM.

Still, given your project requirements you probably could get by with
a small FIFO (maybe 4 bytes deep). You need to get enough data from
the microcontroller. OTOH it sounds like a lot of fuss to keep the
microcontroller. If you switch to an ARM device (NXP for instance) you
can reach >30MHz SPI easely and use DMA.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Sep 26, 8:41=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Wed, 26 Sep 2012 11:49:32 -0500, nba83 wrote:
> >>Are you bitbanging this? Seems the STM32F107 has an I2S interface and s=
o
> >>has the AD1933. Aren't the two working together, or is the another
> >>reason
>
> >>you can not use the I2S peripheral?
>
> > Stm32 only supports rates 8 KHz to 96 KHz, I want to drive the chip at
> > 192 KHz
> > =A0which Stm does not provide
>
> Things aren't lining up here.
>
> 192kHz sampling? =A0Over 35MHz bit rate? =A0That works out to over 182bit=
s/
> sample. =A0How many bits per channel? =A0How many channels?
>

first post mentioned ad1933, 8channels,24bit,192kHz so 36.864MHz

> That chip will run at something like a 72MHz core clock, which gives you
> 36MHz at the SPI. =A0Moreover, if the ADC demands (say) 32 bits/write, th=
en
> you've got 64 clock cycles per word out if the chip is running flat out
> -- that leads me to believe that if you can't pump this out the SPI port
> of that chip, you're not going to be able to do anything significant to
> the data while it's in the processor. =A0Unless (and probably even if) yo=
u
> hand-code the thing in assembly and run it out of RAM, you're not going
> to be able to do much more than read the data out of memory and shove it
> out the door.

SPI is just for setup, data goes on I2S, running the mcu at 73.728MHz
and
using DMA it might work (assuming the I2S can run at mcuclk/2)

-Lasse

On Wed, 26 Sep 2012 11:49:32 -0500, nba83 wrote:

>>Are you bitbanging this? Seems the STM32F107 has an I2S interface and so
>>has the AD1933. Aren't the two working together, or is the another
>>reason
> 
>>you can not use the I2S peripheral?
>>
>>
> 		
> Stm32 only supports rates 8 KHz to 96 KHz, I want to drive the chip at
> 192 KHz
>  which Stm does not provide

Things aren't lining up here.

192kHz sampling?  Over 35MHz bit rate?  That works out to over 182bits/
sample.  How many bits per channel?  How many channels?

That chip will run at something like a 72MHz core clock, which gives you 
36MHz at the SPI.  Moreover, if the ADC demands (say) 32 bits/write, then 
you've got 64 clock cycles per word out if the chip is running flat out 
-- that leads me to believe that if you can't pump this out the SPI port 
of that chip, you're not going to be able to do anything significant to 
the data while it's in the processor.  Unless (and probably even if) you 
hand-code the thing in assembly and run it out of RAM, you're not going 
to be able to do much more than read the data out of memory and shove it 
out the door.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com