Prev: some good papers on OFDM/MIMO-OFDM
Next: Exocortex.DSP FFT implimentation? What should my result look like.
From: Tim Wescott on 13 Jul 2010 11:18
On 07/13/2010 07:30 AM, Jerry Avins wrote:
> On 7/13/2010 9:41 AM, Chris Maryan wrote:
>> The trick is that you aren't transfering things between clock domains,
>> just between clock enable domains. Everything always runs on the
>> fastest clock (in your case 20kHz), then you create clock enables
>> carried on the 20kHz clock, but at 10kHz or 2kHz rates. So when you
>> define your clocks in ISE, you only define one 20kHz clock and the
>> timing is valid for all of the clock enable domains.
>>
>> In VHDL it goes like this:
>
> ...
>
> In any case, setup and hold times depend on the device, not the speed
> that it's clocked at.

In the case of an FPGA they also depend on the design -- if you design a
device with lots of combinatorial logic between latches then the setup
time goes up; use the same exact FPGA and be very careful with your
pipelining (or use fancy tools that pipeline for you) and your setup
times go down.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
From: Jerry Avins on 13 Jul 2010 13:43
On 7/13/2010 11:18 AM, Tim Wescott wrote:
> On 07/13/2010 07:30 AM, Jerry Avins wrote:
>> On 7/13/2010 9:41 AM, Chris Maryan wrote:
>>> The trick is that you aren't transfering things between clock domains,
>>> just between clock enable domains. Everything always runs on the
>>> fastest clock (in your case 20kHz), then you create clock enables
>>> carried on the 20kHz clock, but at 10kHz or 2kHz rates. So when you
>>> define your clocks in ISE, you only define one 20kHz clock and the
>>> timing is valid for all of the clock enable domains.
>>>
>>> In VHDL it goes like this:
>>
>> ...
>>
>> In any case, setup and hold times depend on the device, not the speed
>> that it's clocked at.
>
> In the case of an FPGA they also depend on the design -- if you design a
> device with lots of combinatorial logic between latches then the setup
> time goes up; use the same exact FPGA and be very careful with your
> pipelining (or use fancy tools that pipeline for you) and your setup
> times go down.

Count the trace as part of the device. Whatever, clock rate is not an issue.

Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
From: Tim Wescott on 13 Jul 2010 14:39
On 07/13/2010 10:43 AM, Jerry Avins wrote:
> On 7/13/2010 11:18 AM, Tim Wescott wrote:
>> On 07/13/2010 07:30 AM, Jerry Avins wrote:
>>> On 7/13/2010 9:41 AM, Chris Maryan wrote:
>>>> The trick is that you aren't transfering things between clock domains,
>>>> just between clock enable domains. Everything always runs on the
>>>> fastest clock (in your case 20kHz), then you create clock enables
>>>> carried on the 20kHz clock, but at 10kHz or 2kHz rates. So when you
>>>> define your clocks in ISE, you only define one 20kHz clock and the
>>>> timing is valid for all of the clock enable domains.
>>>>
>>>> In VHDL it goes like this:
>>>
>>> ...
>>>
>>> In any case, setup and hold times depend on the device, not the speed
>>> that it's clocked at.
>>
>> In the case of an FPGA they also depend on the design -- if you design a
>> device with lots of combinatorial logic between latches then the setup
>> time goes up; use the same exact FPGA and be very careful with your
>> pipelining (or use fancy tools that pipeline for you) and your setup
>> times go down.
>
> Count the trace as part of the device. Whatever, clock rate is not an
> issue.

No kidding. That's not quite a rate you could achieve with relays, but
it should be a snap to do it with vacuum tubes.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
From: san_jack on 14 Jul 2010 01:09
The reason we are going for FPGA is we have soft ip cores of all the
modules targeted for fpga and we are not going for bulk production. even
though speed is less, area requirement of the design is more (about 2
spartan-6 lx16) fpgas.

>On 07/13/2010 10:43 AM, Jerry Avins wrote:
>> On 7/13/2010 11:18 AM, Tim Wescott wrote:
>>> On 07/13/2010 07:30 AM, Jerry Avins wrote:
>>>> On 7/13/2010 9:41 AM, Chris Maryan wrote:
>>>>> The trick is that you aren't transfering things between clock
domains,
>>>>> just between clock enable domains. Everything always runs on the
>>>>> fastest clock (in your case 20kHz), then you create clock enables
>>>>> carried on the 20kHz clock, but at 10kHz or 2kHz rates. So when you
>>>>> define your clocks in ISE, you only define one 20kHz clock and the
>>>>> timing is valid for all of the clock enable domains.
>>>>>
>>>>> In VHDL it goes like this:
>>>>
>>>> ...
>>>>
>>>> In any case, setup and hold times depend on the device, not the speed
>>>> that it's clocked at.
>>>
>>> In the case of an FPGA they also depend on the design -- if you design
a
>>> device with lots of combinatorial logic between latches then the setup
>>> time goes up; use the same exact FPGA and be very careful with your
>>> pipelining (or use fancy tools that pipeline for you) and your setup
>>> times go down.
>>
>> Count the trace as part of the device. Whatever, clock rate is not an
>> issue.
>
>No kidding. That's not quite a rate you could achieve with relays, but
>it should be a snap to do it with vacuum tubes.
>
>--
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com
>
>Do you need to implement control loops in software?
>"Applied Control Theory for Embedded Systems" was written for you.
>See details at http://www.wescottdesign.com/actfes/actfes.html
>
From: Rob Gaddi on 14 Jul 2010 13:23
On 7/13/2010 10:09 PM, san_jack wrote:
> The reason we are going for FPGA is we have soft ip cores of all the
> modules targeted for fpga and we are not going for bulk production. even
> though speed is less, area requirement of the design is more (about 2
> spartan-6 lx16) fpgas.
>

An S6 LX16 is a monster of a part: you've got flops, gates, and RAMs
coming out your ears. To have to throw two of them at a problem, and
then to only be clocking them at 20 kHz, seems off.

Let's say you had 1000x as many clock cycles to work with, which would
push your central clock rate up to a mere 20 MHz. That's plenty of time
to store one set of data in RAM, pull a different set of data, do
operations on it, and repeat. Are you 100% sure you're attacking this
problem correctly?

--
Rob Gaddi, Highland Technology
Email address is currently out of order
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: some good papers on OFDM/MIMO-OFDM
Next: Exocortex.DSP FFT implimentation? What should my result look like.