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
multiple clock design
Started by ●July 10, 2010
Reply by ●July 13, 20102010-07-13
Reply by ●July 13, 20102010-07-13
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. �����������������������������������������������������������������������
Reply by ●July 13, 20102010-07-13
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
Reply by ●July 14, 20102010-07-14
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 clockdomains,>>>>> 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 designa>>> 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 >
Reply by ●July 14, 20102010-07-14
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
Reply by ●July 14, 20102010-07-14
On 07/14/2010 10:23 AM, Rob Gaddi wrote:> 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? >Buy an FPGA-able ARM core? -- 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
Reply by ●July 14, 20102010-07-14
On Jul 14, 10:21�pm, Tim Wescott <t...@seemywebsite.com> wrote:> On 07/14/2010 10:23 AM, Rob Gaddi wrote: > > > 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? > > Buy an FPGA-able ARM core?Or design the whole thing asynchronously i.e. in a *self-timed* manner. It'll be a nice exercise, though not a terribly useful one. Or tell you what: instantiate a picoblaze, run everything in software, and deallocate your dynamic reconfiguration block when done. -Momo
Reply by ●July 15, 20102010-07-15
Important thing is that we are a product oriented company and want to capitalize the idea soon to beat the competitor (also to be finished before next appraisal meet to guard us from screwing). we have good experience in vhdl and actually starting our first design in FPGA. so we don't want to broaden our views and spend time for knowing about dsp,arm,etc.>On Jul 14, 10:21=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On 07/14/2010 10:23 AM, Rob Gaddi wrote: >> >> > 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.ev=>en >> >> though speed is less, area requirement of the design is more (about2>> >> 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, whichwould>> > push your central clock rate up to a mere 20 MHz. That's plenty oftime>> > 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? >> >> Buy an FPGA-able ARM core? > >Or design the whole thing asynchronously i.e. in a *self-timed* >manner. It'll be a nice exercise, though not a terribly useful one. Or >tell you what: instantiate a picoblaze, run everything in software, >and deallocate your dynamic reconfiguration block when done. > >-Momo >
