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
Thanks for your help, so far. Really appreciate it. I'm already a step further in my considerations. Now I'm looking for a diagram like frequency (some MHz to 10 GHz for example) versus loss tangent and / or epsilon R for FR4. I only found a poor black-and-white copy from 1991 in a paper which I searched with Google. I wouldn't have thought it to be so hard to find a graph... Does anybody know where I can find that?Article: 115551
Gabor wrote: > On Feb 12, 12:58 pm, Magne Munkejord <Magne.Munkej...@student.uib.no> > wrote: >> Thanks for your reply! >> >> >> >> Sean Durkin wrote: >>> Magne Munkejord wrote: >>>> Hello, >>>> I have a design with several LVDS transceivers. The design works well >>>> when all ports are connected but once some ports are unconnected I start >>>> receiving garbage from the floating inputs. >>> Well, what do you expect them to give you? If they are not connected, >>> and neither pulled to ground nor to VCC, you get something in between, >>> and that depends on the temperature, humidity, moon phase, your karma, >>> whatever... That's why it's called "floating", because the input floats >>> somewhere in between. Most of the time somewhere around the middle >>> exactly where the decision threshold between 0 and 1 is, so sometimes >>> you get 0, other times you get 1, which translates to garbage. >>> As the warning states, if you do attach PULLUP or PULLDOWN primitives, >>> this might affect signal integrity. You might be OK with that, or it >>> might screw up your data, that's for you to decide. As you know, the >>> differential termination won't resolve the issue with the floating >>> inputs. So, pullups/-downs might be a solution, but only if it doesn't >>> affect signal integrity too much, which it seems to do in yout case >>> (since you still get garbage sometimes despite of the pullups). >> Sorry, inaccurate information from my part. When I leave all ports >> unconnected (no cables attached) 1 out of 8 channels still receives >> garbage. When I connect cables from one port to another >> data-transmission seems to be in order (2 of to 2 words received, 100% >> signal integrity :) I need more statistics on this). >> >>>> If anyone have any suggestions on how to handle unconnected ports please >>>> let me know. >>> Yes, ignore everything you get from floating inputs. >> Easier said then done. The final design will have 120 serial channels. >> Received data words from each channel will be stored in a shared memory >> so I need to filter out the garbage words before I store them. >> >> >> >>> HTH, >>> Sean >> I am well aware of the problem that a floating input acts like an >> antenna. (At least I am now :) Since pullups and pulldowns are not an >> ideal solution, I was hoping there might be a way to detect an >> unconnected port/input and disable this channel. >> I see that in my original post, I left out some vital information; The >> lvds lines are used for serial data transmission over cat5 TP cables. >> Non-Return-to-Zero encoding with 4 cycles per bit, 32 bit words, 2 start >> bits, one parity bit and one stop bit. When the lines are idle the >> transmitters should hold the lines high (when looking at the >> single-ended signals from my IBUFDS/OBUFDS). >> The situation now is that, if by chance, a floating input stays low for >> 4 cycles and high for the 4 next, I start sampling for data bits. Of >> course I can discard words with stop bit error and/or parity errors but >> this method is not bullet-proof. >> Maybe I should try to make a more demanding/critical start condition? I >> will try to experiment a bit or two. >> As you say, these are design considerations I will have to make myself. >> I was thinking that this might be a common problem with a good solution >> but I can't find any discussions/articles about it on the Xilinx >> website. Thats why I made this thread. If anyone have some experience to >> share with me I'd be grateful. > > > It may be possible to fix this inside the FPGA if you can add a pullup > to the positive input and a pulldown to the negative input of each > pair. > Even then, I wouldn't count on this arrangement working well due to > the > relatively low value of the differential termination resistor and the > resulting very low voltage created by the weak pullup/pulldown pair > (assuming the P&R tools really place these components). > > Another approach is to add external pullup/pulldown resistors to bias > the > signals when disconnected (also not optimal). There are LVDS receiver > devices that have guaranteed outputs when the inputs are floating. > They > do this by sensing that the common mode input voltage is above the > high limit (there is an internal pullup to create this CM voltage when > the inputs float). The FPGA could do this with an additional I/O > attached to one of the LVDS pair, but if you're trying to run too > fast you'll have issues with the unbalanced capacitive loading. > > So probably the best way to avoid this mess is to use a protocol with > guaranteed AC and DC characteristics like 8B-10B. You can then > easily detect error conditions and disable the disconnected links. > > Regards, > Gabor > Thanks Gabor. I've looked into the 8B-10B encoding that you suggested. It is not likely I will have time to implement this but I would like to say something about it in my master thesis. You say that it is easy to detect error conditions and I have tried to figure out how this can be done. When you mention AC and DC characteristics I assume you are thinking of that each encoded 10-bit word would contain 5 zeroes and 5 ones. So if I count the number of ones and zeroes over an interval and see a signicant difference in numbers then this would indicate a floating input? Or should I simply look for invalid 10-bit words? Words that would not be part of the alphabet for this encoding scheme. Can you please let me know if I got this right?Article: 115552
> Hi, I've been wondering for a while if there is any data about
> typical clock frequencies of FPGA designs for various FPGA
> devices.
Me too. :)
My rule of thumb (take with a pinch of salt!):
* Take the manufacturer's headline speed figure for the part
* Anything over 66% of this is "fast"
* Anything less, but over 33%, is "slow"
* Anything less than 33% is a waste of space :-)
As Austin pointed out, there are many reasons why you might design for this
or that frequency, and one FPGA design might contain several distinct clock
domains, each chosen for a particular purpose. Or there may be several
locally-high-speed blocks which communicate over a lower-speed bus.
FPGA vendors' marketing departments doubtless have a lot of data on this,
but I suspect they'll be reluctant to let you have it!
Cheers,
-Ben-
Article: 115553You can use the functions provided by the Standalone BSP for this purpose. Refer to the PPC exception handling section of the Standalone BSP docs. - Vasanth "Ed" <RobotBuilder@charter.net> wrote in message news:1171072586.253725.95260@l53g2000cwa.googlegroups.com... > Hi, > > I looked through the Xilkernel documentation and Xilinx mentions a few > times about enabling and disabling interrupts and context switching. > I need to be able to do this but can't seem to find anywhere how to do > this. Anyone know how? I don't want to just enable and disable a > single interrupt. I want to disable other threads from executing for > a very short duration and turn off all interrupts. I am using a Power > PC on the Virtex 4 FX12 MM. > > Thanks, > -Ed >Article: 115554
On 13 Feb 2007 09:12:27 -0800, "Say Joe" <ngsayjoe@gmail.com> wrote: >>>> Another thing: one may prefer to not have a single language or to always use the same one. > >Yes, this is true. But there must be one that you like (favorite) ahem... - the one I'm not using this week - the (possibly nonexistent) language that supports the feature I desperately need to solve today's problem - the language my customer pays me to use - the language I can use with most confidence - the language for which my tools have fewest bugs - the language for which I can get free or cheap tools ... seriously - the best reason no-one wants to answer you is that we all know that the question is meaningless. If I answer the question "what is my preferred language" I know that I'm using my own criteria for preference, and everyone else's criteria may be different; so, if I post my preference on your forum, I can be sure that it is open to misinterpretation because you have not given me the tools to express my criteria. Take a look at the archives of John Cooley's DeepChip website; he asks specific questions of a very wide audience. Even that is open to accusations of ambiguity and bias. What you're asking is so vague as to be unanswerable by anyone who cares about honesty and clarity. Stop demanding answers to meaningless questions. If you want to find out what people really think about design languages, do a proper job and trawl through the archives of the relevant newsgroups, and the proceedings of relevant conferences like FDL and DVCon and DAC. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 115555
Hello all, I would like to do some simple and dirty DSP to roughly approximate a RC audio filter. I think I can do it something like this (PSEUDO code here, ignoring bit depths and multiplier instantiation issues) I am aiming for a cut of frequency of ~713 Hz Audio is an 8 bit unsigned output (from a YM2149 audio chip as it happens) Ena_20K is a single clock enable at my desired sampling frequency (Freq) wait until rising_edge(clk) if (Ena_20K = '1') then Audio_sampled <= Audio; -- sample output Audio_filtered <= Audio_filtered + ( Audio_filtered_t1 - Audio_filtered) * K Audio_filtered_t1 <= audio_filtered; -- previous value end if; Audio_out <= Audio_filtered(some top bits) Is this correct?? Can I get away with n bit unsigned maths, or do I need to offset / sign? Does anybody know off the top of their head how I calculate K given Freq and a cut of frequency? Anyone know of any good on-line resources? I have looked around a bit, but everything needs Matlab nowadays which I don't have handy at home :) I have done a lot of video filtering using FIRs, but I have forgotten the little I used to know about IIRs.... Any input gratefully received. Regards, MikeJ www.fpgaarcade.comArticle: 115556
Say Joe wrote: >>>>Perhaps instead of having simply "Others", it could allow someone to write something: e.g. "Others > > (please elaborate): I use ABEL and Java". > > Ohh, yes I forgot about ABEL, but it isn't supported in major FPGA > software Quartus and ISE, so what's the point? I try to include > languages supported by vendor software only. The point is you really need to do more homework. ABEL is supported in Xilinx and Lattice flows, and those that have it, can still do Atmel flows in ABEL. A better question is "What HDL language(s) do you use", as many designers use more than one. I have most lines of code in CUPL, but also ABEL, Verilog, VHDL, and I like the look of MyHDL, which is a python derivative. > There's a difference. Usenet postings will be archived after a few > months, but my forum poll is mean to run FOREVER. So, people can keep > growing the poll results in time. Not the way it is set up, they can't. Let user add languages, and tick more than one language, and it becomes half-usefull. -jgArticle: 115557
Andreas Ehliar wrote: > Hi, I've been wondering for a while if there is any data about > typical clock frequencies of FPGA designs for various FPGA > devices. > > What I'm curious about is if there is any sort of published > statistics about the clock frequencies used in different FPGA > designs on different FPGA architectures. > > Basically I'd like to have some empirical data as to what to > consider absurdly low, low, normal or high or extremely high in > terms of clock frequency in a certain FPGA device. I've got a candidate for absurdly low :) We have a CPLD design for a Clock(time variety) that starts at 32.768KHz, but we divide that a little before the CPLD uses it, so 1024Hz is the CPLD clock. The corner frequency (where the uA/Mhz adds 10% to the Static icc of 2.4uA) on this CPLD is around 10KHz, so I propose a more general rule : " Any frequency that barely moves the meter above Static Icc, qualifies as Absurdly low." Of course, on some FPGAs, that will be rather high.... ;) -jgArticle: 115558
On Feb 13, 2:08 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Andreas Ehliar wrote: > > Hi, I've been wondering for a while if there is any data about > > typical clock frequencies of FPGA designs for various FPGA > > devices. > > > What I'm curious about is if there is any sort of published > > statistics about the clock frequencies used in different FPGA > > designs on different FPGA architectures. > > > Basically I'd like to have some empirical data as to what to > > consider absurdly low, low, normal or high or extremely high in > > terms of clock frequency in a certain FPGA device. > > I've got a candidate for absurdly low :) > > We have a CPLD design for a Clock(time variety) that starts > at 32.768KHz, but we divide that a little before the CPLD uses it, > so 1024Hz is the CPLD clock. > The corner frequency (where the uA/Mhz adds 10% to the Static icc of > 2.4uA) on this CPLD is around 10KHz, so I propose a more general rule : > > " Any frequency that barely moves the meter above Static Icc, > qualifies as Absurdly low." > > Of course, on some FPGAs, that will be rather high.... ;) > > -jg You didn't mention the CPLD used, but I'm guessing that there are a number of reasons in addition to the maximum achievable clock rate that go into selection of an FPGA for a design. For the lowest cost per I/O parts, for example, I wouldn't be surprised if there were a number of absurdly slow designs running into significant volumes. I'm guessing the CPLD in this case was chosen for minimal power consumption. At 1024 Hz. there are a number of microcontrollers that would do the job of a clock quite nicely. My FPGA designs often have bits of random house-keeping or control functions that run much slower than the remainder of the design, but often the part is picked for a combination of size (LUTs and flip-flops) and frequency that determine my ability to move data through the part. As the matrix of options available in the newer FPGA families grows, many parts will be chosen for other features such as built-in SERDES or available block memory rather than the speed of the fabric. Designs that get close to the manufacturers published clock frequencies become rarer at the larger densities, but quite common in the smallest part of any family. So "absurdly fast" has to be tempered with part size as well as Fmax. Just my 2 cents, GaborArticle: 115559
"Uwe Hercksen" <hercksen@mew.uni-erlangen.de> wrote in message news:op.tnournbqni00lm@hercksen3... > On Mon, 12 Feb 2007 22:30:39 +0100, john jardine > <john@jjdesigns.fsnet.co.uk> wrote: > > > Had trouble with crosstalk on a mass of video signals. Cured with a > > multilayer board where each signal was 'boxed in' by ground plane to the > > sides, above and below. Sort of square coax. > > Hello, > > but how about a real closed square shield around the center conductor? > > Bye Would have been ideal. At the time was thinking about a method to do this and sorted a setup that may have been worth talking to the PCB people about but a customer was paying to clear down his urgent problem and not to start up a research project :). No ... I don't remember what I figured out. Ideas are easy, it's the implementation that's a problem :). No doubt it'll surface again if I'm I'm under pressure. john -- Posted via a free Usenet account from http://www.teranews.comArticle: 115560
MikeJ wrote: > I would like to do some simple and dirty DSP to roughly approximate a RC > audio filter. > I think I can do it something like this (PSEUDO code here, ignoring bit > depths and multiplier instantiation issues) > I am aiming for a cut of frequency of ~713 Hz There is a motorola booklet describing a stereo graphic equalizer built with a 56001. That would probably have all the logic you would need to do what you want. If you just want a simple low pass filter, I suppose you don't need that much, but then the 56001 is pretty old by now, so you should be able to do much more. -- glenArticle: 115561
Uwe Hercksen wrote: > On Mon, 12 Feb 2007 22:30:39 +0100, john jardine > <john@jjdesigns.fsnet.co.uk> wrote: > >> Had trouble with crosstalk on a mass of video signals. Cured with a >> multilayer board where each signal was 'boxed in' by ground plane to the >> sides, above and below. Sort of square coax. > > > Hello, > > but how about a real closed square shield around the center conductor? To do that would need plated slots, and slots have the PCB fabs luke-warm at best : hard to do cleanly, they also weaken the PCB if long, and also have minimum router sizes, plus machine time...... A better direction would be thinner laminates, and using the space you would have lost to the slot anyway, as wider GND webs on the same plane, coupled with stitching vias (which can be smaller dia than slots) -jgArticle: 115562
> There is a motorola booklet describing a stereo graphic equalizer > built with a 56001. That would probably have all the logic you > would need to do what you want. > Sounds interesting. I don't suppose you have a link? Google is currently failing me ... Thanks, MikeJArticle: 115563
[...] "werty" <werty@swissinfo.org> wrote in message news:1171348634.104020.242500@l53g2000cwa.googlegroups.com... > > ---------------------------------------------------------- > > Boxed ! the wavelength is far greater than > your dimensions , thus higher modes can not > exist , thus you do NOT need sides . > When you reach 10 Ghz , then maybe > you need sides in ur boxed "coax" . > > But the big joke , is in the real world , > they use cheap PCB to xmit 2.5 Ghz . > No strip line , no microstrip , nada .. > It works well , so quit arguing reality . > > BTW , i saw some novice , trying to > use juice cans to launch WiFi . > He figured the more cans , the more > gain . He had 3 cans , T'd . > to divide the power . > Gain is not in cans , its in size of > the dish . > > Another book worm said all i needed > was $26 for 100 meters of blah blah > coax at 2.5 Ghz .. > > 10 times that price ! > and 1.8" dia hard line ! > > At these wavelengths , its lower loss > to send it TEM and thru the air , > not thru a coax . > > This is goin to FPGA ? Do those relics > still exist ?! Oh well , i supose ya gotta > try to "protect" your firmware by reinventing > the CPU ! > Que?. Don't listen to the worms. Video comes in forms other than digital. -- Posted via a free Usenet account from http://www.teranews.comArticle: 115564
Gabor wrote: > On Feb 13, 2:08 pm, Jim Granville <no.s...@designtools.maps.co.nz> >>I've got a candidate for absurdly low :) >> >>We have a CPLD design for a Clock(time variety) that starts >>at 32.768KHz, but we divide that a little before the CPLD uses it, >>so 1024Hz is the CPLD clock. >>The corner frequency (where the uA/Mhz adds 10% to the Static icc of >>2.4uA) on this CPLD is around 10KHz, so I propose a more general rule : >> >>" Any frequency that barely moves the meter above Static Icc, >>qualifies as Absurdly low." >> >>Of course, on some FPGAs, that will be rather high.... ;) >> >>-jg > > You didn't mention the CPLD used, Atmel ATF1504BE / ATF1502BE > but I'm guessing that there are > a number of reasons in addition to the maximum achievable clock > rate that go into selection of an FPGA for a design. For the > lowest cost per I/O parts, for example, I wouldn't be surprised > if there were a number of absurdly slow designs running into > significant volumes. I'm guessing the CPLD in this case was > chosen for minimal power consumption. Yes, and for low IO pin cost. > At 1024 Hz. there are > a number of microcontrollers that would do the job of a clock > quite nicely. yes, but at 100 pins, they are more expensive than the cpld, ( as well as being considerably over-resourced !) and this is also partly a teaching example for CPLDs.... Finding a regulator that did not impact the Icc was quite a challenge ... -jgArticle: 115565
I am working on a design where the output rate is 3 Gbps, the fast internal logic runs at 300 MHz, but the bulk is human-oriented GUI, clocked at 1 MHz. What's the average of 3Gbps and 1 MHz? I suppose big, cutting-edge multi-FPGA designs usually run "as fast as possible", while small, single-FPGA designs might run at all sorts of clock rates. Sometimes faster is not any better, especially in human- oriented control. BTW, don't assume that our Marketing folks keep exact records of our customers' clock frequencies. But they usually get an earful when the part isn't fast enough... Peter Alfke On Feb 13, 1:34 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Gabor wrote: > > On Feb 13, 2:08 pm, Jim Granville <no.s...@designtools.maps.co.nz> > >>I've got a candidate for absurdly low :) > > >>We have a CPLD design for a Clock(time variety) that starts > >>at 32.768KHz, but we divide that a little before the CPLD uses it, > >>so 1024Hz is the CPLD clock. > >>The corner frequency (where the uA/Mhz adds 10% to the Static icc of > >>2.4uA) on this CPLD is around 10KHz, so I propose a more general rule : > > >>" Any frequency that barely moves the meter above Static Icc, > >>qualifies as Absurdly low." > > >>Of course, on some FPGAs, that will be rather high.... ;) > > >>-jg > > > You didn't mention the CPLD used, > > Atmel ATF1504BE / ATF1502BE > > > but I'm guessing that there are > > a number of reasons in addition to the maximum achievable clock > > rate that go into selection of an FPGA for a design. For the > > lowest cost per I/O parts, for example, I wouldn't be surprised > > if there were a number of absurdly slow designs running into > > significant volumes. I'm guessing the CPLD in this case was > > chosen for minimal power consumption. > > Yes, and for low IO pin cost. > > > At 1024 Hz. there are > > a number of microcontrollers that would do the job of a clock > > quite nicely. > > yes, but at 100 pins, they are more expensive than the cpld, > ( as well as being considerably over-resourced !) > and this is also partly a teaching example for CPLDs.... > > Finding a regulator that did not impact the Icc was > quite a challenge ... > > -jgArticle: 115566
On Feb 13, 12:41 pm, Magne Munkejord <Magne.Munkej...@student.uib.no> wrote: > Gabor wrote: > > On Feb 12, 12:58 pm, Magne Munkejord <Magne.Munkej...@student.uib.no> > > wrote: > >> Thanks for your reply! > > >> Sean Durkin wrote: > >>> Magne Munkejord wrote: > >>>> Hello, > >>>> I have a design with several LVDS transceivers. The design works well > >>>> when all ports are connected but once some ports are unconnected I start > >>>> receiving garbage from the floating inputs. > >>> Well, what do you expect them to give you? If they are not connected, > >>> and neither pulled to ground nor to VCC, you get something in between, > >>> and that depends on the temperature, humidity, moon phase, your karma, > >>> whatever... That's why it's called "floating", because the input floats > >>> somewhere in between. Most of the time somewhere around the middle > >>> exactly where the decision threshold between 0 and 1 is, so sometimes > >>> you get 0, other times you get 1, which translates to garbage. > >>> As the warning states, if you do attach PULLUP or PULLDOWN primitives, > >>> this might affect signal integrity. You might be OK with that, or it > >>> might screw up your data, that's for you to decide. As you know, the > >>> differential termination won't resolve the issue with the floating > >>> inputs. So, pullups/-downs might be a solution, but only if it doesn't > >>> affect signal integrity too much, which it seems to do in yout case > >>> (since you still get garbage sometimes despite of the pullups). > >> Sorry, inaccurate information from my part. When I leave all ports > >> unconnected (no cables attached) 1 out of 8 channels still receives > >> garbage. When I connect cables from one port to another > >> data-transmission seems to be in order (2 of to 2 words received, 100% > >> signal integrity :) I need more statistics on this). > > >>>> If anyone have any suggestions on how to handle unconnected ports please > >>>> let me know. > >>> Yes, ignore everything you get from floating inputs. > >> Easier said then done. The final design will have 120 serial channels. > >> Received data words from each channel will be stored in a shared memory > >> so I need to filter out the garbage words before I store them. > > >>> HTH, > >>> Sean > >> I am well aware of the problem that a floating input acts like an > >> antenna. (At least I am now :) Since pullups and pulldowns are not an > >> ideal solution, I was hoping there might be a way to detect an > >> unconnected port/input and disable this channel. > >> I see that in my original post, I left out some vital information; The > >> lvds lines are used for serial data transmission over cat5 TP cables. > >> Non-Return-to-Zero encoding with 4 cycles per bit, 32 bit words, 2 start > >> bits, one parity bit and one stop bit. When the lines are idle the > >> transmitters should hold the lines high (when looking at the > >> single-ended signals from my IBUFDS/OBUFDS). > >> The situation now is that, if by chance, a floating input stays low for > >> 4 cycles and high for the 4 next, I start sampling for data bits. Of > >> course I can discard words with stop bit error and/or parity errors but > >> this method is not bullet-proof. > >> Maybe I should try to make a more demanding/critical start condition? I > >> will try to experiment a bit or two. > >> As you say, these are design considerations I will have to make myself. > >> I was thinking that this might be a common problem with a good solution > >> but I can't find any discussions/articles about it on the Xilinx > >> website. Thats why I made this thread. If anyone have some experience to > >> share with me I'd be grateful. > > > It may be possible to fix this inside the FPGA if you can add a pullup > > to the positive input and a pulldown to the negative input of each > > pair. > > Even then, I wouldn't count on this arrangement working well due to > > the > > relatively low value of the differential termination resistor and the > > resulting very low voltage created by the weak pullup/pulldown pair > > (assuming the P&R tools really place these components). > > > Another approach is to add external pullup/pulldown resistors to bias > > the > > signals when disconnected (also not optimal). There are LVDS receiver > > devices that have guaranteed outputs when the inputs are floating. > > They > > do this by sensing that the common mode input voltage is above the > > high limit (there is an internal pullup to create this CM voltage when > > the inputs float). The FPGA could do this with an additional I/O > > attached to one of the LVDS pair, but if you're trying to run too > > fast you'll have issues with the unbalanced capacitive loading. > > > So probably the best way to avoid this mess is to use a protocol with > > guaranteed AC and DC characteristics like 8B-10B. You can then > > easily detect error conditions and disable the disconnected links. > > > Regards, > > Gabor > > Thanks Gabor. > I've looked into the 8B-10B encoding that you suggested. It is not > likely I will have time to implement this but I would like to say > something about it in my master thesis. > You say that it is easy to detect error conditions and I have tried to > figure out how this can be done. When you mention AC and DC > characteristics I assume you are thinking of that each encoded 10-bit > word would contain 5 zeroes and 5 ones. So if I count the number of ones > and zeroes over an interval and see a signicant difference in numbers > then this would indicate a floating input? Or should I simply look for > invalid 10-bit words? Words that would not be part of the alphabet for > this encoding scheme. > Can you please let me know if I got this right? Valid words have no more than 6 1's or 0's. That is DC is maintained +/- 1 count. In addition, any word that is not 5 1's and 5 0's has two versions, one with 6 1's, the other with 6 0's. Thus any long- term DC unbalance is avoided by using the appropriate version of the word to prevent the DC component from going more negative or positive than +/- 1. This is something you can check for validity. AC component of the input signal is also maintained. Other than the escape codes, you should never get more than 4 1's or 0's in a row. Thus if your inputs oscillate much slower than your bit rate, you can detect code errors by counting adjacent 1's or 0's. Invalid 10-bit words is an easy starting point. Typically you'd use a state machine that detects lock when it receives a particular code, usually K28.5 if memory serves me correctly. Then you might allow 1 or 2 bad codes before deciding you've lost lock and wait for the next escape character. You never mentioned your bit rate. If you're not running too fast you may have other options, like detecting non- integral bit periods, etc. If you're running as fast as the I/O can go, you get another benefit from the 8b-10b code of carrying the clock information on your data pair. However clock recovery in an FPGA is not easy if you need to use fabric resources rather than built-in SERDES I/O blocks.Article: 115567
I am about to buy the ML403 eval board because I need something to run Linux on, but does anyone know of a similar board that has PCI or mini PCI support?Article: 115568
On Feb 13, 1:34 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Yes, and for low IO pin cost. > > > At 1024 Hz. there are > > a number of microcontrollers that would do the job of a clock > > quite nicely. > > yes, but at 100 pins, they are more expensive than the cpld, > ( as well as being considerably over-resourced !) > and this is also partly a teaching example for CPLDs.... > > Finding a regulator that did not impact the Icc was > quite a challenge ... FYI: I did a low power design, simple enough to fit in a low power CPLD (xc2c64a). In my case the number of I/O was not important. To implement my system I had to add 2 ext comparators (one to generate clock - 150KHz, one to detect the input) and one LDO because the supply was not regulated. I did the same design using MCUs (TI and Mirochip): I had to clock them 4x or 6x faster to do same job. Guess what: the lowest power was required by the design w/ CPLD. Unfortunately it's prohibitive because of the price and [package] size (again, in my case I'd needed one input and one output). I wish they would make low cost CPLD in small packages, about the size of xc2c128, w/ LDO and 1-4 comparators on die. Also I've found the POR circuitry of this device (xc2c64a) rock solid. I was very impressed with its performance. -- mmihaiArticle: 115569
mmihai wrote: > On Feb 13, 1:34 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > > >>Yes, and for low IO pin cost. >> >> >>>At 1024 Hz. there are >>>a number of microcontrollers that would do the job of a clock >>>quite nicely. >> >>yes, but at 100 pins, they are more expensive than the cpld, >>( as well as being considerably over-resourced !) >>and this is also partly a teaching example for CPLDs.... >> >>Finding a regulator that did not impact the Icc was >>quite a challenge ... > > > FYI: > > I did a low power design, simple enough to fit in a low power CPLD > (xc2c64a). In my case the number of I/O was not important. > > To implement my system I had to add 2 ext comparators (one to generate > clock - 150KHz, one to detect the input) and one LDO because the > supply was not regulated. > > I did the same design using MCUs (TI and Mirochip): I had to clock > them 4x or 6x faster to do same job. > > Guess what: the lowest power was required by the design w/ CPLD. > Unfortunately it's prohibitive because of the price and [package] size > (again, in my case I'd needed one input and one output). > I wish they would make low cost CPLD in small packages, about the size > of xc2c128, w/ LDO and 1-4 comparators on die. > > Also I've found the POR circuitry of this device (xc2c64a) rock solid. > I was very impressed with its performance. Interesting - so what did you finally go into production with ? -jgArticle: 115570
Andreas Ehliar wrote: > Hi, I've been wondering for a while if there is any data about > typical clock frequencies of FPGA designs for various FPGA > devices. The latest of our tiny logic analyzers samples at 1GHz, using a Spartan_3. Not too much of the logic runs at 1ns between edges ;-) We managed 500MHz with a Spartan_2. The web page is www.rockylogic.com if you want to come round and throw a brick through the window. -- TimArticle: 115571
Hi All,
I reviewed LocalLink and Aurora protocol and it does not specifically say
anything about RocketIO tranceivers. So I assumed that it could be
implemented by using LVDS pins when higher speeds are not necessary. But its
IP just works with RocketIO.
- I am wondering if it's possible to implement it with diferrential
pins other than RocketIO?
- Does anybody know another protocol and interface implementable with
LVDS, with capabilities comparable to Aurora?
Thanks
Massoud
Article: 115572I have an IP core than needs to eventually transfer data such that MicroBlaze (and maybe eventually PowerPC) has access to it. The data will be pushed out of the IP in bytes. It is possible that only 2 bytes are output for a given 'frame' of data. It is important that these 2 bytes get processed. More data may not come in until much later in time...relatively. Other cases will push more bytes per frame. One option would be to place an asynchronous FIFO in the data path. The bytes would get stored in that FIFO using the IP's clock. The read port would be connected to an OPB IPIF FIFO. The OPB FIFO would store the data from the asynchronous FIFO using some yet to be determined logic. Then the OPB could request data through the IPIF interface. We've thought about using the FSL but that option is not available (as far as I know) on the PowerPC. The problem with using the IPIF FIFO directly is that it is synchronous to the OPB clock. The IP is on a different clock. Any suggestions as to a better way to do this? Thanks!Article: 115573
Hi Motty, motty wrote: > We've thought about using the FSL but that option is not available (as > far as I know) on the PowerPC. The problem with using the IPIF FIFO > directly is that it is synchronous to the OPB clock. The IP is on a > different clock. In V4FX (and presumably V5FX?) the PPC has an APU (Aux processing unit) interface, which can bridge across to something called FCB (fabric coprocessor bus) via the fcb_v1_00_a. Thence you can bridge to FSL with the fcb2fsl_bridge core. I've seen a marketing slide showing this arrangement, but alas no XAPP that I can find. These cores all live in the usual spot in an EDK installation ($EDK/hw/XilinxProcessorLib/pcores/...) Quite an endorsement of FSL by Xilinx, if you think about it. Regards, JohnArticle: 115574
"Gabor" <gabor@alacron.com> wrote: >I'm guessing the CPLD in this case was >chosen for minimal power consumption. At 1024 Hz. there are >a number of microcontrollers that would do the job of a clock >quite nicely. I have a CPLD design with an input clock 153.6kHz (16 x 9600) and most of the design is running at 75Hz. The CPLD was chosen to be big enough to fit the design and a CPLD was chosen over a microcontroller because microcontrollers need 'software' and in some organisations the amount of crap you have to go through to use any kind of 'software' in a design makes a programmable logic solution attractive. --
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