Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Tim wrote: > > Hal Murray wrote > > > As far as I can tell, RISC/CISC/Stack is all lost in the noise. > > Perhaps a good excuse to go drink beer and have religious arguments. > > > > Use what fits your problems and skills. A clever hacker can do > > very good work, especially if he is having fun doing what he wants. > > On the other hand, Intel's army of engineers is going a great job > > of cranking out fast chips in spite of the horrible architecture > > they have to use. > > Transputer. Still being developed, built, and used. A 500MHz > version in HDL was presented at the last DAC. > > Seems to be a good fit for verious embedded problems, like the > problems this group focuses on. It is good to hear about something that is even further out in left field than Forth... :) To say that the Transputer is being "used" is a bit of a stretch. Who is using it? Certainly this is not commercially available in the same way that other processors are, for example, the 8051 or Coldfire, etc... Where can I get a current Transputer? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 50501
Peter Alfke <peter@xilinx.com> wrote: : Mathew Orman wrote: :> The output of any register has to drive the input of the next block in your :> design. If the output is low than the is a sink current drown from the next :> input and if it is high :> the register is sousering the current to the next input block. : Not true. Nowadays we are all using CMOS technology, where the static current : is essentially zero ( femtoamps inside the chip). Does this still hold for todays 1x0 nm designs. The P4 is known to consume about 30 Watt even in hold mode. Explications for that I heard was leackage currents in the 1x0 nm design. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 50502
Uwe, The 2VP4 and 2VP7 (Virtex II Pro) consume only a few hundred milliamperes when the junction temeprature is 85C from internal leakage. Just because Intel designs in a particular fashion does not mean that everyone has to do the same thing. Austin Uwe Bonnes wrote: > Peter Alfke <peter@xilinx.com> wrote: > > : Mathew Orman wrote: > > :> The output of any register has to drive the input of the next block in your > :> design. If the output is low than the is a sink current drown from the next > :> input and if it is high > :> the register is sousering the current to the next input block. > > : Not true. Nowadays we are all using CMOS technology, where the static current > : is essentially zero ( femtoamps inside the chip). > > Does this still hold for todays 1x0 nm designs. The P4 is known to consume > about 30 Watt even in hold mode. Explications for that I heard was leackage > currents in the 1x0 nm design. > > Bye > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 50503
Martin Schoeberl wrote: > > > The slowness comes in because of the work the stack machine must do to > > perform that add > > > > Fetch op one from stack (dec sp ) > > Fetch op two from stack (dec sp) > > Add ops > > Push result to stack ( inc sp) > > > > By my count this is 4 cycles, although I suppose you could use a dual port > > stack and pop the arguments in one cycle. Although this increases the area > > of the design, which doesn't fit with what I want to acheieve. It doesn't > > look like it lends itself well to any kind of > > pipelining either. > > I assumed these four operations in one single cycle. It's easy to implement > when TOS and TOS-1 are real register, that feed the alu. You only have to > spill and fill TOS-1 with a single port memory. For the design its easier to > use a memory with independent read and write port. > > You can find a simple picture of that at: http://www.jopdesign.com/jop3.html > > A is TOS, B is TOS-1 and the block named RAM is the rest of the stack. On an > operation that consumes one operand (like add) B is filled with the next > stack element and A is loaded with A op B. On a push instruction B is loaded > with A and the memory is filled with B. This is very common for forth machines, but another poster was trying to say that a speed advantage was gained on stack machines because there was no need for a multiplexer to route different registers to and from the ALU. This use of discrete registers for TOS and TOS-1 requires that the same multiplexers be used on the inputs to the TOS, TOS-1 and the remaining stack RAM. I have found that the only optimizations that are unique to a given architecture are due to eliminating modes of operation. If the stack machine only moves data up or down in the stack by one word at a time, this restriction will allow simpler hardware than a general register based machine. But by bringing back the arbitrary movement of data, the optimizations are lost. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 50504
My mistake, I needed to find a motherboard with 64/66 PCI slots to be
guaranteed the 3V needed for the board.
Austin Franklin wrote:
> Hi Ray,
>
> That may not be quite right. 64 bit has nothing to do with 3V or 5V, it's
> 66MHz that's 3V only. 64 bit can be either 3V or 5V, as it is merely adding
> 32 bits to the data path, with no change in signaling or timing.
>
> I have seen motherboards that support 64 bit, but are only 5V 33MHz.
>
> Regards,
>
> Austin
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3DF580B1.FEDF0293@andraka.com...
> > The 64 bit PCI supports 3v, and any motherboard with it will work with the
> 3v
> > cards. Some of the FPGA cards such as the ISI Osiris board require a 64
> bit slot
> > because they are 3v boards. It is rare to find 32bit PCI motherboards
> with 3v
> > support.
> >
> > Hal Murray wrote:
> >
> > > > Did 3V PCI ever take off
> > >
> > > Thanks for all the feedback. Sorry my question wasn't clear.
> > >
> > > There are two possible meanings for 3V. One is power. The other
> > > is the signaling level.
> > >
> > > First, the power stuff:
> > >
> > > The PCI connector has power pins for 5V, and 3.3V, and also a
> > > few more pins for IO power. They are either 3 or 5, depending
> > > upon the signaling voltage, the idea being that you can wire
> > > them to the supply rail for your IO pads and make a board that
> > > supports either 3V signaling or 5V, depending upon the power the
> > > motherboard supplies on those pins.
> > >
> > > The PCI connector has a plug that matches with a cutout on the
> > > board. The plug goes in either of two positions (turn the connector
> > > around), one for 5V signaling, the other for 3V. So in theory,
> > > you can make three types of cards. The normal card in wide use
> > > is 5V signaling, though they may only drive the outputs with a
> > > 3V CMOS driver. You can also make 3V only card by putting the
> > > cutout on the other end of the card. You can also make 3V/5V
> > > cards by cutting out both slots and maybe wiring the IO pad
> > > rail on your chip to the IO supply from the PCI connector.
> > >
> > > I've never seen any 3V or dual cards.
> > >
> > > The main question I was trying to ask was if anybody had seen
> > > any 3V or dual signaling level cards. If so, I might think more
> > > about taking advantage of that. Since I didn't see many
> > > encouraging responses I'll probably but this on the back burner.
> > >
> > > Some early systems didn't actually supply any 3.3V power. You
> > > can dance around that with an on-board regulator. I plan to
> > > ignore that. (But I'll check my systems first, just in case,
> > > and listen for tales of troubles with not-so-early boards.)
> > >
> > > Now for the signaling:
> > >
> > > The 3V signaling rules overlap the 5V rules enough so that a
> > > card that drives high to 3V will work in a 5V system. The
> > > catch is that some other card driving to 5V on a system that
> > > produces worst-case reflections might generate an 11V spike.
> > > "5V tolerant" is the critical term for that.
> > >
> > > The Spartan-II is 5V tolerant but doesn't have DLLs. The -IIE
> > > has DLLs, but doesn't tolerate 5V signaling.
> > >
> > > Since 3V systems don't seem to be very popular, I probably won't
> > > build a card expecting to find a 3V only slot.
> > >
> > > Several years ago, I put a scope on a system that had the connector
> > > pegs set for 5V. I never saw anything go over 3V. Obviously that
> > > depends upon what cards are plugged in. Somebody could add an
> > > old/evil card that really does drive to 5V.
> > >
> > > For hack/research systems it might make sense to use a FPGA that
> > > wasn't 5V tolerant on a card that could be plugged into a 5V system.
> > > You would have to remember to get out the scope before adding a card
> > > that hadn't been tested yet. I'm probably not desperate enough
> > > to get the DLLs that I will do this. (But I'm still scheming.)
> > >
> > > Thanks for the PLX suggestions. Their web site expects me to
> > > register before they give me data sheets so I'll put that on the
> > > back burner.
> > >
> > > Thanks for the heads-up about using DLLs on PCI clocks. Is
> > > that a clear don't-do-that, or just another worm for the list?
> > >
> > > --
> > > The suespammers.org mail server is located in California. So are all my
> > > other mailboxes. Please do not send unsolicited bulk e-mail or
> unsolicited
> > > commercial e-mail to my suespammers.org address or any of my other
> addresses.
> > > These are my opinions, not necessarily my employer's. I hate spam.
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930 Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 50505
Laurent Gauch wrote:
>
> Nice board, but the 400ma is no enougth for the X2S100E FPGA. Certainly
> OK in some cases, but a 500 ma minimum is specified by Xilinx for the
> FPGA download!!
Sorry for mistake. Should be 600 ma. See Linear's LTC3406 datasheet.
Seiran Petikian
seiran@seytronix.com
petikian01@rogers.com
>
> Seiran wrote:
> > Hi!
> > Dear Friends.
> >
> > I hope my message may be interesting for this group. (If it isn't then
> > just ignore it.)
> >
> > Our company started to produce very small size FPGA and microcontroller
> > boards.
> > The sizes are small enough to drop all in your "overloaded" notebook's bag.
> > All boards powered from USB, so no external power source need. It's
> > really convenient
> > when you are going to demonstrate your design with your laptop only.
> > You can use them as evaluation board or fit them on your own boards as a
> > component.
> > Also you can buy universal prototyping board and low price JTAG cable
> > for downloading
> > XILINX FPGA's and flash ROM.
> >
> > See our web site. www.seytronix.com <comp.arch.embedded>
> >
> > Some details and design examples will come soon.
> > (I've just started to setup the site and any suggestion is appreciated!)
> >
> > Thanks!
> >
> > Seiran Petikian
> > seiran@seytronix.com
> > petikian01@rogers.com
> >
Article: 50506Austin Lesea <austin.lesea@xilinx.com> wrote: : Uwe, : The 2VP4 and 2VP7 (Virtex II Pro) consume only a few hundred milliamperes : when the : junction temeprature is 85C from internal leakage. : Just because Intel designs in a particular fashion does not mean that : everyone has : to do the same thing. http://www.theinquirer.net/?article=6677 -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 50507
> Uwe Bonnes wrote: > > Does this still hold for todays 1x0 nm designs. The P4 is known to consume > > about 30 Watt even in hold mode. Explications for that I heard was leackage > > currents in the 1x0 nm design. > > ( plus a ref to http://www.theinquirer.net/?article=6677 ) This is why varying Vcc has become the norm, for portable uP apps. Austin Lesea wrote: > The 2VP4 and 2VP7 (Virtex II Pro) consume only a few hundred milliamperes when the > junction temeprature is 85C from internal leakage. > > Just because Intel designs in a particular fashion does not mean that everyone has > to do the same thing. There are those for whom 'a few hundred milliamperes' is still a large number... And we can expect this to increase, on the next shrink ? -jgArticle: 50508
John, In Timing Analyzer you can view the Physical Name by going to Edit -> Preferences and selecting Show Physical Name in detailed path. Most people didn't want to see that information so by default it is not shown. For those who want to see it, they can turn it on. Kate John_H wrote: > If you look at your report with the optional stuff (in menu entry > View/Options?) you can see the physical connections. If, for instance, it > says the net going into this element is the .T port of an IOB, then it's > probably a tristate-to-pad time. I miss having the timing analyzer reports > defaulting to the physical implementation. > > "Daryl" <eengineer@eat.com> wrote in message > news:Xns92CD8A16157F0eeD3eastdaycom@130.133.1.4... > > Hello there, > > > > In my recent design, I notice that a timing parameter named "Tiotp" > > which is reported by ISE 5 tools. > > It seems a IOB timing parameter, but I cannot find any description on > > it in the handbook of VirtexII. > > If I remember rightly, for the recent version of ISE, it is "Tioop" of > > IOB which means propagation delay from the O input of the IOB to PAD. > > > > The FPGA gurus and Xilinx people, would you explain it to me? > > > > > > > > > > -- > > Badahana > >Article: 50509
As a follow-up to my post, in looking at Floorplanner it seems that it might be sensible to build large input output busses by straddling two banks in each corner of a device. This would allow shortest path from every related I/O pin to the logic resources in that corner. Is this true? What are the issues regarding clock distribution? Thanks, -- Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 50510
> > of the JIT compiled program was LONGER!. In JDK 1.1 about 10% and in JDK 1.3 > > it was about 15 times slower! > > Wow - a real warning to those who would use Java for embedded/real time > work. > Just be real carefull to never change versions. > > Was that 15x slower, because the interpreting mode got faster ? > It's not a trivial amount of work to make something run 15x slower :) No warning about usage of Java in embedded work. That's just an artefact of the JIT. You wil not use JIT in embedded systems. > Did you ever compare the .NET byte code, or consider a .NET FPGA engine > ? Have not tried it. I think it's just a copy of the JVM idea for the Win32 world. The most important thing about .NET are the libraries. But you don't need them in embedded systems. Martin -- JOP - a Java Optimized Processor for FPGAs. http://www.jopdesign.comArticle: 50511
> > So a simple function like:
> >
> > int f(int a, int b) {
> > return a+b;
> > }
> >
> > translates to:
> >
> > Method int f(int, int)
> > 0 iload_1
> > 1 iload_2
> > 2 iadd
> > 3 ireturn
> ---snip---
>
>
> Again, your mind set is setting your expectations. You are
> forcing the machine to do what you believe is the best
> way to represent the problem. Maybe Java is not the best
> example of a stack language to look at. In the above
> example, you've assumed that the two values need to be
> loaded. In a typical stack implementation, they are already there
It's not my mind set, it's just what a Java compiler does. As I'm working on
a Java processor these are the problems I have to deal with.
Martin
--
JOP - a Java Optimized Processor for FPGAs.
http://www.jopdesign.com
Article: 50512"hristo" <hristostev@yahoo.com> schrieb im Newsbeitrag news:b0ab35d4.0212101604.3085c402@posting.google.com... > > At the end of the configuration, when all data bits have been shifted into > > the FPGA, > > through which channel? Whatever configuration channel is used (JTAG, serial slave/master) > > GSR (global set/rest for FlipFlops) will be released > > GTS (global tristate for IOs) will be released > why this signal is sent? > > GWE (global write enable for FlipFlops /RAMS) will be released > why this signal is sent? These signal assure a (almost) simultaneously power up of the whole FPGA. It would ne not so nicce if the first half is already configured and running when the second half still wait for configuration. > ok during those sequences will the logic be clocked or no? can i do The clock is running through the chip (if you apply a clock outside), but will have no effect until the GSR and GWE are released. > all those configuration and later input the clock? Sure, but this is not really neccessary. -- MfG FalkArticle: 50513
"Tim Nicolson" <t.nicolson@signal.qinetiq.com> wrote in message news:<1037972506.869047@bengal>... [snip] > The ip algorithm requires that I compute logarithms. This can prove > quite a computationally expensive operation, but I only need accuracy > down to around 4/5 significant figures. [snip] > This method is inexpensive but gives limited accuracy. Operations shown > below > > > z = a + b*mant + c*mant^2 + d*mant^3; > > if (e ~= 0) > z = z + exp * C1; > end; > > This requires 6* and 4+. Hi Tim, I don't have anything to add to the existing discussion of logs (sorry), but if you are evaluating polynomials, you should be aware of Horner's rule ( a personal favorite ): a + b*x + c*x^2 + d*x^3 = ( a + x*(b + x*(c + x*d ) ) ) this reduces your 6 mults (??? 7) to 3 (??? 4). [snip] > > Thanks very much for your time. > > Tim >Article: 50514
"hristo" <hristostev@yahoo.com> schrieb im Newsbeitrag news:b0ab35d4.0212110739.377c8625@posting.google.com... > as a follow up to my previous messages > will the user clock be running during the Fpga startup phase? > we have read a lot about the GSR slow propagation through the chip, so > why not just delay the input data for some clock cyles till we will be > sure that GSR has run through all the chip? Hmm, not so practicable. The effect you describe is a possible lock-up of state-machines if the reset is not fast enough, so a half of the state machine is already running where the other half is still held in reset. The solution against such bad things is to use normal routing ressources to drive the reset for FSMs, which is MUCH faster but required some routing ressources. No bad deal after all. -- MfG FalkArticle: 50515
Jim Granville wrote: > > Just because Intel designs in a particular fashion does not mean that everyone has > > to do the same thing. > > There are those for whom 'a few hundred milliamperes' is still a large > number... We are obviously concerned about this, and we have managed to keep the "sub-threshold leakage current" somewhat under control. The largest Virtex-II devices are physically much bigger and have a lot more transistors than Intel's biggest microprocessors, and we still have far lower leakage current. But the recent trend has definitely been away from low standby current. And that goes for all state-of-the-art big and fast CMOS devices from any manufacturer. Chip designers can reduce standby current, but at the cost of lower performance, i.e. longer delays, and also larger size = higher cost. Peter AlfkeArticle: 50516
The general approach to rapidly computing logarithms (used by Henry Briggs
to generate the log tables he published in 1617) is to first reduce the
problem to the computation of the logarithm of a value very near 1. Then
use the power series
log (1+x) = x - x^2/2 + x^3/3 - x^4/4 ......
to get a value of whatever accuracy you need. The "cleverness" is in how to
creatively move the argument near 1.
A full treatment of this is given in _Dead Reckoning - Calculating Without
Instruments_ by Ronald Doerfler (ISBN 0-88415-087-9).
Good luck. :-)
Kip Ingram
--
Get daily news and analysis from the FPGA market for pennies a day.
Subscribe to
The FPGA Roundup today: http://www.KipIngram.com/FPGARoundup.html
--
"John" <john.l.smith@titan.com> wrote in message
news:5b9931fd.0212111542.5d473661@posting.google.com...
> "Tim Nicolson" <t.nicolson@signal.qinetiq.com> wrote in message
news:<1037972506.869047@bengal>...
> [snip]
> > The ip algorithm requires that I compute logarithms. This can prove
> > quite a computationally expensive operation, but I only need accuracy
> > down to around 4/5 significant figures.
> [snip]
> > This method is inexpensive but gives limited accuracy. Operations shown
> > below
> >
> >
> > z = a + b*mant + c*mant^2 + d*mant^3;
> >
> > if (e ~= 0)
> > z = z + exp * C1;
> > end;
> >
> > This requires 6* and 4+.
>
> Hi Tim,
> I don't have anything to add to the existing discussion
> of logs (sorry), but if you are evaluating polynomials,
> you should be aware of Horner's rule ( a personal favorite ):
>
> a + b*x + c*x^2 + d*x^3 =
> ( a + x*(b + x*(c + x*d ) ) )
>
> this reduces your 6 mults (??? 7) to 3 (??? 4).
>
> [snip]
>
> >
> > Thanks very much for your time.
> >
> > Tim
> >
Article: 50517Peter, I'd just like to mention that we had the Virtex II product in full design work for a major product at the last company I worked for before going into private practice (BP Microsystems here in Houston), and I was *very* impressed with the architecture. Outstanding product! Thanks, Kip Ingram -- Get daily news and analysis from the FPGA market for pennies a day. Subscribe to The FPGA Roundup today: http://www.KipIngram.com/FPGARoundup.html -- "Peter Alfke" <peter@xilinx.com> wrote in message news:3DF7CEA9.521274FC@xilinx.com... > > > Jim Granville wrote: > > > > Just because Intel designs in a particular fashion does not mean that everyone has > > > to do the same thing. > > > > There are those for whom 'a few hundred milliamperes' is still a large > > number... > > We are obviously concerned about this, and we have managed to keep the "sub-threshold > leakage current" somewhat under control. The largest Virtex-II devices are physically > much bigger and have a lot more transistors than Intel's biggest microprocessors, and > we still have far lower leakage current. > But the recent trend has definitely been away from low standby current. > And that goes for all state-of-the-art big and fast CMOS devices from any manufacturer. > > Chip designers can reduce standby current, but at the cost of lower performance, i.e. > longer delays, and also larger size = higher cost. > > Peter Alfke >Article: 50518
John wrote: > I don't have anything to add to the existing discussion > of logs (sorry), but if you are evaluating polynomials, > you should be aware of Horner's rule ( a personal favorite ): > > a + b*x + c*x^2 + d*x^3 = > ( a + x*(b + x*(c + x*d ) ) ) which interestingly (and somewhat obviously) is simply a recursive multiply/accumulate - techniques for which are well-established in hardware DSP/imaging. could lead to some minor savings or hardware reuse. Rgds, JohnArticle: 50519
rickman wrote >>> Transputer. Still being developed, built, and used. A 500MHz >>> version in HDL was presented at the last DAC. >>> >>> Seems to be a good fit for verious embedded problems, like the >>> problems this group focuses on. > > It is good to hear about something that is even further out in left > field than Forth... :) > > To say that the Transputer is being "used" is a bit of a stretch. Who > is using it? I invited them to share their actual and potential customer list with me, and I am sure it will arrive soon :-) I understand the answer is set-top boxes, routers, entertainment, automotive, and so on. > Certainly this is not commercially available in the same > way that other processors are, for example, the 8051 or Coldfire, > etc... Where can I get a current Transputer? Available like the parts you mention, but the MOQ is a few orders of magnitude larger. A little like XC2S30-6VQ100C (Meow)Article: 50520
hello, I've been targeting Altera devices for a while, and this is my first foray into the Xilinx devices. I notice that they have both a DCM and CLKDLL available to minimize clock skew, when using multiple clocks derived from a primary clock. My question is, doesn't a DCM have the same characteristics as a CLKDLL. If so, then when would I ever need to use a CLKDLL? Wouldn't I just always use a DCM? Thanks.Article: 50521
I appreciate your response and that definitely helps my understanding. I was under the impression that the wire delays were estimated accurately in the synthesis process, but I guess not. Also, what is an ECO that you mention in your email ? Thanks, Prashant Muzaffer Kal <kal@dspia.com> wrote in message news:<j1uevu4e7mmo2o0cvqlargcbijvqo6bdl5@4ax.com>... > On 11 Dec 2002 09:17:18 -0800, prashantj@usa.net (Prashant) wrote: > > >Hi all, > >I have been struggling with a problem for nearly a month now. I have a > >small piece of code which gives hold time violations when its > >synthesized in Quartus II. But if I synthesize and complete the > >fitting of the design, there are no hold time violations. Post fitting > >simulations dont show any violations either. Has anyone see such > >behavior in their designs ? Is this a problem and if so, what needs to > >be done to fix it ? > > > >Thanks, > >Prashant > > Hold violations happen when clk->Q + logic delay (assuming zero skew) > is smaller than the hold constraint of the accepting flop. If you have > little or no logic and a fast flop, the synthesizer may underestimate > the wire delay and generate a hold violation. When you do P&R, the > actual wire delay gets added and that may resolve the hold violation. > So if you're not seeing hold violations after P&R, you're OK. In the > future if you see hold violations after P&R the solution might be to > do an ECO and add a slow buffer between the two flops to fix it. > > Muzaffer Kal > > http://www.dspia.com > ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 50522
If you're using a Virtex-II the only thing the CLKDLL primitive buys you is backward compatability in the source code with the Virtex and Virtex-E style implementations. The Virtex-II devices only have the DCM elements. The CLKDLL primitive configures the DCM for the simple functionality that the earlier devices provided. The Virtex and Virtex-E parts (and Spartan-II and Spartan-IIE) only have the DLLs - no DCMs are available. "Skept" <skepticon@yahoo.com> wrote in message news:bbdf4ddd.0212111726.485779f8@posting.google.com... > hello, > > I've been targeting Altera devices for a while, and this is my first > foray into the Xilinx devices. I notice that they have both a DCM and > CLKDLL available to minimize clock skew, when using multiple clocks > derived from a primary clock. > > My question is, doesn't a DCM have the same characteristics as a > CLKDLL. If so, then when would I ever need to use a CLKDLL? Wouldn't > I just always use a DCM? > > Thanks.Article: 50523
"Pete Fraser" <pete@rgb.com> wrote in message news:<uvevbaamr4t5eb@news.supernews.com>... > "Jay" <kayrock66@yahoo.com> wrote in message > news:d049f91b.0212101735.6d7ba6f6@posting.google.com... > > I'm going to second Paul's suggestion about just computing the the > > correlation sequentially, its just too easy not to do. And also, I > > don't think a single correlation is going to give you your time delay, > > I think you're going to have to slide the 2 data sets across each > > other and keep computing that correlation until it peaks. > > > > Do you mean convolution? > > I think correlation already does the sliding stuff. I think 4096 points is right around the area where using fft's starts to become seriously faster than direct convolutions (convolution is almost the same as correlation but you conjugate the data in the frequency domain). This assumes your data is a nice size like power of 2, which it is. It's NlogN versus N^2 multiplies. Don't forget you have to zero pad the data and actually do a 8192 point fft unless you want a circular correlation. Also the fft method is a memory hog if that's an issue since, besides zero-padding, you must store the intermediate data to multiply, not to mention the inverse data and the multiplies are complex. Off the top of my head I'd assume it's possible to make a clever algorithm to implement your big fft with NlogN multiplies using 32-point stages. KeithArticle: 50524
Correlation is the convolution between two timesets, one reversed in time (and offset for each resulting data point). The suggestion was to do the convolution with data set A and the reversed data set B rather than doing IFFT( FFT(A) * complex_conjugate(FFT(B)) ). It's been a while, but I think that's the idea. The only point where the convoultion approach falls short is when one wants many points of correlation across a sliding time window. The scale of information in time and resolution will push the tradoffs around for FFT, multiply, IFFT versus multiply/add over and over. One data point in the convolution is the sum of n multiples. If only one peak is needed, finding that peak then servoing to it might work fine but you need n^2 multiplies to get n results out of the correlation. My apologies if I haven't hit the details points precisely but it gives a flavor for the considerations involved. "Pete Fraser" <pete@rgb.com> wrote in message news:uvevbaamr4t5eb@news.supernews.com... > > "Jay" <kayrock66@yahoo.com> wrote in message > news:d049f91b.0212101735.6d7ba6f6@posting.google.com... > > I'm going to second Paul's suggestion about just computing the the > > correlation sequentially, its just too easy not to do. And also, I > > don't think a single correlation is going to give you your time delay, > > I think you're going to have to slide the 2 data sets across each > > other and keep computing that correlation until it peaks. > > > > Do you mean convolution? > > I think correlation already does the sliding stuff. > >
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z