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
Ray Andraka wrote: > Where slack does come into play with metastability is that your > metastability resolution time available is equal to the slack time. If your > path leading from your syncronizer has little slack, your chances of a > metastable event lasting long enough to matter is greatly increased. You > want to maximize the slack after a synchronizer, preferably with > geographically close registers with no intervening logic. I'd also suggest a TO:FROM spec for the path between the syncronizer and the next register. A suggested value would be: period - needed_extra_delay - jitter_budget Where the needed_extra_delay is more than enough to meet the MTBF goals your design requires. Without this, the router might send this path round the chip a few times until there wasn't enough extra delay, even with registers nearby... -- Phil HaysArticle: 49676
Does anybody have the dates that specific versions of xilinx fpga's were first produced? I am hoping to get dates to within 1 month. I am looking for the dates that these or any other devices were produced. Virtex II 2V40 2V80 2V250 2V500 2V1000 2V1500 2V2000 2V4000 2V6000 2V8000 Spartan IIE XC2S50E XC2S100E XC2S150E XC2S200E XC2S300E XC2S400E XC2S600E Spartan II any version Thanks MattArticle: 49677
> Looking at it closer, you are right. >You can (slightly) reduce the probability with voting, but cannot avoid >a 'just under vote' becomming 'just over vote' after the metastable >delay, >and so cannot force a MAX value on the metastable time. How does voting "(slightly) reduce the probability"? Here is my analysis. The setup times will be slightly different. Pick the middle FF and concentrate on that. It will go metastable as often as any single FF. You have added logic that eats up some of the settling time so I claim that's worse rather than better. > Simpler/better results can be got with opposite edge cascaded >registers. Beware. Using opposite edges eats up a half cycle of settling time. What sort of MTBF does that leave you? Don't forget to round down in case of clock asymmetry. -- 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.Article: 49678
ted wrote: > Be careful when buying these devices second hand, as the specs say the > guaranteed number of programming cycles is only 100 times. YOu may get > a "retired" device. Hmm, never noticed that in the datasheet. > You may be better off buying CPLDs from Xilinx. Xilinx sells online > via their website I think (postage and import duty may cost you dear > though!). I've just finished looking at their website - the XC9500 CPLDs look very nice, plus some of them are available in PLCC packages. And to top it all off they've got a UK disti who (from experience) is quite good at giving out samples. > Their parallel programmer is also easy to make and you can download > the circuit from their website. Guess that settles it - Xilinx it is :-) It's just a shame that Farnell don't seem to stock XC9500 CPLDs... I think they stock some of Xilinx' FPGAs though. Later. -- Phil. philpem@despammed.com <<-- Yes, this address is real... http://www.philpem.dsl.pipex.com/Article: 49679
>I feel bad now. I started this thread because I had hoped to get some >definitive information to take back to a discussion that was hot in >comp.lang.forth a few days ago. I had some people over there telling me >that they could "cure" metastability or that it was dealt with in the >chips. There was even one chip designer who told me that you could >safely "ignore" metastability in modern logic (modern being anything >smaller than 0.25 um) because of the high settling speeds. The only "cure" is to wait long enough so that the MTBF is good enough. Most of the time, especially with modern silicon, you can get that out to the age of the universe. But you have to keep an eye on things, for example to make sure that the the placer or router doesn't do something silly. It's only "dealt with in the chips" if the designer thought about it and did the right thing. Yes, it is possible/reasonable to have asynchronous inputs to chips. But check the spec sheets. Take FIFOs for example. Is write really a noop if the FIFO is full? What happens if you write to a full FIFO just at the wrong time relative to a read? (I think we got burned by this, or maybe we were just paranoid.) I don't think you can ignore the issue, at least not "safely". All that you need to cause problems is for the router to do something dumb and we all know how often that happens. Note also that real data is very hard to get. -- 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.Article: 49680
Dear Group I hope it is the right place to ask this question with so many IC designers around. I often have to do PCB layout with standard components and it always makes me wonder, "Why are address bus/ data bus/ power/ ground pins placed that or this way?" Take for example industry standard flash memory 29x010 with oddly placed A10 pin. Or MIC2550 USB transceiver with mixed up DPLUS and DMINUS pins. I understand legacy issues and existing packaging constrains. Apart from this what rules do you follow doing pin assignment? Many Thanks NuBe.Article: 49681
>Denial: Early 70s - Widespread disbelief. Early analyses documenting >inevitability of problem rejected by skeptical journal editors. > >Folk Cures: 70s-80s - Popular pastime: Concoct a “Cure” for the >problem of “synchronization failure”. Commercial synchronizer >products. > >Reconciliation: 80s-90s - Acceptance of the reality: synchronization >takes time. Interesting special case solutions. Sounds about right. I had friends working at BBN in the early 70s. They worked on the Arpanet IMP/TIP. One of them was out at Washington Univ, St Louis, for a year or so when much of the early metastability work was going on. He returned to BBN as a believer and being a smart/senior hardware guy he spread the word. They finally tracked down a nasty bug in the 316 IMP (the second generation IMP, less expensive than the first generation 516 military spec version). It was a "simple" metastability issue in the DMA logic. A word out of a packet would get dropped or stored in the wrong place or something nasty like that. He couldn't convince the designers (Honneywell) it was a problem. They didn't believe. It wasn't part of the culture yet. The software guys ended up hacking around it. They lined up a big row of add instructions and computed a cheap checksum as fast as possible. Observed reliability of the ARPAnet took a great step in the right direction. That was back in the days of TTL, well Schotky. Nothing was all that good at metastability. I remember getting burned when we tried to save a 1/2 cycle by picking a chip that clocked on the other edge. That particular chip was real bad at metastability. Sigh. In the early/mid 80s, there was a conference in San Francisco. I took the train up for the metastability session. One of the guys on the panel got it all wrong. I thought John Wakerly (Stanford) did the best job of explaining things, but I was already a believer so I'm not sure how much that counts. I do remember that he shot down an example or two of "fixes", concluding with "believe me" even if you can't find the bug in it. He did mention that he was covering it in classes so the word was getting out by then. -- 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.Article: 49682
Here is an interesting web page by Howard Johnson: http://www.chipcenter.com/eexpert/hjohnson/hjohnson020.html I think John Wakerly covers a lot of good points about metastability in his book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN 0-13-212838-1). He has a nice "ball and hill" description that I find very helpful. I think the ball/hill description is better than the balanced pencil. Consider two kids on the floor rolling a ball back and forth between them. Now put a bump in the middle. If you roll the ball slowly it goes half way up the bump and then comes back. If you roll it fast enough it goes up and over the bump and down the other side. If you roll the ball with a speed in the middle, there is some speed where it will get up to the top of the hill and ballance there until it falls off. That's the metastable case. Note that there is sure to be some speed that will cause problems. (Math geeks have a good term for it - continious functions or something like that.) I don't have a good/simple story for why "fixes" don't work. The runt pulse on the reset is enough to make me very suspicious. If you start with the ball/hill example, could you fix that so it couldn't dally on the top? -- 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.Article: 49683
nospam <nospam@please.com> wrote in message news:<653itussjd8u3unrcraov00snerb6e1t7q@4ax.com>... > already5chosen@yahoo.com (Michael S) wrote: > > >> The 'problem' inside the 386 is almost certainly a race and not > >> metastability. > > >Do you think 386EX uses READY# input in multiple state machines > >without sampling it in one FF ? If it was the case, I would expect the > >problem to appear much more often then it actually does. > > The timing specs for READY# and signals changing due to the completion of > the cycle (which occurred because of READY#) are referenced to the same > clock edge. So READY# is not synchronised with a single FF or everything > would be delayed by a cycle. You assume that output signals are driven by FFs. I think it's not a case. According to 386EX datasheet RD# Valid Delay is 4 to 30ns, CS# Valid Delay is 4 to 33ns. Both numbers suggest that signals are driven by combinatorial logic. > > What READY# actually feeds I don't know but you don't need multiple state > machines to race just multiple FFs which a single state machine has. When I said multiple state machines I ment multiple FFs.Article: 49684
We've recently launched a website where you can purchase Altera FPGA related hardware. Currently we offer a byteblaster-compatible programmer. Have a look at www.logicblock.com and mail us if you have any enquiries about related products. Products in the pipeline include small evaluation boards and a USB programmer. Bulk discounts are also available. All products are orderable via a secure server and shipping is done worldwide.Article: 49685
hmurray@suespammers.org (Hal Murray) wrote in message news:<utiom46n1pu6a7@corp.supernews.com>... > >I have tried to analyze the behaviour of such an analogy in the presence > >of noise, but I don't have the tools to do it rigorously. It may well > >be possible to shorten the metastable time with noise, but I really > >can't prove it one way or the other. > > Somebody mentioned noise recently, but I'll repeat. It doesn't work. > It kicks the system toward the stable point just as often as it helps > you by kicking the system in the right direction. > As I said above, there is very short time (metastability-catching set-up time window) when noise has a chance to kicks the system in the wrong direction. On the other hand, in the properly designed system there is much longer time (slack time) when noise might move a node out of metastability. According to Xilix estimations metastability-catching set-up time window is 7 orders of magnitude shorter than typical slack time, so the negative effect of the noise is negligible relatively to its positive effect. Before you start to argue, try to realize that I am not talking about metastability as a theoretical phenomenon but about metastability as something which can compromize the correctness of the design. You are right, noise doesn't reduce the probability of entering metastable state. However, it does increase a probability of resolving metastability within a slack time window. If metastability resolved within a slack time window - nobody care about it. I don't even know how to detect the case. From the practical point of view the case is the same as when metastability didn't happen. Once again, I expect metastability-affected system to performe better (produce longer MTBF) at higher temperature. I don't know how much better. I would be glad to see the measurements results. Because Xilix Lab alredy has a proper setup for the mesurements it must be easy for them to repeat the tests at -40Deg and at +70Deg. It's all I am asking for.Article: 49686
I don't suggest the noise as a cure for metastability. I only say that measurements methodology, described in Xilix Lab article is likely to be affected by the temperature. If Peter Alfke (or his stuff) would be so kind to repeat the mesurements at lower temperature (-40Deg for example), I would be pleased to see the results. rickman <spamgoeshere4@yahoo.com> wrote in message news:<3DD9AE93.E9811DFC@yahoo.com>... > Michael S wrote: > > > > I feel those "others" were wrong. > > There is relatively short period of time when noise might move a node > > into metastability. It's what Xilix calls the metastability-catching > > set-up time window. > > The time period during which noise might move a node out of > > metastability is typically much longer. This period is equal to the > > timing margin of your design, i.e. the difference between clock period > > and sum of the normal flip-flop delay, longest wire delay, > > combinatorial logic delay and the setup time of the next flip-flop. In > > the other words, the difference between actual clock period and the > > shortest possible clock period of the design. > > We call that slack time, the difference between the time allowed for a > given clock controlled path and the actual time needed. > > > > I have no experience in ASIC/Custom chip design, but when designing > > for FPGA I don't feel good when timing margin of my design is shorter > > then 500ps. According to Xilinx's estimation the duration of the > > metastability-catching set-up time window for their chips is 0.03 > > femtoseconds, i.e. 7 orders of magnitude shorter. > > How is the metastable timing window related to the timing slack? The > time window is the period in time where the input must be in the > undefined region of voltage to end up with a metastable internal state > that lasts long enough to affect the settling time. The timing slack is > the amount of extra time that is available for the output to settle > before it affects any FFs connected to the metastable output. These are > two different and unrelated aspects of metastability. > > > > So noise helps, I just don't know how much. > > I don't agree with your analysis, because you make an *assumption* about > the initial conditions which can lead to metastability, but that is not > the real issue. > > The real issue that the knowledge of noise reducing the metastability > settling time is not useful information. To be able to use noise as a > tool, you would have to provide a minimum noise spec. How can a spec be > generated of the required spectral characteristics of the noise to > reduce metastable failures? > > I think that if you try to answer that question, you will see why noise > does, in fact, *not* improve metastability recovery times. > > -- > > 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: 49687
Hal Murray wrote: > Here is an interesting web page by Howard Johnson: > http://www.chipcenter.com/eexpert/hjohnson/hjohnson020.html > > I think John Wakerly covers a lot of good points about metastability in his > book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN > 0-13-212838-1). He has a nice "ball and hill" description that I find very > helpful. > > I think the ball/hill description is better than the balanced pencil. > > Consider two kids on the floor rolling a ball back and forth between > them. Now put a bump in the middle. If you roll the ball slowly it > goes half way up the bump and then comes back. If you roll it fast > enough it goes up and over the bump and down the other side. > > If you roll the ball with a speed in the middle, there is some > speed where it will get up to the top of the hill and ballance > there until it falls off. That's the metastable case. Note that > there is sure to be some speed that will cause problems. (Math > geeks have a good term for it - continious functions or something > like that.) > > I don't have a good/simple story for why "fixes" don't work. > The runt pulse on the reset is enough to make me very suspicious. > > If you start with the ball/hill example, could you fix that so it > couldn't dally on the top? > As an ex maths-geek I'd say you are out of luck. If you plot the "kick energy" vs. the max outward distance from the kicker we know of 2 points on this curve. One where the max distance is < the top of the hill and one where its > than the top. So the theory of continuous functions says that there must be an energy value where the distance = the top. So much for maths, now for the issues hidden behind this: 1. Can the kick function take all possible energy values ? Imagine an FF so sensitive that it flips on receiving a single electron on its clock input. Is such a beast possible ? and if so would metatstability rear its ugly head now in the form of the uncertainty principle ? 2. Is the physical world really continuous in the mathematical sense ? This is a debate that's been going on for millenia and the modern notion of mathematical continuity only dates from Dedekind in the 1870s with our present definitions due, IIRC, to Cauchy a few years later. Note that even in a quantum mechanical description a particle's wave function is still assumed to be a continuous solution to the Schroedinger wave equation.Article: 49688
Hal Murray wrote: > <snip good stuff > > If you start with the ball/hill example, could you fix that so it > couldn't dally on the top? I've SEEN this in mini golf courses :) Illustrates the point of gain asymmetry very nicely. How about bumping the hill ? Imagine a hill, with the hiccups - what does that do to the maximum probable ball dally time ? How to give the hill Hiccups ? Well, in a FPGA, one simple technique could be to drive, or not drive, the surrounding logic, and see if there was any change in metastable times. The bumps would come from the natural ringing in the Vcc.Gnd planes. I would like to see temperature plots, not just the Vcc ones as the assertion Peter A. made of : "Measurements were taken at room temperature, but testing at VCC extremes gives an indication of performance at higher and lower temperature." I think needs to be tested : Low Temp = faster, but Low temp also is less thermal noise - which dominates ? It may be that the modern FPGAs are powerfull and flexible enough to get precision in the measurements, and to see 'better' and 'worse' directions from stimulus changes. Jim G.Article: 49689
Markus Fras wrote: > Hello, > > I'm looking for some advice concerning Altera's EPC16 device. The problem is > that I'd like to programm it in circuit via JTAG, but it just doesn't work. > The JTAG chain is o.k., I can successfully scan the chain read the ID code, > perform a device blank check. Also the programming procedure does not lead > to an error. But when I try to verify the data it fails at once. I've tried > with Quartus II V1.1 and Altera's jam-player, both with the same result. As > download cable I'm using a standard Altera ByteBlasterMV. > Has anybody an idea, what could be wrong or what I could try to get more > information about the situation? Any advice is very wellcome - Thanks in > advance! > > Markus Fras > > I recently found that the cable between the programmer and the chip was causing errors. I reduced the length and it worked fine, even with 1.5 meters of round cable between the programmer and the PC parallel port. Paul Bealing www.pmb.co.nzArticle: 49690
Hi Everyone, I'm using an fpga with the clock temporarily off and so have only combinational logic. Now, in this mode I need to generate a signal which is a falling edge only. This edge needs to be produced whenever there is any change (rising or falling) on any one of a set of input signals. I've got as far as using XOR on all the inputs to produce a toggling signal but I am now at a loss as to how to convert this to a falling edge only. toggling_output <= A xor B xor C .......... falling_edge_only <= ????? I suspect there is either a simple answer or it is impossible. Anybody know which? Solutions that will synthesise in VHDL would be appreciated. My synthesis tool rejects all my attempts although they simulate perfectly as a functional models. Thanks for any pointers PhilArticle: 49691
I am curious about this as well. Could you not just write a normal rising edge detector and invert the signal of interest prior to being placed on the input of the edge detector?Article: 49692
Dear all, I am designing an PLD using ALtera and now I require a functionality check to be performed. I have a data from a device "Serializer Deserilaizer" and this has to be sent to the APEXii and then received from it for which the functionlaity test has to be performed. one can also call it a feedthro´ check. I f any one of U has the prog could u pls share it with me. Luv VickyArticle: 49693
Phil Connor <phil_j_connor@hotmail.com> wrote: > Hi Everyone, > > I'm using an fpga with the clock temporarily off and so have only > combinational logic. > > Now, in this mode I need to generate a signal which is a falling edge > only. This edge needs to be produced whenever there is any change > (rising or falling) on any one of a set of input signals. > > I've got as far as using XOR on all the inputs to produce a toggling > signal but I am now at a loss as to how to convert this to a falling > edge only. > > toggling_output <= A xor B xor C .......... > > falling_edge_only <= ????? > > I suspect there is either a simple answer or it is impossible. Anybody > know which? simple. > Solutions that will synthesise in VHDL would be appreciated. My > synthesis tool rejects all my attempts although they simulate > perfectly as a functional models. If "SIG='1' AND NOT SIG'STABLE" (or 'EVENT) is the complete conditional expression for the common synthesis shorthand "RISING_EDGE(SIG)", what is then the expression "SIG='0' AND NOT SIG'STABLE"? Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection)Article: 49694
Thanks for the answers!
I know now, that the input Pin GCK0 isnt a clock input in my schematic.
GCK0 => IBUFG => CLKIN from CLKDLL
The follow assignment is in my constraint file:
NET "gck0" LOC = "p80";
If i take this, i will not get a clocksignal.
If i take LOC = "DLL0", then the constraint file editor will overwrite
it with old value.
If i take LOC = "p187", then the follow error message will appear:
"ERROR:MapLib:103 - symbol "gck0" (pad signal=gck0) driving
IBUFG->CLKDLL is
LOCed to a generic IOB site. It must be LOCed to a GCLKIOB site."
If i have not got:
* a input gck0
and
* old systemclock (pin 185,
with 'TIMESPEC "TS_clk_a1" = PERIOD "clk_a1" 48 MHz HIGH 50 %;')
and
* INST XLXI_15 LOC="DLL3" is in my constraint file
(without using the editor, i dont know where is this option)
(XLXI_15 is the instname of ibufg).
then the projectmanager say the ucf-file is corrupt.
Unfortunately the documents ds001_2.pdf and xapp174.pdf dont help me by
this problem.
The documents can be found in support from xilinx.
I have try many others possibilities, but none were successfully.
I dont know, what i m doing wrongly.
I will be glad, if i can get more informations or answers.
with kind regards
Stefan
Article: 49695
This is true. With the pre 4.1i router, you could depend on the router using the
direct path if the flip-flops were located in adjacent slices. The new router
generally will not use that unless it deems it to be a critical path (which
putting the from:to spec forces). The new router apparently selects a few
critical paths based on slack times, nails those down then routes the rest not
caring how much time or resource is used as long as the slack is non-negative.
This is one of the cases where it matters. (BTW, routing the way the router does
it now also increases the power consumption considerably).
Phil Hays wrote:
> Ray Andraka wrote:
>
> > Where slack does come into play with metastability is that your
> > metastability resolution time available is equal to the slack time. If your
> > path leading from your syncronizer has little slack, your chances of a
> > metastable event lasting long enough to matter is greatly increased. You
> > want to maximize the slack after a synchronizer, preferably with
> > geographically close registers with no intervening logic.
>
> I'd also suggest a TO:FROM spec for the path between the syncronizer and
> the next register. A suggested value would be:
>
> period - needed_extra_delay - jitter_budget
>
> Where the needed_extra_delay is more than enough to meet the MTBF goals
> your design requires.
>
> Without this, the router might send this path round the chip a few times
> until there wasn't enough extra delay, even with registers nearby...
>
> --
> Phil Hays
--
--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: 49696Hello, can someone point me to how I will be able to instantiate a Virtex II - IOB component for implementing some logic in the IOB and use the available registers? I use Leonardo Spectrum for Synthesis and I know I have an option to Map registers in IOBs. But I want to be able to do it manually in a vhdl file. Thanks AnupArticle: 49697
Ray Andraka wrote: > > Where slack does come into play with metastability is that your > metastability resolution time available is equal to the slack time. If your > path leading from your syncronizer has little slack, your chances of a > metastable event lasting long enough to matter is greatly increased. You > want to maximize the slack after a synchronizer, preferably with > geographically close registers with no intervening logic. > > rickman wrote: > stuff about slack time not being related to metastability That is the well understood part of metastability. I was commenting on Michael's post which seemed to confuse the very small calculated input time window which will result in a FF going metastable and slack time which will provide settling time for the metastability to be resolved to a defined state. These are two independant concepts and even though they are both aspects of metastability, they have nothing to do with one another. -- 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: 49698
Hal Murray wrote: > > >I feel bad now. I started this thread because I had hoped to get some > >definitive information to take back to a discussion that was hot in > >comp.lang.forth a few days ago. I had some people over there telling me > >that they could "cure" metastability or that it was dealt with in the > >chips. There was even one chip designer who told me that you could > >safely "ignore" metastability in modern logic (modern being anything > >smaller than 0.25 um) because of the high settling speeds. > > The only "cure" is to wait long enough so that the MTBF is good enough. > Most of the time, especially with modern silicon, you can get that out > to the age of the universe. > > But you have to keep an eye on things, for example to make sure that > the the placer or router doesn't do something silly. > > It's only "dealt with in the chips" if the designer thought about it > and did the right thing. Yes, it is possible/reasonable to have > asynchronous inputs to chips. But check the spec sheets. Take > FIFOs for example. Is write really a noop if the FIFO is full? > What happens if you write to a full FIFO just at the wrong time > relative to a read? (I think we got burned by this, or maybe we > were just paranoid.) > > I don't think you can ignore the issue, at least not "safely". > All that you need to cause problems is for the router to do > something dumb and we all know how often that happens. > > Note also that real data is very hard to get. You are preaching to the choir. The trouble is that it is very hard to convince people of this when they don't want to believe. As you say, there is little data on the subject that does more than show it exists. Fortunately it is quite easy to deal with in the vast majority of designs, as long as you understand that you do *need* to address it. -- 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: 49699
I am trying to implement the baseband layer of Bluetooth on an FPGA, using Xilinx (project navigator) software. I have produced a simple maximal shift sequence and now want to Gaussian filter this. Has anybody used this software to complete this task before? If so could you offer me any hints or tips on how to start as I'm clueless, I had never used an FPGA or HDL until last week! Thanks very much Tom
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