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
On Mar 28, 4:31=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 27, 10:34 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > > > > > > > On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnu...@gmail.com> > > wrote: > > > >On Mar 27, 1:25 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > > > >> Also sometimes called a "delay-locked loop". > > > >I am pretty sure that this is not a delay locked loop. =A0A DLL uses a > > >delay in the feedback path to generate an output that has a different > > >phase than the original. =A0This is often used to compensate for a del= ay > > >elsewhere in the clock path. > > > >In one incarnation of the design of this circuit the error integrator > > >was enabled by the input clock enable. =A0If there was a phase shift i= n > > >the input and output clock enables, it would produce a single count of > > >difference during part of the cycle, but would be zero again by the > > >next input clock enable. =A0However, with the phase accumulator (DCO) > > >operating on each cycle of the main clock, this single count would be > > >added in producing what amounted to a fractional phase step compared > > >to the value in the error integrator. =A0The result is that the smalle= st > > >adjustments in output frequency would be made by the phasing of the > > >input and output signals. =A0However, the phase would never be correct= ed > > >in the error integrator. > > > >This is a bit hard to describe in words. =A0I hope it is clear. > > > >Rick > > > That's also a DLL, and perhaps the more commonly-used meaning of the > > term in my experience. > > Yeah, I guess people use whatever term they want often and that makes > it hard to communicate about these things. =A0I am pretty sure that the > "correct" definition of a Delay Locked Loop is as I described above. > But if there is no "official" group to decide these things, there > really is no correct definition. > > > This FIFO thing is also pretty common but doesn't seem to have a > > universal name. =A0 As John mentioned, they've been referred to as RLLs= , > > "Elastic buffer", and I've heard DLL when the purpose was to match the > > delay to some other output to which the stream needs to be > > synchronized. =A0In the satellite world there's also "plesiochronous > > buffer" (one of my fave names for this). > > In my case the use is two fold. =A0I am receiving a bit stream and I > need to interleave other data with it at a odd ratio (31:1, 15:1, > etc). =A0The interleave ratio also determines a delay in the other bit > stream which must be compensated for in the first bit stream with a > fixed quantity delay. =A0Then as the first bit stream speeds or slows, > the second bit stream clock rate is adjusted to match. =A0The second bit > rate is just a simple ratio to the first, so that would not require a > PLL. =A0But the output stream is now 32/31 times the bit rate of the > first input. =A0This is what the PLL is for. > > At the other end a similar circuit de-interleaves the two bit streams > and a PLL generates the output clock. =A0A similar FIFO adds a delay at > this end and the FIFO data count is again used as the phase > detector. > > > I guess since the jobs that it does can different a universal name is > > impractical. > > I would like to think that the name would be based on how the circuit > works, not so much on what it is used for. =A0A FIFO is always called a > FIFO (or a queue) regardless of how it is being used. =A0Oh, well. =A0The > main thing is to get it to work. > > Rick- Hide quoted text - > > - Show quoted text - One drawback of the "buffer-half-full" control loop is that the jitter present on the DCO depends on how "bursty" the input data is. An alternative approach which is used in sending data over bursty channels link Ethernet is the concept of a "time stamp". Assume that evey so often (8 samples or so) you interleave a time stamp with the data. The time stamp is simply a counter running from the local clock that has enough bits that it never wraps around. So you take this stream and put it through some bursty channel which is potentially interleaved with other streams that compete for bandwidth. Assume you have some mechanism on the remote node for deriving a copy of the "global time", so there is a counter which is synced pretty closely with the source counter. So you put your data into a buffer as before, but now whenever you clock out a data sample that has an associated time stamp, you compare the time stamp with the local time, and you adjust your DCO based on this difference. So how is this different than the "buffer-half-full" scheme? The difference is that the jitter of the dco, in the case where your data is very bursty, is independant of the burstiness. You still need a buffer large enough to handle the burstiness, but you end up only making very small changes to the dco in order to make it track. There are many networking standards that take this approach, for example you can google "Ethernet AVB". Bob AdamsArticle: 139401
My VHDL is somwhat rusty.... What's the correct syntax to alias a bunch of signals into a vector - the code below shows what I'm trying to do, but ISE doesn't like the '&'.... Port declaration : FX2_IO:in std_logic_vector(1 to 40); Signal declaration : alias dvi_red: std_logic_vector(7 downto 0) is FX2_IO(18) & FX2_IO(24) & FX2_IO(30) & FX2_IO(36) & FX2_IO(19) & FX2_IO(25) & FX2_IO(35) & FX2_IO(37);Article: 139402
For educational purposes I want to implement a function that has a high number of inputs. Since such a function would end up anyway only as a component of a larger design I do not care for pin limitations of a given chip. But the entire design does not exist. So currently I try to use the INCREMENTAL_SYNTHESIS attribute. Now I get the warning that this is deprecated, and I should use partitions instead. As far as I have understood XAPP918 I have to have the entire design to be able to define my particular function as partition. Of course I could build a dummy-top design which uses a shift register or something like that to provide the input pins. There has to be a way to build a core with ISE, not? AndreasArticle: 139403
rickman schrieb: > On Mar 27, 6:55 pm, thomas.sch...@hotmail.fr wrote: >> Does anyone know where I could find a xc6200 fpga? I would like to >> experiment things on reconfigurable computing and it seems to be the >> only fpga with a complete documentation to be fully dynamically >> reconfigurable. > > These chips were only available for a short while. I don't really > know why Xilinx produced them and then not only stopped, but seems to > have killed them off entirely. > > I seem to recall that there were projects around to allow you to do > any manipulation of the bit stream you wish through a JAVA interface. > Not the same as open source tools, but it was supposed to make the > same functionality available. > > Rick Xilinx inherited them when they bought Algotronix. I think the main reason for that takeover where some patents xilinx needed (or maybe did not want to get into the hands of a competitor). Xilinx kept the devices for some time in the market, in particular to get the favor of academia where they were quite popular. But since commercial customes never really went for them they eventually died. AndreasArticle: 139404
On Mar 28, 8:41=A0am, Robert Adams <robert.ad...@analog.com> wrote: > On Mar 28, 4:31=A0am, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 27, 10:34 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > > > > On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnu...@gmail.com> > > > wrote: > > > > >On Mar 27, 1:25 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > > > > >> Also sometimes called a "delay-locked loop". > > > > >I am pretty sure that this is not a delay locked loop. =A0A DLL uses= a > > > >delay in the feedback path to generate an output that has a differen= t > > > >phase than the original. =A0This is often used to compensate for a d= elay > > > >elsewhere in the clock path. > > > > >In one incarnation of the design of this circuit the error integrato= r > > > >was enabled by the input clock enable. =A0If there was a phase shift= in > > > >the input and output clock enables, it would produce a single count = of > > > >difference during part of the cycle, but would be zero again by the > > > >next input clock enable. =A0However, with the phase accumulator (DCO= ) > > > >operating on each cycle of the main clock, this single count would b= e > > > >added in producing what amounted to a fractional phase step compared > > > >to the value in the error integrator. =A0The result is that the smal= lest > > > >adjustments in output frequency would be made by the phasing of the > > > >input and output signals. =A0However, the phase would never be corre= cted > > > >in the error integrator. > > > > >This is a bit hard to describe in words. =A0I hope it is clear. > > > > >Rick > > > > That's also a DLL, and perhaps the more commonly-used meaning of the > > > term in my experience. > > > Yeah, I guess people use whatever term they want often and that makes > > it hard to communicate about these things. =A0I am pretty sure that the > > "correct" definition of a Delay Locked Loop is as I described above. > > But if there is no "official" group to decide these things, there > > really is no correct definition. > > > > This FIFO thing is also pretty common but doesn't seem to have a > > > universal name. =A0 As John mentioned, they've been referred to as RL= Ls, > > > "Elastic buffer", and I've heard DLL when the purpose was to match th= e > > > delay to some other output to which the stream needs to be > > > synchronized. =A0In the satellite world there's also "plesiochronous > > > buffer" (one of my fave names for this). > > > In my case the use is two fold. =A0I am receiving a bit stream and I > > need to interleave other data with it at a odd ratio (31:1, 15:1, > > etc). =A0The interleave ratio also determines a delay in the other bit > > stream which must be compensated for in the first bit stream with a > > fixed quantity delay. =A0Then as the first bit stream speeds or slows, > > the second bit stream clock rate is adjusted to match. =A0The second bi= t > > rate is just a simple ratio to the first, so that would not require a > > PLL. =A0But the output stream is now 32/31 times the bit rate of the > > first input. =A0This is what the PLL is for. > > > At the other end a similar circuit de-interleaves the two bit streams > > and a PLL generates the output clock. =A0A similar FIFO adds a delay at > > this end and the FIFO data count is again used as the phase > > detector. > > > > I guess since the jobs that it does can different a universal name is > > > impractical. > > > I would like to think that the name would be based on how the circuit > > works, not so much on what it is used for. =A0A FIFO is always called a > > FIFO (or a queue) regardless of how it is being used. =A0Oh, well. =A0T= he > > main thing is to get it to work. > > > Rick- Hide quoted text - > > > - Show quoted text - > > One drawback of the "buffer-half-full" control loop is that the jitter > present on the DCO depends on how "bursty" the input data is. > > An alternative approach which is used in sending data over bursty > channels link Ethernet is the concept of a "time stamp". Assume that > evey so often (8 samples or so) you interleave a time stamp with the > data. The time stamp is simply a counter running from the local clock > that has enough bits that it never wraps around. > > So you take this stream and put it through some bursty channel which > is potentially interleaved with other streams that compete for > bandwidth. Assume you have some mechanism on the remote node for > deriving a copy of the "global time", so there is a counter which is > synced pretty closely with the source counter. > > So you put your data into a buffer as before, but now whenever you > clock out a data sample that has an associated time stamp, you compare > the time stamp with the local time, and you adjust your DCO based on > this difference. > > So how is this different than the "buffer-half-full" scheme? The > difference is that the jitter of the dco, in the case where your data > is very bursty, is independant of the burstiness. You still need a > buffer large enough to handle the burstiness, but you end up only > making very small changes to the dco in order to make it track. > > There are many networking standards that take this approach, for > example you can google "Ethernet AVB". > > Bob Adams Isn't this what the low pass filter helps with? Even if the packets arrive at very random times, the LPF will smooth the control "voltage" to the DCO. In my case I don't expect a lot of jitter from the input signal. On the other end, I am not handling the packet interface. My customer's equipment is doing that. I am supplied with data and clock. I just have to separate the two data streams and reclock the output with the fixed delay line. In another approach, I have to provide a fixed time delay independent of the data rate. In that case the error integrator is removed and the buffer length directly controls the DCO rate. I expect that will not have stability issues. RickArticle: 139405
On Mar 28, 12:02=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > My VHDL is somwhat rusty.... > What's the correct syntax to alias a bunch of signals into a vector - the= code below shows what I'm > trying to do, but ISE doesn't like the '&'.... > > Port declaration : > FX2_IO:in std_logic_vector(1 to 40); > > Signal declaration : > > alias dvi_red: std_logic_vector(7 downto 0) is =A0FX2_IO(18) & FX2_IO(24)= & FX2_IO(30) & FX2_IO(36) & > FX2_IO(19) & FX2_IO(25) & FX2_IO(35) & FX2_IO(37); I looked and I don't see where this is supported within the standard. However, the standard is a bit obtuse in this area and I can't say I understand it well. That said, it seems that at earlier times at least, the use of alias was not well supported. I can't say it is widely supported for synthesis now, so maybe it is best to be avoided. dvi_red <=3D (FX2_IO(18) & FX2_IO(24) & FX2_IO(30) & FX2_IO(36) & FX2_IO (19) & FX2_IO(25) & FX2_IO(35) & FX2_IO(37)); How about this instead? RickArticle: 139406
Hi All, I have a design that fails on XST synthesis with the message "synthesis failed see design summary for more information" (on ISE10.1 lin64). However, the design summary does not contain any information on the failure. No warning nothing. I am able to synthesize all sub- modules successfully. The top level module does not contain any logic only submodules instances. There is absolutely no clue in the .syr file. Synthesis fails at the beginning of the "Advanced HDL Synthesis" step. Synplify Pro has no problem synthesizing the entire design. Trying to synthesize the design from the command line results in segmentation fault again after the beginning of the "Advance HDL Synthesis" step. Thanks for any hint.Article: 139407
Mike Harrison wrote:
> My VHDL is somwhat rusty....
> What's the correct syntax to alias a bunch of signals into a vector - the code below shows what I'm
> trying to do, but ISE doesn't like the '&'....
>
> Port declaration :
> FX2_IO:in std_logic_vector(1 to 40);
>
> Signal declaration :
That would be
signal dvi_red : std_logic_vector(7 downto 0);
before the architecture BEGIN.
If the right side expression is used only once,
I would make a simple assignment as rickman demonstrated.
If I wanted to attach a name to the *expression* for reuse,
I would use a function rather than an alias.
-- Mike Treseler
Article: 139408On Sat, 28 Mar 2009 10:17:55 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >On Mar 28, 8:41 am, Robert Adams <robert.ad...@analog.com> wrote: >> On Mar 28, 4:31 am, rickman <gnu...@gmail.com> wrote: >> >> >> >> > On Mar 27, 10:34 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: >> >> > > On Fri, 27 Mar 2009 16:03:09 -0700 (PDT), rickman <gnu...@gmail.com> >> > > wrote: >> >> > > >On Mar 27, 1:25 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: >> >> > > >> Also sometimes called a "delay-locked loop". >> >> > > >I am pretty sure that this is not a delay locked loop. A DLL uses a >> > > >delay in the feedback path to generate an output that has a different >> > > >phase than the original. This is often used to compensate for a delay >> > > >elsewhere in the clock path. >> >> > > >In one incarnation of the design of this circuit the error integrator >> > > >was enabled by the input clock enable. If there was a phase shift in >> > > >the input and output clock enables, it would produce a single count of >> > > >difference during part of the cycle, but would be zero again by the >> > > >next input clock enable. However, with the phase accumulator (DCO) >> > > >operating on each cycle of the main clock, this single count would be >> > > >added in producing what amounted to a fractional phase step compared >> > > >to the value in the error integrator. The result is that the smallest >> > > >adjustments in output frequency would be made by the phasing of the >> > > >input and output signals. However, the phase would never be corrected >> > > >in the error integrator. >> >> > > >This is a bit hard to describe in words. I hope it is clear. >> >> > > >Rick >> >> > > That's also a DLL, and perhaps the more commonly-used meaning of the >> > > term in my experience. >> >> > Yeah, I guess people use whatever term they want often and that makes >> > it hard to communicate about these things. I am pretty sure that the >> > "correct" definition of a Delay Locked Loop is as I described above. >> > But if there is no "official" group to decide these things, there >> > really is no correct definition. >> >> > > This FIFO thing is also pretty common but doesn't seem to have a >> > > universal name. As John mentioned, they've been referred to as RLLs, >> > > "Elastic buffer", and I've heard DLL when the purpose was to match the >> > > delay to some other output to which the stream needs to be >> > > synchronized. In the satellite world there's also "plesiochronous >> > > buffer" (one of my fave names for this). >> >> > In my case the use is two fold. I am receiving a bit stream and I >> > need to interleave other data with it at a odd ratio (31:1, 15:1, >> > etc). The interleave ratio also determines a delay in the other bit >> > stream which must be compensated for in the first bit stream with a >> > fixed quantity delay. Then as the first bit stream speeds or slows, >> > the second bit stream clock rate is adjusted to match. The second bit >> > rate is just a simple ratio to the first, so that would not require a >> > PLL. But the output stream is now 32/31 times the bit rate of the >> > first input. This is what the PLL is for. >> >> > At the other end a similar circuit de-interleaves the two bit streams >> > and a PLL generates the output clock. A similar FIFO adds a delay at >> > this end and the FIFO data count is again used as the phase >> > detector. >> >> > > I guess since the jobs that it does can different a universal name is >> > > impractical. >> >> > I would like to think that the name would be based on how the circuit >> > works, not so much on what it is used for. A FIFO is always called a >> > FIFO (or a queue) regardless of how it is being used. Oh, well. The >> > main thing is to get it to work. >> >> > Rick- Hide quoted text - >> >> > - Show quoted text - >> >> One drawback of the "buffer-half-full" control loop is that the jitter >> present on the DCO depends on how "bursty" the input data is. >> >> An alternative approach which is used in sending data over bursty >> channels link Ethernet is the concept of a "time stamp". Assume that >> evey so often (8 samples or so) you interleave a time stamp with the >> data. The time stamp is simply a counter running from the local clock >> that has enough bits that it never wraps around. >> >> So you take this stream and put it through some bursty channel which >> is potentially interleaved with other streams that compete for >> bandwidth. Assume you have some mechanism on the remote node for >> deriving a copy of the "global time", so there is a counter which is >> synced pretty closely with the source counter. >> >> So you put your data into a buffer as before, but now whenever you >> clock out a data sample that has an associated time stamp, you compare >> the time stamp with the local time, and you adjust your DCO based on >> this difference. >> >> So how is this different than the "buffer-half-full" scheme? The >> difference is that the jitter of the dco, in the case where your data >> is very bursty, is independant of the burstiness. You still need a >> buffer large enough to handle the burstiness, but you end up only >> making very small changes to the dco in order to make it track. >> >> There are many networking standards that take this approach, for >> example you can google "Ethernet AVB". >> >> Bob Adams > >Isn't this what the low pass filter helps with? Even if the packets >arrive at very random times, the LPF will smooth the control "voltage" >to the DCO. In my case I don't expect a lot of jitter from the input >signal. On the other end, I am not handling the packet interface. My >customer's equipment is doing that. I am supplied with data and >clock. I just have to separate the two data streams and reclock the >output with the fixed delay line. > >In another approach, I have to provide a fixed time delay independent >of the data rate. In that case the error integrator is removed and >the buffer length directly controls the DCO rate. I expect that will >not have stability issues. > >Rick FWIW, this sounds a lot like a typical demultiplexing problem where a multiplexed stream has to be broken back out into the constituent signals. The sub-channels are often at different average rates, and depending on how the multiplexing scheme worked the subchannels may fill their indvidual buffers in a pretty bursty fashion. Some standardized interfaces (well, many, actually) want the data to come back out at a very stable rate. In some cases it needs to come out at a ridiculously stable rate, and when the FIFO is filling in bursts it can turn into a tricky problem. I think you're on the right track, though. We've done this quite a few times with a similar approach, but it seems like there's always some pitfall that's specific to the application. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.phpArticle: 139409
On Mar 28, 9:08=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 27, 9:16=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > For some time I've found it pretty humorous that Xilinx boast of "True > > LUT6" in all their Virtex 5+ marketing material. Do they really think > > that they can somehow imply that Altera's ALM isn't a "True LUT6" when > > in fact it's obvious that the ALM encompasses a LUT6 and much more. > > > Or are there some unreal LUT6 out there? > > I don't know what they are referring to by that. =A0I Lattice provides a > dual LUT6 or a single LUT7 in their equivalent to the CLB. =A0I think > they do that by combining LUT4 outputs with dedicated muxes. =A0Heck, > that's "real" enough for me. =A0I wonder what the advantage of a "real" > LUT6 is? =A0:^) > > Rick Maybe it's in the logic coverage, and the background resource that implies ? - and what you can then do with that resource. This sounded like a reasonable advance ? G=F6ran Bilski did make this comment : [" With Xilinx 6-LUT, you can really make small 16-bit RISC machines which is register file based. Programming a register based CPU in assembler is much easier than a stack machine. I crafted a couple of years ago a 16-bit machine which could be as small as 200 LUTs (4-LUT) but was around 300 LUTs in general. It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT)."] and also this ["RAM32M primitives .... this primitive helped to reduce the register file size with around 7x. It handles 1 write and 3 read ports very efficient."] Antti: [ cool, 4 LUTs are used for 4 port 32 x 2 RAM with async read ports!! ]Article: 139410
John Larkin wrote: > On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk> > wrote: > >> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >> news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... >>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >>> <pabloalvarezsanchez@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> For several reasons a need very low jitter on some of my outputs. I >>>> was thinking of using LVDS for my I/Os and of course I do not consider >>>> using a clock manager. Do you have an idea of the order of magnitude >>>> of jitter one can get? What fpga would you recomend for a low cost >>>> small design? >>>> >>>> Cheers >>>> >>>> Pablo >>> >>> Here's a signal that has made three independent non-trivial in/out >>> passes through a Spartan3, plus passed through six external SSI CMOS >>> chips. Total jitter of that whole chain is below 20 ps RMS. >>> >>> ftp://jjlarkin.lmi.net/Jitter3.jpg >>> >>> >>> We were fairly impressed. Spartans are like having a few thousand 10KH >>> ECL gates on a $20 chip. >>> >>> John >>> >> I've just built a fractional-N synthesizer using a Spartan 3. The reference >> frequency comes from an LVDS-output crystal oscillator. The VCO frequency >> is fed into the opposite side of the FPGA using an LVDS-output comparator >> and the (AD9901 style) PFD output from the FPGA to the loop filter is also >> LVDS on a third physical side. >> >> Inside the FPGA, the VCO divider and reference divider are on local clocks >> confined to small regions around the pads where they enter. BUFGCE >> primitives are used to gate the clocks so I only send edges over the global >> clock network when a divider resets. The AD9901 PFD ensures that the VCO >> and reference divider outputs are 180 degrees out of phase. >> >> Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 >> CPLD. It worked quite well, but there was some interation between the VCO >> and reference frequencies which caused integer-N boundary spurs. I see no >> trace of these spurs on my new Spartan 3 design, and the phase noise is much >> lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I >> haven't finished tweaking things yet. >> >> >> They say don't attempt analogue functions in FPGAs; but it seems to work >> remarkably well in the Spartan 3, which is fully static when I'm not >> clocking it. >> >> > > The Spartan LVDS inputs are pretty good r-r comparators. And you can > make lots of good, cheap delta-sigma dacs from an FPGA. > > You can do cool analog things with FPGAs. ... Can you tell us more about that? Sounds very interesting. As long as it doesn't rely on really undocumented parameters like leakage currents, or goes away when the family gets discontinued (one reason I don't like FPGA much). > ... You can also get into a heap of trouble. > Probably of the exothermic kind where the smoke alarms kick in and the sprinkler system comes on :-) -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 139411
On Mar 28, 3:59=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > On Mar 28, 9:08=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 27, 9:16=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > > For some time I've found it pretty humorous that Xilinx boast of "Tru= e > > > LUT6" in all their Virtex 5+ marketing material. Do they really think > > > that they can somehow imply that Altera's ALM isn't a "True LUT6" whe= n > > > in fact it's obvious that the ALM encompasses a LUT6 and much more. > > > > Or are there some unreal LUT6 out there? > > > I don't know what they are referring to by that. =A0I Lattice provides = a > > dual LUT6 or a single LUT7 in their equivalent to the CLB. =A0I think > > they do that by combining LUT4 outputs with dedicated muxes. =A0Heck, > > that's "real" enough for me. =A0I wonder what the advantage of a "real" > > LUT6 is? =A0:^) > > > Rick > > Maybe it's in the logic coverage, and the background resource that > implies ? > - and what you can then do with that resource. > This sounded like a reasonable advance ? If you mean the coverage of possible functions of the 6 inputs, a mux gives total coverage. That's all the LUTx is, a set of FFs with the outputs selected by a mux. The "real" LUTs use particular combinations of of pass transistors or transmission gates to implement the muxes. I can't say how the "extra" muxs (that connect the LUT4 outputs) are made. One advantage of the separate LUT4 connected by 2 input MUXes is that you can implement a large number of functions of up to 16 inputs, possibly as many as 19 inputs. But this depends on the available routing. The advantage of combining 8 LUTs and FFs in a single CLB/ PFU is that you can save a bit on routing by not providing 8 x N inputs from the routing matrix as you would for LUTs in separate CLBs. > G=F6ran Bilski =A0did make this comment : > [" With Xilinx 6-LUT, you can really make small 16-bit RISC machines > which is register file based. > Programming a register based CPU in assembler is much easier than a > stack machine. > I crafted a couple of years ago a 16-bit machine which could be as > small as 200 LUTs (4-LUT) but was around 300 LUTs in general. > It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT)."] > > and also this > ["RAM32M primitives .... this primitive > =A0helped to reduce the register file size with around 7x. > =A0It handles 1 write and 3 read ports very efficient."] > Antti: [ cool, 4 LUTs are used for 4 port 32 x 2 RAM with async read > ports!! ] I'm not sure you can compare apples (LUT4) and oranges (LUT6) this way. You can create a 32 x 1 ram using two LUT4s and an "extra" mux (in CLB/PFU, not LUT). To get 4 port x 32 x 1 bit requires 8 LUT4s. To get N bits requires 8 x N LUT4s or 16 in this case which is 4x the number of LUT6s used. However, how do you compare the "cost" of a LUT6 vs a LUT4? There are 4 times as many FFs and muxes in the LUT itself. There are fewer inputs, so less routing required. There are a lot fewer LUT6 elements in a given price/size FPGA than a LUT4 equivalent, but how many fewer? The trade off is how often the LUT6 is wasted on logic with fewer than 6 inputs vs. how often it allows reduced routing resources to fully connect your design. I expect the size/cost of the LUT6 is 4x the LUT4 in respects other than routing. I would guess that they picked the LUT6 rather than a LUT5 because it allows a 4:1 mux with no wasted inputs. Muxes are real LUT eaters in many designs, including CPUs. RickArticle: 139412
On Mar 28, 3:08 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote: > On Sat, 28 Mar 2009 10:17:55 -0700 (PDT), rickman <gnu...@gmail.com> > wrote: > > >On Mar 28, 8:41 am, Robert Adams <robert.ad...@analog.com> wrote: > >> One drawback of the "buffer-half-full" control loop is that the jitter > >> present on the DCO depends on how "bursty" the input data is. > > >> An alternative approach which is used in sending data over bursty > >> channels link Ethernet is the concept of a "time stamp". Assume that > >> evey so often (8 samples or so) you interleave a time stamp with the > >> data. The time stamp is simply a counter running from the local clock > >> that has enough bits that it never wraps around. > > >> So you take this stream and put it through some bursty channel which > >> is potentially interleaved with other streams that compete for > >> bandwidth. Assume you have some mechanism on the remote node for > >> deriving a copy of the "global time", so there is a counter which is > >> synced pretty closely with the source counter. > > >> So you put your data into a buffer as before, but now whenever you > >> clock out a data sample that has an associated time stamp, you compare > >> the time stamp with the local time, and you adjust your DCO based on > >> this difference. > > >> So how is this different than the "buffer-half-full" scheme? The > >> difference is that the jitter of the dco, in the case where your data > >> is very bursty, is independant of the burstiness. You still need a > >> buffer large enough to handle the burstiness, but you end up only > >> making very small changes to the dco in order to make it track. > > >> There are many networking standards that take this approach, for > >> example you can google "Ethernet AVB". > > >> Bob Adams > > >Isn't this what the low pass filter helps with? Even if the packets > >arrive at very random times, the LPF will smooth the control "voltage" > >to the DCO. In my case I don't expect a lot of jitter from the input > >signal. On the other end, I am not handling the packet interface. My > >customer's equipment is doing that. I am supplied with data and > >clock. I just have to separate the two data streams and reclock the > >output with the fixed delay line. > > >In another approach, I have to provide a fixed time delay independent > >of the data rate. In that case the error integrator is removed and > >the buffer length directly controls the DCO rate. I expect that will > >not have stability issues. > > >Rick > > FWIW, this sounds a lot like a typical demultiplexing problem where a > multiplexed stream has to be broken back out into the constituent > signals. The sub-channels are often at different average rates, and > depending on how the multiplexing scheme worked the subchannels may > fill their indvidual buffers in a pretty bursty fashion. > > Some standardized interfaces (well, many, actually) want the data to > come back out at a very stable rate. In some cases it needs to come > out at a ridiculously stable rate, and when the FIFO is filling in > bursts it can turn into a tricky problem. > > I think you're on the right track, though. We've done this quite a > few times with a similar approach, but it seems like there's always > some pitfall that's specific to the application. Yes, that is exactly what both approaches are doing. The difference is in the delay that needs to be added to the one channel to compensate for a delay in the other. In addition to needing to provide data at an even rate, the design has to preserve a timing relationship between the two signals. Both have even rates coming into the system. The combined data packets are conveyed over a network and regenerated at the other end. Because the system is giving me a clock that is already stabilized, I don't need to worry about "bursty" clocking. I just have to work with the average rate changing. The requirement I was given is 10 ppm/s, but that was plucked from air and I am sure I should do better than that. The main goal is to preserve the timing relationship between the two signals. One is a time code reference and the other is data that needs to be analyzed in a context of the time code. There are two approaches to solving the larger problem. One is to treat the time code signal as an analog signal and convey that as time samples. I can slave the rate of conversion to the rate of the incoming data stream so the rate ratio does not change. The CODEC has a delay which scales with the sample rate. So a fixed size buffer on the other data stream will keep them aligned. The other approach is to decode the time code and send symbols which requires a much lower data rate on the network. The decoding takes time, but is a fixed amount. So the delay of the other data stream has to scale with its data rate to get a fixed time delay. I am about done simulating the first approach. I should be able to get the second approach to work much more easily. RickArticle: 139413
ISE10 Project Navigator offers a lot of synthesis and map options (Block Ram packing, LUT combining just to name a few of them) that I have successfully used to shrink my design. I was wondering how to use this options when using Synplify Pro (as integrated tool in ISE10 and as stand alone tool). Thanks for any hint. GAArticle: 139414
On Sat, 28 Mar 2009 13:35:04 -0700, Joerg <notthisjoergsch@removethispacbell.net> wrote: >John Larkin wrote: >> On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk> >> wrote: >> >>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >>> news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... >>>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >>>> <pabloalvarezsanchez@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> For several reasons a need very low jitter on some of my outputs. I >>>>> was thinking of using LVDS for my I/Os and of course I do not consider >>>>> using a clock manager. Do you have an idea of the order of magnitude >>>>> of jitter one can get? What fpga would you recomend for a low cost >>>>> small design? >>>>> >>>>> Cheers >>>>> >>>>> Pablo >>>> >>>> Here's a signal that has made three independent non-trivial in/out >>>> passes through a Spartan3, plus passed through six external SSI CMOS >>>> chips. Total jitter of that whole chain is below 20 ps RMS. >>>> >>>> ftp://jjlarkin.lmi.net/Jitter3.jpg >>>> >>>> >>>> We were fairly impressed. Spartans are like having a few thousand 10KH >>>> ECL gates on a $20 chip. >>>> >>>> John >>>> >>> I've just built a fractional-N synthesizer using a Spartan 3. The reference >>> frequency comes from an LVDS-output crystal oscillator. The VCO frequency >>> is fed into the opposite side of the FPGA using an LVDS-output comparator >>> and the (AD9901 style) PFD output from the FPGA to the loop filter is also >>> LVDS on a third physical side. >>> >>> Inside the FPGA, the VCO divider and reference divider are on local clocks >>> confined to small regions around the pads where they enter. BUFGCE >>> primitives are used to gate the clocks so I only send edges over the global >>> clock network when a divider resets. The AD9901 PFD ensures that the VCO >>> and reference divider outputs are 180 degrees out of phase. >>> >>> Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 >>> CPLD. It worked quite well, but there was some interation between the VCO >>> and reference frequencies which caused integer-N boundary spurs. I see no >>> trace of these spurs on my new Spartan 3 design, and the phase noise is much >>> lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I >>> haven't finished tweaking things yet. >>> >>> >>> They say don't attempt analogue functions in FPGAs; but it seems to work >>> remarkably well in the Spartan 3, which is fully static when I'm not >>> clocking it. >>> >>> >> >> The Spartan LVDS inputs are pretty good r-r comparators. And you can >> make lots of good, cheap delta-sigma dacs from an FPGA. >> >> You can do cool analog things with FPGAs. ... > > >Can you tell us more about that? Sounds very interesting. As long as it >doesn't rely on really undocumented parameters like leakage currents, or >goes away when the family gets discontinued (one reason I don't like >FPGA much). How are you going to get an edge on your competition unless you use stuff that they don't know? JohnArticle: 139415
On Mar 28, 6:52=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Sat, 28 Mar 2009 13:35:04 -0700, Joerg > > > > <notthisjoerg...@removethispacbell.net> wrote: > >John Larkin wrote: > >> On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <a...@nospam.co.uk> > >> wrote: > > >>> "John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in m= essage > >>>news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... > >>>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez > >>>> <pabloalvarezsanc...@gmail.com> wrote: > > >>>>> Hi, > > >>>>> For several reasons a need very low jitter on some of my outputs. I > >>>>> was thinking of using LVDS for my I/Os and of course I do not consi= der > >>>>> using a clock manager. Do you have an idea of the order of magnitud= e > >>>>> of jitter one can get? What fpga would you recomend for a low cost > >>>>> small design? > > >>>>> Cheers > > >>>>> Pablo > > >>>> Here's a signal that has made three independent non-trivial in/out > >>>> passes through a Spartan3, plus passed through six external SSI CMOS > >>>> chips. Total jitter of that whole chain is below 20 ps RMS. > > >>>>ftp://jjlarkin.lmi.net/Jitter3.jpg > > >>>> We were fairly impressed. Spartans are like having a few thousand 10= KH > >>>> ECL gates on a $20 chip. > > >>>> John > > >>> I've just built a fractional-N synthesizer using a Spartan 3. =A0The = reference > >>> frequency comes from an LVDS-output crystal oscillator. =A0The VCO fr= equency > >>> is fed into the opposite side of the FPGA using an LVDS-output compar= ator > >>> and the (AD9901 style) PFD output from the FPGA to the loop filter is= also > >>> LVDS on a third physical side. > > >>> Inside the FPGA, the VCO divider and reference divider are on local c= locks > >>> confined to small regions around the pads where they enter. =A0BUFGCE > >>> primitives are used to gate the clocks so I only send edges over the = global > >>> clock network when a divider resets. =A0The AD9901 PFD ensures that t= he VCO > >>> and reference divider outputs are 180 degrees out of phase. > > >>> Some years ago, I built a cruder fractional-N synth using a 5V Altera= PLCC84 > >>> CPLD. =A0It worked quite well, but there was some interation between = the VCO > >>> and reference frequencies which caused integer-N boundary spurs. =A0I= see no > >>> trace of these spurs on my new Spartan 3 design, and the phase noise = is much > >>> lower. =A0I'm seeing around -95 dBc/Hz at 100 Hz offsets at the momen= t; and I > >>> haven't finished tweaking things yet. > > >>> They say don't attempt analogue functions in FPGAs; but it seems to w= ork > >>> remarkably well in the Spartan 3, which is fully static when I'm not > >>> clocking it. > > >> The Spartan LVDS inputs are pretty good r-r comparators. And you can > >> make lots of good, cheap delta-sigma dacs from an FPGA. > > >> You can do cool analog things with FPGAs. ... > > >Can you tell us more about that? Sounds very interesting. As long as it > >doesn't rely on really undocumented parameters like leakage currents, or > >goes away when the family gets discontinued (one reason I don't like > >FPGA much). > > How are you going to get an edge on your competition unless you use > stuff that they don't know? > > John You mean the stuff that can change without warning? One place where I worked had a design that was using FET transistors to control the current to control the current to an LED backlight, V in and I out. Heck, they publish a curve for that right? That would be a *typical* curve. After using this part for some years, the circuit stopped working right with a dim backlight. The FET maker had "improved" their process and changed the threshold voltage just a bit, still within spec, but not the same curve. So now the ROM values for the DAC didn't let enough current pass. It's not likely that the LVDS circuit would be changed at any point in the future... I guess that is where the "trouble" part comes in. RickArticle: 139416
On Thu, 26 Mar 2009 13:39:47 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk> >wrote: > >> >>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >>news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... >>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >>> <pabloalvarezsanchez@gmail.com> wrote: >>> >>>>Hi, >>>> >>>>For several reasons a need very low jitter on some of my outputs. I >>>>was thinking of using LVDS for my I/Os and of course I do not consider >>>>using a clock manager. Do you have an idea of the order of magnitude >>>>of jitter one can get? What fpga would you recomend for a low cost >>>>small design? >>>> >>>>Cheers >>>> >>>>Pablo >>> >>> >>> Here's a signal that has made three independent non-trivial in/out >>> passes through a Spartan3, plus passed through six external SSI CMOS >>> chips. Total jitter of that whole chain is below 20 ps RMS. >>> >>> ftp://jjlarkin.lmi.net/Jitter3.jpg >>> >>> >>> We were fairly impressed. Spartans are like having a few thousand 10KH >>> ECL gates on a $20 chip. >>> >>> John >>> >> >>I've just built a fractional-N synthesizer using a Spartan 3. The reference >>frequency comes from an LVDS-output crystal oscillator. The VCO frequency >>is fed into the opposite side of the FPGA using an LVDS-output comparator >>and the (AD9901 style) PFD output from the FPGA to the loop filter is also >>LVDS on a third physical side. >> >>Inside the FPGA, the VCO divider and reference divider are on local clocks >>confined to small regions around the pads where they enter. BUFGCE >>primitives are used to gate the clocks so I only send edges over the global >>clock network when a divider resets. The AD9901 PFD ensures that the VCO >>and reference divider outputs are 180 degrees out of phase. >> >>Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 >>CPLD. It worked quite well, but there was some interation between the VCO >>and reference frequencies which caused integer-N boundary spurs. I see no >>trace of these spurs on my new Spartan 3 design, and the phase noise is much >>lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I >>haven't finished tweaking things yet. >> >> >>They say don't attempt analogue functions in FPGAs; but it seems to work >>remarkably well in the Spartan 3, which is fully static when I'm not >>clocking it. >> >> > >The Spartan LVDS inputs are pretty good r-r comparators. And you can >make lots of good, cheap delta-sigma dacs from an FPGA. I asked the Altera rep (actually from Arrow) to check on that for me. It seemed like a possibility. I have a bunch of ideas if this is really a possibility (noise and such). >You can do cool analog things with FPGAs. You can also get into a heap >of trouble. I may try? So far the other engineers don't think it can be done. We'll see. ;-)Article: 139417
On Sat, 28 Mar 2009 16:09:45 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >On Mar 28, 6:52 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Sat, 28 Mar 2009 13:35:04 -0700, Joerg >> >> >> >> <notthisjoerg...@removethispacbell.net> wrote: >> >John Larkin wrote: >> >> On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <a...@nospam.co.uk> >> >> wrote: >> >> >>> "John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in message >> >>>news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... >> >>>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >> >>>> <pabloalvarezsanc...@gmail.com> wrote: >> >> >>>>> Hi, >> >> >>>>> For several reasons a need very low jitter on some of my outputs. I >> >>>>> was thinking of using LVDS for my I/Os and of course I do not consider >> >>>>> using a clock manager. Do you have an idea of the order of magnitude >> >>>>> of jitter one can get? What fpga would you recomend for a low cost >> >>>>> small design? >> >> >>>>> Cheers >> >> >>>>> Pablo >> >> >>>> Here's a signal that has made three independent non-trivial in/out >> >>>> passes through a Spartan3, plus passed through six external SSI CMOS >> >>>> chips. Total jitter of that whole chain is below 20 ps RMS. >> >> >>>>ftp://jjlarkin.lmi.net/Jitter3.jpg >> >> >>>> We were fairly impressed. Spartans are like having a few thousand 10KH >> >>>> ECL gates on a $20 chip. >> >> >>>> John >> >> >>> I've just built a fractional-N synthesizer using a Spartan 3. The reference >> >>> frequency comes from an LVDS-output crystal oscillator. The VCO frequency >> >>> is fed into the opposite side of the FPGA using an LVDS-output comparator >> >>> and the (AD9901 style) PFD output from the FPGA to the loop filter is also >> >>> LVDS on a third physical side. >> >> >>> Inside the FPGA, the VCO divider and reference divider are on local clocks >> >>> confined to small regions around the pads where they enter. BUFGCE >> >>> primitives are used to gate the clocks so I only send edges over the global >> >>> clock network when a divider resets. The AD9901 PFD ensures that the VCO >> >>> and reference divider outputs are 180 degrees out of phase. >> >> >>> Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 >> >>> CPLD. It worked quite well, but there was some interation between the VCO >> >>> and reference frequencies which caused integer-N boundary spurs. I see no >> >>> trace of these spurs on my new Spartan 3 design, and the phase noise is much >> >>> lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I >> >>> haven't finished tweaking things yet. >> >> >>> They say don't attempt analogue functions in FPGAs; but it seems to work >> >>> remarkably well in the Spartan 3, which is fully static when I'm not >> >>> clocking it. >> >> >> The Spartan LVDS inputs are pretty good r-r comparators. And you can >> >> make lots of good, cheap delta-sigma dacs from an FPGA. >> >> >> You can do cool analog things with FPGAs. ... >> >> >Can you tell us more about that? Sounds very interesting. As long as it >> >doesn't rely on really undocumented parameters like leakage currents, or >> >goes away when the family gets discontinued (one reason I don't like >> >FPGA much). >> >> How are you going to get an edge on your competition unless you use >> stuff that they don't know? >> >> John > >You mean the stuff that can change without warning? One place where I >worked had a design that was using FET transistors to control the >current to control the current to an LED backlight, V in and I out. >Heck, they publish a curve for that right? That would be a *typical* >curve. After using this part for some years, the circuit stopped >working right with a dim backlight. The FET maker had "improved" >their process and changed the threshold voltage just a bit, still >within spec, but not the same curve. So now the ROM values for the >DAC didn't let enough current pass. Using a fet open-loop as a linear current controller is more risk that I'm willing to take... especially when it's easy to do it right. > >It's not likely that the LVDS circuit would be changed at any point in >the future... I guess that is where the "trouble" part comes in. > >Rick It's a matter of calculated risk. If a part behaves in some useful but undocumented way, and the process is likely stable, the performance may be worth the risk. I think I've been burned more times by semiconductors being discontinued than by their behavior changing. On a thing we're doing now, we're using some SOT-89 power phemts as switches. These are RF parts, and are barely specified for DC behavior; hell, lots of RF fets are totally unspecified for DC behavior. So we're including a place to install a trimpot in case the transfer curves don't stay put. JohnArticle: 139418
On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk>
wrote:
>
>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
>news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com...
>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez
>> <pabloalvarezsanchez@gmail.com> wrote:
>>
>>>Hi,
>>>
>>>For several reasons a need very low jitter on some of my outputs. I
>>>was thinking of using LVDS for my I/Os and of course I do not consider
>>>using a clock manager. Do you have an idea of the order of magnitude
>>>of jitter one can get? What fpga would you recomend for a low cost
>>>small design?
>>>
>>>Cheers
>>>
>>>Pablo
>>
>>
>> Here's a signal that has made three independent non-trivial in/out
>> passes through a Spartan3, plus passed through six external SSI CMOS
>> chips. Total jitter of that whole chain is below 20 ps RMS.
>>
>> ftp://jjlarkin.lmi.net/Jitter3.jpg
>>
>>
>> We were fairly impressed. Spartans are like having a few thousand 10KH
>> ECL gates on a $20 chip.
>>
>> John
>>
>
>I've just built a fractional-N synthesizer using a Spartan 3. The reference
>frequency comes from an LVDS-output crystal oscillator. The VCO frequency
>is fed into the opposite side of the FPGA using an LVDS-output comparator
>and the (AD9901 style) PFD output from the FPGA to the loop filter is also
>LVDS on a third physical side.
>
>Inside the FPGA, the VCO divider and reference divider are on local clocks
>confined to small regions around the pads where they enter. BUFGCE
>primitives are used to gate the clocks so I only send edges over the global
>clock network when a divider resets. The AD9901 PFD ensures that the VCO
>and reference divider outputs are 180 degrees out of phase.
>
>Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84
>CPLD. It worked quite well, but there was some interation between the VCO
>and reference frequencies which caused integer-N boundary spurs. I see no
>trace of these spurs on my new Spartan 3 design, and the phase noise is much
>lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I
>haven't finished tweaking things yet.
>
>
>They say don't attempt analogue functions in FPGAs; but it seems to work
>remarkably well in the Spartan 3, which is fully static when I'm not
>clocking it.
>
>
We did some playing with FPGA-based PLLs. The classic charge-pump PDs
didn't work very well. This works...
fpga_up------ak----R-----+-------opamp
|
|
|
fpga_dn------ka----R-----+
where AK and KA are schottky diodes feeding an opamp integrator (P+I
control) thing, and the up/down things pulse in the obvious
polarities. The fpga outputs are hard and fast, not tri-state, and
overlap a good bit. No deadband, fast as all getout, low phase noise.
John
Article: 139419On Sun, 29 Mar 2009 18:34:04 -0500, "dts4theworld" <dts4theworld@gmail.com> wrote: >Hi everyone, > >I'm currently working on a project which involves a Virtex 5 board with >USB port (and Cypress FX2 MicroController). >My goal is to connect a webcam to the FPGA board and process that input >data with an algorithm which should detect movement (a simple one). > >From the forums I found on the web I understood that this is not an easy >task - connecting the webcam to the FPGA and processing the video signal - >and I'm now searching for any relevant information regarding this. > >I'm using an UVC (USB Video Class) compatible webcam, and I have the >documentation for this from usb.org, but still can't figure out exactly how >the video signal is transmitted (how do you initialize the webcam, how does >the host ask for data, and how is the received data structured). By the >way, I'm working in verilog. > >Is there any link/documentation or example which could possibly help me? > >Thank you in advance, >Chris > This is a significant project as you have figured out. It is not advisable to try to implement the UVC portion in hardware. My suggestion would be to get the linux UVC stack and port the relevant portions of it to a processor (soft-core or otherwise) implemented in your fpga design. Very simplistically, you need a host controller and a UVC driver to talk to the webcam. When the webcam is attached, the host controller sends it USB packets to enumerate the device to find what kind of end-point(s) it supports and hand it off to the UVC stack for video related packet processing. You really don't want to (re)do this in hardware. Get a processor and port enough of linux UVC stack to it, which is a significant task by itself but much smaller than doing all of it yourself. There is also the problem of convincing the fx2 to act as a usb host. It's usually used in peripheral device implementations but it might be possible to hack it to behave like a host in a limited way which should be enough for your purposes. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 139420
John Larkin wrote: > On Sat, 28 Mar 2009 13:35:04 -0700, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > >> John Larkin wrote: >>> On Thu, 26 Mar 2009 19:34:22 -0000, "Andrew Holme" <ah@nospam.co.uk> >>> wrote: >>> >>>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >>>> news:nhfns4lrd245pvu2lt4pnn03lio466j5ti@4ax.com... >>>>> On Wed, 26 Nov 2008 10:05:06 -0800 (PST), palvarez >>>>> <pabloalvarezsanchez@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> For several reasons a need very low jitter on some of my outputs. I >>>>>> was thinking of using LVDS for my I/Os and of course I do not consider >>>>>> using a clock manager. Do you have an idea of the order of magnitude >>>>>> of jitter one can get? What fpga would you recomend for a low cost >>>>>> small design? >>>>>> >>>>>> Cheers >>>>>> >>>>>> Pablo >>>>> Here's a signal that has made three independent non-trivial in/out >>>>> passes through a Spartan3, plus passed through six external SSI CMOS >>>>> chips. Total jitter of that whole chain is below 20 ps RMS. >>>>> >>>>> ftp://jjlarkin.lmi.net/Jitter3.jpg >>>>> >>>>> >>>>> We were fairly impressed. Spartans are like having a few thousand 10KH >>>>> ECL gates on a $20 chip. >>>>> >>>>> John >>>>> >>>> I've just built a fractional-N synthesizer using a Spartan 3. The reference >>>> frequency comes from an LVDS-output crystal oscillator. The VCO frequency >>>> is fed into the opposite side of the FPGA using an LVDS-output comparator >>>> and the (AD9901 style) PFD output from the FPGA to the loop filter is also >>>> LVDS on a third physical side. >>>> >>>> Inside the FPGA, the VCO divider and reference divider are on local clocks >>>> confined to small regions around the pads where they enter. BUFGCE >>>> primitives are used to gate the clocks so I only send edges over the global >>>> clock network when a divider resets. The AD9901 PFD ensures that the VCO >>>> and reference divider outputs are 180 degrees out of phase. >>>> >>>> Some years ago, I built a cruder fractional-N synth using a 5V Altera PLCC84 >>>> CPLD. It worked quite well, but there was some interation between the VCO >>>> and reference frequencies which caused integer-N boundary spurs. I see no >>>> trace of these spurs on my new Spartan 3 design, and the phase noise is much >>>> lower. I'm seeing around -95 dBc/Hz at 100 Hz offsets at the moment; and I >>>> haven't finished tweaking things yet. >>>> >>>> >>>> They say don't attempt analogue functions in FPGAs; but it seems to work >>>> remarkably well in the Spartan 3, which is fully static when I'm not >>>> clocking it. >>>> >>>> >>> The Spartan LVDS inputs are pretty good r-r comparators. And you can >>> make lots of good, cheap delta-sigma dacs from an FPGA. >>> >>> You can do cool analog things with FPGAs. ... >> >> Can you tell us more about that? Sounds very interesting. As long as it >> doesn't rely on really undocumented parameters like leakage currents, or >> goes away when the family gets discontinued (one reason I don't like >> FPGA much). > > How are you going to get an edge on your competition unless you use > stuff that they don't know? > Oh, I do a lot of unorthodox stuff. Using 74HCU or CD4000 in analog circuits, switcher FETs in servos, RF parts for digital functions and so on. I am just curious what can be done with an FPGA in that respect. A long time ago I was looking into using the old Intel CPLD series that way because of they microamp capabilities. Boy was I glad I didn't, shortly after they ditched the whole line. Thing is, most of my designs are targeted for more than a decade in production. And no trimpots or calibration allowed unless that can be automated. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 139421
On Sat, 28 Mar 2009 18:00:34 +0100, ACD <acd4usenet@lycos.de> wrote: >For educational purposes I want to implement a function that has a high >number of inputs. >Since such a function would end up anyway only as a component of a >larger design I do not care for pin limitations of a given chip. >But the entire design does not exist. >So currently I try to use the INCREMENTAL_SYNTHESIS attribute. >Now I get the warning that this is deprecated, and I should use >partitions instead. >As far as I have understood XAPP918 I have to have the entire design to >be able to define my particular function as partition. >Of course I could build a dummy-top design which uses a shift register >or something like that to provide the input pins. > >There has to be a way to build a core with ISE, not? > >Andreas Just use the regular synthesis flow, but with the setting to generate I/O buffers turned OFF. Then you can instantiate it as a component in a top level design, and attach a "box_type" attribute to that component, set to the string "black_box". (Using a component gives you something to attach the attribute to. Direct entity instantiation is sometimes preferred; but then I don't know what you attach the attribute to: maybe a label you later attach to the instance?) Synthesising the top level should report a black box for the component. The NGDbuild then needs to find the synthesised output (ngc file) for the component; either in the project dir, or in its core search path. This is just how EDK cores are treated in the ISE flow. - BrianArticle: 139422
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:s8cts4d6jcmvbk2tu3cd3tua362o6gtde7@4ax.com...
>
> We did some playing with FPGA-based PLLs. The classic charge-pump PDs
> didn't work very well. This works...
>
>
> fpga_up------ak----R-----+-------opamp
> |
> |
> |
> fpga_dn------ka----R-----+
>
>
> where AK and KA are schottky diodes feeding an opamp integrator (P+I
> control) thing, and the up/down things pulse in the obvious
> polarities. The fpga outputs are hard and fast, not tri-state, and
> overlap a good bit. No deadband, fast as all getout, low phase noise.
>
> John
>
Even better is :-
V+
|
R
|
fpga_up------ka----ak-----+-------opamp
|
|
|
fpga_dn------ak----ka-----+
|
R
|
0V
Syms.
Article: 139423In comp.arch.fpga Joerg <notthisjoergsch@removethispacbell.net> wrote: > Oh, I do a lot of unorthodox stuff. Using 74HCU or CD4000 in analog > circuits, switcher FETs in servos, RF parts for digital functions and so > on. I am just curious what can be done with an FPGA in that respect. I once knew someone who built an FM radio transmitter using a 74S04 as the output stage. I suppose cheaper than RF transistors at the time. -- glenArticle: 139424
On Sun, 29 Mar 2009 02:39:04 +0100, Symon wrote: > "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in > message news:s8cts4d6jcmvbk2tu3cd3tua362o6gtde7@4ax.com... >> >> We did some playing with FPGA-based PLLs. The classic charge-pump PDs >> didn't work very well. This works... >> >> >> fpga_up------ak----R-----+-------opamp >> | >> | >> | >> fpga_dn------ka----R-----+ >> >> >> where AK and KA are schottky diodes feeding an opamp integrator (P+I >> control) thing, and the up/down things pulse in the obvious polarities. >> The fpga outputs are hard and fast, not tri-state, and overlap a good >> bit. No deadband, fast as all getout, low phase noise. >> >> John >> > Even better is :- > > V+ > | > R > | > fpga_up------ka----ak-----+-------opamp > | > | > | > fpga_dn------ak----ka-----+ > | > R > | > 0V > > Syms. I've used 74HCT9046 parts for the same purpose. The '9046 has an accurately matched (~1%) current source and sink which is something that's hard to achieve with discretes. The output of the FPGA can be AC coupled into the '9046 to get around the level shifting problem. Regards, Allan
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