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
Hi, I'm using a virtexII and I'm trying to use the Architecture wizard to divide a clock by 5. However, the divided clock rising edge is aligned with the falling edge of my input clock. Is this normal or I'm doing something wrong in the Architecture wizard? How can I have both rising edge aligned? Here are the parameters I use Input clock: 26Mhz, External Divide by 5 Feedback: internal, 1X Duty cycle correction: yes Phase shift: none. Thank you very much DavidArticle: 59801
Probably not, a fair amount of it is structural instantiation of primitives
to force the implementation and layout. As a result, it is big and may be
hard to follow. It was done as a fun project to demonstrate my company's
capability and as an example I can use in my seminars. I am still
developing much of the supporting material needed to make it available in
whole for public consumption. I may put it in the book I am working on as
an appendix, however. The book is due to the publisher 14 months from
now. I may also put the board mods and bitstream up on the web for people
who want to try it out some time in the future...definitely not this week
though, got some SBIR proposals to finish up as well as the MAPLD
conference to prepare for.
Pete Fraser wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3F4D8155.A14C666F@andraka.com...
> > How about not just music out of an FPGA pin, but a complete shortwave
> receiver using just a SpartanII FPGA
> > and an AtoD converter? See the block diagram on my website.
>
> Sounds like fun.
> Are you going to post the HDL?
--
--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: 59802Ray Andraka <ray@andraka.com> wrote in message news:<3F4DED0E.574A03F9@andraka.com>... > You sound like a good candidate to spend you time pursuing a perpetual motion machine. Ray, maybe we can absorb some energy from a parallel universe and ... :) >From the site referred by Philip: "Hopefully, the discussion will discourage further attempts to eliminate this unavoidable characteristic" I think a researcher should never say something like that. The right phrase should be: Hopefully, the discussion will encourage further attemps to better understand and avoid this characteristic. Nobody knows everything. Physics don't change (I hope), but the way we model it is always evolving. Things considered impossible became possible. > The physics stipulate that you'll have a probability of hitting a metastable state. As > processes improve, we can narrow the width of the window, but we can't eliminate it. > Narrowing the width reduces the probability of hitting it for a fixed clock rate. Trouble > is, as the process improvements occur that permit narrowing the window, the clock speeds > also increase, so unless the designer designs for metastbility, the odds may not improve. > I understood the problem. I've found some "solutions", but when I tried to prove them I could only prove they don't work at all. But, like Winston Churchill, I'll never surrender, not any time soon. Anyway, thankyou. I always appreciate what you (Ray), Austin, Peter, Rick, and everybody else that contributes here have to say. Well, Peter's "Grrr" not included :). Luiz Carlos.Article: 59803
this is dependant on what chip he is using - is this only a xilinx newsgroup? Marten wrote: >"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message >news:bilfne$sel$1@home.itg.ti.com... > > >>Hi all, >>I have a vhdl component with a "clock_in" input. Depending on the mode of >>operation, I want to switch between two different clock signals. I will >>never switch on the fly though. Can I use a mux in front of the clock_in >>input? I'm afraid it might glitch. >>Thanks >>David >> >> >> >> > >David, > >Do a query for 'clock sources' in the category 'XCELL Journals' on the >Xilinx web site. This will provide you with a link called 'XCELL 24 - >Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead you >to xl24_20.pdf, a neat little circuit that hopefully will ease your worries >:) > >Keep in mind that whatever you put in the clock path will affect the setup >and hold time requirements for the particular component. > >Take care, > > >Marten > >] remove the obvious to repy by e-mail [ > > > >Article: 59804
ISE 5.2, Spartan 2e. Dumb question ! I'm trying to work out how to use the DLL pads to feed the DLL ! GCKn inputs work via IBUFGs, but with DLL pads I get complaints about needing an 'IBUFDLL', but this does not seem to figure in the library. (The actual code being used here is a slightly hacked version of the examples in Xapp 174) DaveArticle: 59805
Hi Peter: the problem with metastability is probably best understood by looking through some of the ieee papers by Dike and Burton - these guys did the measurements and there is no solution - metastability requires thermal noise on two nodes inside a flop(including the Xilinx model that I saw a couple years ago) to force the output change, and that's a statistical quantity - metastability can reign out to infinity, although the probability is small. No solution known to us under device physics as we know it now, just getting the probabilities smaller. This is why hold time is just a statistic, and much like we qualify things under BERT and jitter (more statistical quantities), we are human and guessing our best. Andrew Peter Alfke wrote: >Luiz, >you need to read up on metastability. >There are things even in physics that have no solution. Perpetual motion >is one. If you want to get philosophical about metastability, read >Heisenberg's Uncertainty papers. > >Phil Freidin has described the problem very well. He and I agree 100% on >the problem. But I have made quantitative tests and know the (very low) >probability. Everybody has an opinion, very few have performed measurements... > >Peter Alfke >================================= >Luiz Carlos wrote: > > >>Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... >> >> >>>The output level of a flip-flop during its metastable time is >>>irrelevant. If it were in the middle ( which it isn't) we could easily >>>fix this with a zener diode. >>>The problem is timing. The Q output can - and will - change to the >>>opposite state at a totally unpredictable time. That's the problem: >>>unpredictable timing, not unknown levels. >>> >>>Cascading flip-flops is the standard remedy, but it introduces latency. >>> >>>Remember: Metastability causes an extra 3 ns of unpredictable delay once >>>in a billion years... Seems to be an affordable risk. >>> >>>Peter Alfke >>> >>> >>Peter, kind of disagree. >> >>Of course for the designer, the problem is timing. But the timing >>problem is caused by the voltage problem. If we had a well defined >>voltage behavior (as I thought, but now I know I were wrong), we could >>fix the timing problem (as you said for the "in the middle" problem). >>Anyway, I undestood what you said. >> >>I also disagree that the problem has no solution. As an engineer I >>don't believe in no solution problems, we just don't know the >>solutions yet. But this is philosophy! >> >>Luiz Carlos >> >>Article: 59806
Hello, I'm wondering if anyone wants to offer up their opinion of Mentor's HDL Designer series or FPGA Advantage (Designer + simulation&synthesis)? I recently acquired it, but am wondering about the quality of the resulting code. It looks like it might be very easy to produce stuff with it, but does it save time coding in the end? Thanks, -robertArticle: 59807
"Ray Andraka" <ray@andraka.com> wrote in message news:3F4DED0E.574A03F9@andraka.com... > You sound like a good candidate to spend you time pursuing a perpetual motion machine. > The physics stipulate that you'll have a probability of hitting a metastable state. As > processes improve, we can narrow the width of the window, but we can't eliminate it. > Narrowing the width reduces the probability of hitting it for a fixed clock rate. Trouble > is, as the process improvements occur that permit narrowing the window, the clock speeds > also increase, so unless the designer designs for metastbility, the odds may not improve. Really the problem is insisting on synchronous designs. Asynchronous (self-timed) logic doesn't have this problem. Well, metastability is still there, but the logic will wait, however long it takes, for it to resolve. I used to hear stories, though I am not sure that I believe them, of people seeing metastability effects on the PDP-10 (KA10), which used self timed logic. Supposedly they could see it stop processing, and then start again with no ill effect. How they know it wasn't in I/O wait, or some other such state, I have no idea. -- glenArticle: 59808
Fortunately there are things that come out of Xilinx that are applicable to all digital logic. That XCELL article is one of them if you chose to look. "Andrew Paule" <lsboogy@qwest.net> wrote in message news:a2t3b.29$qq3.17593@news.uswest.net... > this is dependant on what chip he is using - is this only a xilinx > newsgroup? > > Marten wrote: > > >"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message > >news:bilfne$sel$1@home.itg.ti.com... > > > > > >>Hi all, > >>I have a vhdl component with a "clock_in" input. Depending on the mode of > >>operation, I want to switch between two different clock signals. I will > >>never switch on the fly though. Can I use a mux in front of the clock_in > >>input? I'm afraid it might glitch. > >>Thanks > >>David > >> > >> > > > >David, > > > >Do a query for 'clock sources' in the category 'XCELL Journals' on the > >Xilinx web site. This will provide you with a link called 'XCELL 24 - > >Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead you > >to xl24_20.pdf, a neat little circuit that hopefully will ease your worries > >:) > > > >Keep in mind that whatever you put in the clock path will affect the setup > >and hold time requirements for the particular component. > > > >Take care, > > > > > >MartenArticle: 59809
If you're still having any difficulty finding that PAL20L10 info, I have a copy of the original article, the 1989 NS PLD Databook. As it turns out, I was the original NS apps engineer who organized that book project (in a former life). My copy even has some errata in red ink. When I saw your posting, I just couldn't resist... aren't newsgroups wondrerful! And I think by now I shouldn't have to worry about too many more support questions coming in about this one! Let me know if you'd like me to fax you a copy. Regards, Jeff Seltzer Colin Jackson wrote: > Thanks, I had never heard of them. > Looks like a great service. > > I emailed National directly without a responce. > A guess their too big for their customers! > If I operated like them I'd be on welfare. > > "Valeria Dal Monte" <aaa@bbb.it> wrote in message > news:Zdr_a.241160$lK4.7357861@twister1.libero.it... > > > > "Colin Jackson" ha scritto nel messaggio > > news:f_ydnYyhuIk3qaSiXTWJgA@comcast.com... > > > Anyone have a datasheet for a National PAL20L10? > > > > At www.freetradezone.com there is the AMD PAL20L10 data sheet > > for free. The National version is available for the subscribers only. > > > >Article: 59810
Robert Abiad wrote:
>
> Hello,
>
> I'm wondering if anyone wants to offer up their opinion of Mentor's HDL
> Designer series or FPGA Advantage (Designer + simulation&synthesis)? I
> recently acquired it, but am wondering about the quality of the
> resulting code. It looks like it might be very easy to produce stuff
> with it, but does it save time coding in the end?
It may be usefully for a schematic oriented designer or
someone learning an hdl.
Once you learn an hdl, you may prefer your own
text editor without all the graphical overhead.
-- Mike Treseler
Article: 59811JEDEC files are very device and architecture specific. It is very unlikely that jed2abl would support anything more than the 22V10 or 16V8 type of devices. If Data I/O, the original authors of ABEL, supported the XC9536 then you might have a shot. If not, then you will have to go to Xilinx and I don't think the programmable logic companies like to give out JEDEC disassembelers, even if they have them Andrew Paule <lsboogy@qwest.net> wrote in message news:<zp63b.37$ib4.39820@news.uswest.net>... > see if you can find jed2abl around - many of the abel compilers had this > feature - converted jedec files to abel code > > Andrew > > yusuke wrote: > > >Hi, > > Is it possible to convert jedec to logical equations? I've got a jed > >file for a xilinx cpld(XC9536xl) and I'm trying to recover a job done > >a long time ago. Or, is it possible to discover the pinout based on > >the jed file? This would be quite useful too. > > > >Thanks in advance, > >yusuke > >PS: Sorry for my poor English skills. > > > >Article: 59812
Philip Freidin <philip@fliptronics.com> wrote in message news:<9scskv82ee51brah4qefbqvefprvtra65r@4ax.com>... > > Yep, you are right, it is just a matter of time. In this case > it is infinite. > > When you do your designs do you > > A) Do nothing special for async signals entering a synchronous > domain, because some day someone will solve this problem. > > or > > B) Use multistage synchronizers to move signals from one clock > domain to another, because some day someone will solve this > problem, but it hasn't happened yet. > > or > > C) Not sure, because I haven't ever seen this problem. > > > Philip Actually I use the option B). Sorry if you are disappointed! (You were sarcastic first!) But I remember people saying CMOS is slow, copper can't be used as metal layer, and a better example: "We are reaching the silicon physical limits"! This is a kind of religion, I don't believe in "not possible", only in "I don't know how to do". Anyway, I don't claim to know everything. If you get more persuasive I can change my mind. At last, I really liked your first post, I found it very elucidative (really, no joke). Luiz CarlosArticle: 59813
In article <8471ba54.0308281344.364a2a0d@posting.google.com>,
Luiz Carlos <oen_br@yahoo.com.br> wrote:
>But I remember people saying CMOS is slow, copper can't be used as
>metal layer, and a better example: "We are reaching the silicon
>physical limits"!
>
>This is a kind of religion, I don't believe in "not possible", only in
>"I don't know how to do".
However, there are many thing which are "NOT POSSIBLE" barring a
massive change in our understanding of basic physics and math.
It is not possible to build a perpetual motion machine ("In this house
we obey the laws of thermodynamics!").
It is not possible to measure a particle's position and velocity with
perfect precision (heisenberg uncertanty principle).
It is not possible to have two energetically stable local-minima
without an energetically-stable local maxima between them: a point of
metastibility.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
Article: 59814Click at http://www.xilinx.com/xcell/xl24/xl24_20.pdf This circuit allows totally asynchronous selection between two clock sources. But remember: both clock must be wiggling (however slowly). You cannot use this circuit to enable/disable a clock, which is actually a far simpler problem. The BUFGMUX in Virtex is not quite this clever, it has a set-up time requirement on the S control input. :-( Glad that someone found this old tidbit useful... Peter Alfke ============================= Marten wrote: > > "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message > news:bilfne$sel$1@home.itg.ti.com... > > Hi all, > > I have a vhdl component with a "clock_in" input. Depending on the mode of > > operation, I want to switch between two different clock signals. I will > > never switch on the fly though. Can I use a mux in front of the clock_in > > input? I'm afraid it might glitch. > > Thanks > > David > > > > > > David, > > Do a query for 'clock sources' in the category 'XCELL Journals' on the > Xilinx web site. This will provide you with a link called 'XCELL 24 - > Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead you > to xl24_20.pdf, a neat little circuit that hopefully will ease your worries > :) > > Keep in mind that whatever you put in the clock path will affect the setup > and hold time requirements for the particular component. > > Take care, > > Marten > > ] remove the obvious to repy by e-mail [Article: 59815
Andrew, I know, and I hope I made that clear in all my comments, App Notes, and TechXclusives. Metastability is unavoidable in asynchronous interfaces. Where I differ from most correspondents: I have measured it and described it quantitatively, using modern CMOS flip-flops. That's why I can state with certainty that the window is 0.07 femtoseconds for a 1.5 ns delay. How often your system might change inside that window is up to you to calculate... Peter Alfke Andrew Paule wrote: > > Hi Peter: > > the problem with metastability is probably best understood by looking > through some of the ieee papers by Dike and Burton - these guys did the > measurements and there is no solution - metastability requires thermal > noise on two nodes inside a flop(including the Xilinx model that I saw a > couple years ago) to force the output change, and that's a statistical > quantity - metastability can reign out to infinity, although the > probability is small. No solution known to us under device physics as > we know it now, just getting the probabilities smaller. This is why > hold time is just a statistic, and much like we qualify things under > BERT and jitter (more statistical quantities), we are human and guessing > our best. > > Andrew > > Peter Alfke wrote: > > >Luiz, > >you need to read up on metastability. > >There are things even in physics that have no solution. Perpetual motion > >is one. If you want to get philosophical about metastability, read > >Heisenberg's Uncertainty papers. > > > >Phil Freidin has described the problem very well. He and I agree 100% on > >the problem. But I have made quantitative tests and know the (very low) > >probability. Everybody has an opinion, very few have performed measurements... > > > >Peter Alfke > >================================= > >Luiz Carlos wrote: > > > > > >>Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... > >> > >> > >>>The output level of a flip-flop during its metastable time is > >>>irrelevant. If it were in the middle ( which it isn't) we could easily > >>>fix this with a zener diode. > >>>The problem is timing. The Q output can - and will - change to the > >>>opposite state at a totally unpredictable time. That's the problem: > >>>unpredictable timing, not unknown levels. > >>> > >>>Cascading flip-flops is the standard remedy, but it introduces latency. > >>> > >>>Remember: Metastability causes an extra 3 ns of unpredictable delay once > >>>in a billion years... Seems to be an affordable risk. > >>> > >>>Peter Alfke > >>> > >>> > >>Peter, kind of disagree. > >> > >>Of course for the designer, the problem is timing. But the timing > >>problem is caused by the voltage problem. If we had a well defined > >>voltage behavior (as I thought, but now I know I were wrong), we could > >>fix the timing problem (as you said for the "in the middle" problem). > >>Anyway, I undestood what you said. > >> > >>I also disagree that the problem has no solution. As an engineer I > >>don't believe in no solution problems, we just don't know the > >>solutions yet. But this is philosophy! > >> > >>Luiz Carlos > >> > >>Article: 59816
I am ready to accept royalties from Altera users... Peter Alfke =================== John_H wrote: > > Fortunately there are things that come out of Xilinx that are applicable to > all digital logic. > That XCELL article is one of them if you chose to look. > > "Andrew Paule" <lsboogy@qwest.net> wrote in message > news:a2t3b.29$qq3.17593@news.uswest.net... > > this is dependant on what chip he is using - is this only a xilinx > > newsgroup? > > > > Marten wrote: > > > > >"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message > > >news:bilfne$sel$1@home.itg.ti.com... > > > > > > > > >>Hi all, > > >>I have a vhdl component with a "clock_in" input. Depending on the mode > of > > >>operation, I want to switch between two different clock signals. I will > > >>never switch on the fly though. Can I use a mux in front of the > clock_in > > >>input? I'm afraid it might glitch. > > >>Thanks > > >>David > > >> > > >> > > > > > >David, > > > > > >Do a query for 'clock sources' in the category 'XCELL Journals' on the > > >Xilinx web site. This will provide you with a link called 'XCELL 24 - > > >Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead > you > > >to xl24_20.pdf, a neat little circuit that hopefully will ease your > worries > > >:) > > > > > >Keep in mind that whatever you put in the clock path will affect the > setup > > >and hold time requirements for the particular component. > > > > > >Take care, > > > > > > > > >MartenArticle: 59817
To add to Peter's response. Platform Flash is electrically erasable and programmable via the four boundary scan (JTAG) pins of the device making it very easy to erase and reprogram in your system as you find necessary. Bruce Jorgens Peter Alfke wrote: > The word "Flash" means that it is electrically erasable. > > Peter Alfke > ==================== > Atif wrote: > > > > Can anyone please tell me is Xilinx Platform Flash PROM an Electrically > > erasable? If no, which technology it uses? > > > > Regards > > AtifArticle: 59818
In article <rzt3b.288788$uu5.63948@sccrnsc04>, gah@ugcs.caltech.edu says... > I used to hear stories, though I am not sure that I believe them, of people > seeing metastability effects on the PDP-10 (KA10), which used self timed > logic. Supposedly they could see it stop processing, and then start again > with no ill effect. How they know it wasn't in I/O wait, or some other such > state, I have no idea. Sorry for being skeptical, but they "saw" it stop processing for approximately 10 to 100 ns that the metastability would resolve and then they saw it start again? -- Rich Iachetta I do not speak for IBMArticle: 59819
Andrew Paule wrote: > > Hi Peter: > > the problem with metastability is probably best understood by looking > through some of the ieee papers by Dike and Burton - these guys did the > measurements and there is no solution - metastability requires thermal > noise on two nodes inside a flop(including the Xilinx model that I saw a > couple years ago) to force the output change, and that's a statistical > quantity - metastability can reign out to infinity, although the > probability is small. No solution known to us under device physics as > we know it now, just getting the probabilities smaller. This is why > hold time is just a statistic, and much like we qualify things under > BERT and jitter (more statistical quantities), we are human and guessing > our best. The (simple) statistical models must fall down when they hit the quantization of single electrons. How close are we to that ? Has anyone tried to actually plot the tail of time/probability, to see what law it follows ? How does this actual tail vary with temperature. -jgArticle: 59820
Thanks Jeff! About four days after I made the posting (after I quoted my customer with a guess) National send me a PDF of it. I noticed you work for Xilinx...I am currently working on a project using your XC2V250/1000 family. Cool chip! Thanks again, Colin "Jeff Seltzer" <Jeff.Seltzer@xilinx.com> wrote in message news:3F4E68B8.5AD03006@xilinx.com... > If you're still having any difficulty finding that PAL20L10 info, I have a > copy of the original article, the 1989 NS PLD Databook. As it turns out, I > was the original NS apps engineer who organized that book project (in a > former life). My copy even has some errata in red ink. When I saw your > posting, I just couldn't resist... aren't newsgroups wondrerful! And I > think by now I shouldn't have to worry about too many more support > questions coming in about this one! Let me know if you'd like me to fax you > a copy. > > Regards, > Jeff Seltzer > > Colin Jackson wrote: > > > Thanks, I had never heard of them. > > Looks like a great service. > > > > I emailed National directly without a responce. > > A guess their too big for their customers! > > If I operated like them I'd be on welfare. > > > > "Valeria Dal Monte" <aaa@bbb.it> wrote in message > > news:Zdr_a.241160$lK4.7357861@twister1.libero.it... > > > > > > "Colin Jackson" ha scritto nel messaggio > > > news:f_ydnYyhuIk3qaSiXTWJgA@comcast.com... > > > > Anyone have a datasheet for a National PAL20L10? > > > > > > At www.freetradezone.com there is the AMD PAL20L10 data sheet > > > for free. The National version is available for the subscribers only. > > > > > > >Article: 59821
On 28 Aug 2003 12:52:11 -0700, oen_br@yahoo.com.br (Luiz Carlos)
wrote:
>Nobody knows everything. Physics don't change (I hope), but the way we
>model it is always evolving. Things considered impossible became
>possible.
This is the classic defense of otherwise indefensible ideas. "They
said that a flying machine was impossible." "They said that Einstein
was crazy." Statements like these ignore certain realities, namely:
(a) Much of what was said to be impossible still is, and shows every
sign of remaining so. If you believe that there are laws of physics,
even laws that are somewhat at odds with the ones we now hold true,
then those laws must say that certain things can happen and others
cannot. If they don't, they aren't laws.
(b) In all of human history, most of the people "they" called crazy
were, in fact, crazy.
Luiz, it's fine with me if you want to believe that metastability can
be prevented. But for all of you folks who have been reading this
thread and wondering just what to do about metastability in your
designs, just read Philip Freidin's excellent summary and follow the
link he pointed to for more information.
Do we really want to keep repeating the same old mistakes? Woudn't it
be more fun to make some new ones?
Bob Perlman
Cambrian Design Works
Article: 59822Hi Jim - this has nothing to do with quantization, until you get into QED, but is a matter of statistical thermal noise on two cells that are used to jam the outputs of a flop. You need the noise, but that has nothing to do with undergrad quantum mechanics. Read Peter's stuff - he's quite good and knowledgable. Andrew Jim Granville wrote: >Andrew Paule wrote: > > >>Hi Peter: >> >>the problem with metastability is probably best understood by looking >>through some of the ieee papers by Dike and Burton - these guys did the >>measurements and there is no solution - metastability requires thermal >>noise on two nodes inside a flop(including the Xilinx model that I saw a >>couple years ago) to force the output change, and that's a statistical >>quantity - metastability can reign out to infinity, although the >>probability is small. No solution known to us under device physics as >>we know it now, just getting the probabilities smaller. This is why >>hold time is just a statistic, and much like we qualify things under >>BERT and jitter (more statistical quantities), we are human and guessing >>our best. >> >> > > The (simple) statistical models must fall down when they hit >the quantization of single electrons. > How close are we to that ? > Has anyone tried to actually plot the tail of time/probability, >to see what law it follows ? > How does this actual tail vary with temperature. > >-jg > >Article: 59823
"Josh Model" <model@ll.mit.edu> wrote in message news:vE23b.67$Y5.42@llslave.llan.ll.mit.edu... > Responses *'d > > > > I must find the index of the maximum of 40 or so (unsorted, of course) > > > 20-bit numbers. --the specifics aren't that important, just helps me > > think. ... > *Right. we get all 40 numbers (outputs of Multiply accumulates) once every > N clock cycles, with N probably being determined by the update rate at which > we can find the maximum. In the ideal situation, N = 1, and we update the > maximum index every clock cycle. What's the operating clock rate? If you are running in the low tens of MHz just up your internal FPGA frequency. That's the "FPGA way". Also, can you use any information prior to the MAC to pre-calculate which result will be the largest? Are the coefficients fixed? You get the idea. What's feeding data into the FPGA? Can any intelligenge be derived from this source? It seems to me that the best you can do is a parallel binary search type algorithm. It will take several clocks no matter what. Another option might be (WARNING: IT'S UGLY AND GENERALLY BAD DESIGN) to hand place all the components and look into a fully combinatorial solution. Depending on your clock rate you might be able to pull this off. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 59824
Matt, Glad to hear that your configuration is working. Thanks for the feedback on App Note 250. We have since replaced this App Note with a chapter in the Cyclone Handbook. The link follows: http://www.altera.com/literature/hb/cyc/cyc_c51013.pdf We have updated the file type descriptions in this new chapter. There's a section called "Device Configuration Files" which describes the file types. Sincerely, Greg Steinke gregs@altera.com Altera Corporation matt@ettus.com (Matt Ettus) wrote in message news:<e8fd79ea.0308271334.7dab22@posting.google.com>... > The problem turned out to be in the file I was sending. I was using > an SOF, because I thought it was raw. Once I found the .rbf option, I > switched to that, and it works now. I didn't find mention of this in > appnote 250, which is on Cyclone configuration. > > Thanks for your help. > Matt
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