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
Rotem Gazit <rotem.gazit@gmail.com> writes: > Hi All, > We are looking for a board (or adaptor) able to convert CameraLink > video to Hotlink-II. > Hi Rotem, We could probably design and make you a custom board - contact me off line if you are interested. Thanks, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 121176
cpope wrote: > I'm working with the xilinx corgen cic v3.0. I'm finding that to get a > decent rejection in the images (60 dB) I need about 4 stages. My input is > only 10 bit and I still end up with a 66 bit output, 50 of which are thrown > away. As a result my design won't fit in my device. Seems horribly > inefficient to me, so I have some questions: > > 1. My coregen says it doesn't support V4 for the cic so I've been compiling > for V2. Seems like the DSP48 with the large accumulator is ideal for CICs? > 2. Looks like the exponential bit growith is from the number of stages. > Since noone uses more than 16 bits at the output why can't the output of the > first integrator be trimmed back to 16 bit before feeding the next and so > on? > 3. If the cic is just a box car filter wouldn't it be easier to implement as > a single subtractor/accumulator whose inputs are the current sample and the > sample delayed by R? At least for reasonable R (< 8192) seems like it should > fit in block ram okay. > > Thanks for any help, > Clark > > The coregen doesn't support V4 simply because no one has re-written it to instantiate the DSP48s instead of LUTs. You should be able to use a V2 LUT version in V4 though, although it will not be all that fast because the carry chains in V4 are fairly slow compared to the DSP48's. The DSP48 limits the CIC width to 48 bits without going through some design gymnastics to cascade DSP48's. For a CIC, 48 bits isn't very much. The CIC's response is a sinc function, which provides only about 13dB attenuation of the first sidelobe for a first order filter. In order to increase the effectiveness of the filter, several sections are cascaded to increase the attenuation of the sidelobes. You typically need 4th or 5th order filters for practical applications. The gain of the CIC filter is (N*R)^M where N is the delay in the comb section (usually 1), R is the decimation ratio, and M is the order of the filter. The width of the integrators must accommodate the input signal times the gain without overflow. Unfortunately, because the filter relies on differences of an integration, the integration has to be full precision so that rounding errors do not get accumulated in the integrators. The result is that the integrators cannot be truncated, and they have to have enough bits to represent the maximum input times the gain of the filter. You can reduce the word width between the integrator and comb sections by simple truncation so that the comb section only has to be M bits wider than the output (and can taper down one bit per stage as it progresses to the output). Rounding isn't necessary if the width is reduced before the comb sections because the difference operation of the comb removes the bias anyway. A first order CIC is equivalent to an N*R stage boxcar filter. To get the response of a 5th order CIC, you'd have to cascade 5 such filters together, and you can't decimate until after the last stage. The adder and subtractor still has to be wide enough to accommodate the gain of the filter (N*R) at each stage. Like the CIC, you can reduce the width of the subtractor, but the integrator has to be wide enough to accommodate the max signal times N without overflow. You wind up with adders that are only log2(N) bits wider than the input if you truncate between stages instead of M*log2(N), but you also wind up with a memory for each stage as well. If your CIC is decimating, you can take advantage of the lower rate through the comb section by using bit or digit serial arithmetic, or by sharing the comb section among multiple channels.Article: 121177
On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: > I need to extend a memory-mapped bus into another enclosure and > thought that a bidirectional LVDS implementation with serial/ > deserializer pairs at each end might work. Does anyone have any > experience or guidance on such a setup? LVDS has a really low common mode voltage tolerance, so if you use it between enclosures, make very sure you have an excellent grounding scheme and control of return currents between enclosures. Generally not a good application of LVDS without some means of improving CMV tolerance. AndyArticle: 121178
cpope wrote: > "Jon Beniston" <jon@beniston.com> wrote in message > news:1182773495.080303.224560@q69g2000hsb.googlegroups.com... > >>>I'm working with the xilinx corgen cic v3.0. I'm finding that to get a >>>decent rejection in the images (60 dB) I need about 4 stages. My input > > is > >>>only 10 bit and I still end up with a 66 bit output, 50 of which are > > thrown > >>>away. As a result my design won't fit in my device. >> >>If they are truely thrown away, it shouldn't be the cause of why you >>aren't fitting into the device. >> > > > I throw them away at the output, I'm not convinced that the compiler trims > them all the way back through the integrators. In fact I'm pretty sure it > doesn't because I found a colleague that had to implement his own CIC that > uses significantly less resources then the coregen block because he was able > to trim the widths of the integrator sections. > > >>>1. My coregen says it doesn't support V4 for the cic so I've been > > compiling > >>>for V2. Seems like the DSP48 with the large accumulator is ideal for > > CICs? > >>Why do you need DSP48s? Isn't the whole point of a CIC that it doesn't >>use multiplies? > > > I have them available. Should be less power and faster speed than > implementing a 48 bit accumulator in slices right? > > >>>2. Looks like the exponential bit growith is from the number of stages. >>>Since noone uses more than 16 bits at the output why can't the output of > > the > >>>first integrator be trimmed back to 16 bit before feeding the next and > > so > >>>on? >> >>Aren't all the integrators cascaded together, then followed by all the >>combs? > > > Yes. My point is the width of the integrators and combs don't seem to be > optimized at all. For example, If I'm only using 16 bits at the output why > would the combs need to be more than say 16+N*2 wide? My coregen sets them > at 66. Similarly, the first integrator should only need input width plus > log2(R) width, the second needs input width + 2*log2(R) and so on. And > that's only if you really need full precision which I suspect you don't. At > any rate the coregen doesn't seem to employ any of these optimizations? > > >>Cheers, >>Jon >> >> > > > No, the integrators all have to have enough bits to hold the input times the gain. Keep in mind each one is keeping a running accumulation of its input, and the modular overflow has to be above the bits you are taking out of the bank. You cannot use fewer MSBs on the first integrators because the CIC takes advantage of the modular property of the 2's complement system and doing so puts the modular overflow in the bit field you are taking out. The 66 bit width coregen is using should be a result of the gain calculated for the maximum decimation ratio and order of your filter. For a 4th order filter with 10 bits input, that means it is set up for decimation ratios upto 2^14. If you can reduce the maximum decimation ratio, it should reduce the width of the integrators. Yes, implementing using the DSP48s is faster than using straight fabric adders. Most CIC's need more than 48 bits, so you have to cascade them. The comb section isn't as bad because you can reduce the width before the comb.Article: 121179
My goal is to implement a bit-error counter targeting 1GHz. The
datawidth is parametrizable. I started off this way,
Verilog code:
----------
assign mismatch[datawidth-1:0] = input_data ^ expected_data;
assign matched = ~( | mismatch); // reduction NOR
always @(posedge clk or posedge reset) begin
if (reset)
error_count = 0;
else if (~matched)
for (i=0; i<datawidth; i=i+1)
error_count = error_count + mismatch[i];
end
---------/////////----------------------
The above meets timing for small datawidths (like 8-bits) and starts
failing to meet timing once the datawidth gets larger. I will be glad
for suggestions of alternate ways to implement this bit-error counter.
In practice our datawidths could go upto 256 bits.
Thanks
Article: 121180> The above meets timing for small datawidths (like 8-bits) and starts > failing to meet timing once the datawidth gets larger. I will be glad > for suggestions of alternate ways to implement this bit-error counter. > In practice our datawidths could go upto 256 bits. Spread your algorithm to work over more than one clock cycle. Use a pipeline stage over eigth clocks. The first stage calculates bit 0 to 7, the second calculates 8 to 15 and so on. In an additional stage you sum up all results. The result is always 9 clocks behind. See http://en.wikipedia.org/wiki/Pipeline_%28computer%29 for a general explanation of pipelines. hth Günther JehleArticle: 121181
On Jun 27, 9:09 am, Andy <jonesa...@comcast.net> wrote: > On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: > > > I need to extend a memory-mapped bus into another enclosure and > > thought that a bidirectional LVDS implementation with serial/ > > deserializer pairs at each end might work. Does anyone have any > > experience or guidance on such a setup? > > LVDS has a really low common mode voltage tolerance, so if you use it > between enclosures, make very sure you have an excellent grounding > scheme and control of return currents between enclosures. Generally > not a good application of LVDS without some means of improving CMV > tolerance. > > Andy The second device draws its power from the first, so they share a common ground. From rich@example.net Wed Jun 27 11:27:18 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!nx02.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc06.POSTED!dd653b87!not-for-mail From: Rich Grise <rich@example.net> Subject: Re: Bidirectional LVDS User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.06.27.18.27.35.295523@example.net> Newsgroups: sci.electronics.design,comp.arch.embedded,comp.arch.fpga References: <1182958775.879163.15750@a26g2000pre.googlegroups.com> <1182960585.995282.256300@k29g2000hsd.googlegroups.com> <1182966001.290721.158570@d30g2000prg.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 30 Date: Wed, 27 Jun 2007 18:27:18 GMT NNTP-Posting-Host: 71.103.128.31 X-Complaints-To: abuse@verizon.net X-Trace: trnddc06 1182968838 71.103.128.31 (Wed, 27 Jun 2007 14:27:18 EDT) NNTP-Posting-Date: Wed, 27 Jun 2007 14:27:18 EDT Xref: prodigy.net sci.electronics.design:820224 comp.arch.embedded:255706 comp.arch.fpga:133036 X-Received-Date: Wed, 27 Jun 2007 14:27:20 EDT (newsdbm02.news.prodigy.net) On Wed, 27 Jun 2007 10:40:01 -0700, Richard Henry wrote: > On Jun 27, 9:09 am, Andy <jonesa...@comcast.net> wrote: >> On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: >> >> > I need to extend a memory-mapped bus into another enclosure and >> > thought that a bidirectional LVDS implementation with serial/ >> > deserializer pairs at each end might work. Does anyone have any >> > experience or guidance on such a setup? >> >> LVDS has a really low common mode voltage tolerance, so if you use it >> between enclosures, make very sure you have an excellent grounding >> scheme and control of return currents between enclosures. Generally >> not a good application of LVDS without some means of improving CMV >> tolerance. > > The second device draws its power from the first, so they share a > common ground. How far? With proper terminations, depending on the bus speed, you could use ordinary ribbon cable but with twice as many leads as signals, and make every other line ground. I've made this work with 3 feet (~1m) of ribbon cable, but at fairly low bus speeds. YMMV. :-) Good Luck! RichArticle: 121182
> > No, the integrators all have to have enough bits to hold the input times > the gain. Keep in mind each one is keeping a running accumulation of > its input, and the modular overflow has to be above the bits you are > taking out of the bank. You cannot use fewer MSBs on the first > integrators because the CIC takes advantage of the modular property of > the 2's complement system and doing so puts the modular overflow in the > bit field you are taking out. I'm not sure that's true. At least this reference (and a colleagues optimized design implies they can be trimmed): http://www.phptr.com/articles/article.asp?p=361985&seqNum=4&rl=1 see 11.4.2 -ClarkArticle: 121183
"Ray Andraka" <ray@andraka.com> wrote in message news:aJvgi.814$%V6.805@newsfe14.lga... > cpope wrote: > > I'm working with the xilinx corgen cic v3.0. I'm finding that to get a > > decent rejection in the images (60 dB) I need about 4 stages. My input is > > only 10 bit and I still end up with a 66 bit output, 50 of which are thrown > > away. As a result my design won't fit in my device. Seems horribly > > inefficient to me, so I have some questions: > > > > 1. My coregen says it doesn't support V4 for the cic so I've been compiling > > for V2. Seems like the DSP48 with the large accumulator is ideal for CICs? > > 2. Looks like the exponential bit growith is from the number of stages. > > Since noone uses more than 16 bits at the output why can't the output of the > > first integrator be trimmed back to 16 bit before feeding the next and so > > on? > > 3. If the cic is just a box car filter wouldn't it be easier to implement as > > a single subtractor/accumulator whose inputs are the current sample and the > > sample delayed by R? At least for reasonable R (< 8192) seems like it should > > fit in block ram okay. > > > > Thanks for any help, > > Clark > > > > > > The coregen doesn't support V4 simply because no one has re-written it > to instantiate the DSP48s instead of LUTs. You should be able to use a > V2 LUT version in V4 though, although it will not be all that fast > because the carry chains in V4 are fairly slow compared to the DSP48's. > The DSP48 limits the CIC width to 48 bits without going through some > design gymnastics to cascade DSP48's. For a CIC, 48 bits isn't very much. > It is for a boxcar filter though, right? If I just implement a straight box car I need log2R+B+1 bits in the accumulator. The max log2R in coregen is 14 so that leaves data sizes up to 34 bits. > The CIC's response is a sinc function, which provides only about 13dB > attenuation of the first sidelobe for a first order filter. In order to > increase the effectiveness of the filter, several sections are cascaded > to increase the attenuation of the sidelobes. You typically need 4th or > 5th order filters for practical applications. The gain of the CIC > filter is (N*R)^M where N is the delay in the comb section (usually 1), > R is the decimation ratio, and M is the order of the filter. The width > of the integrators must accommodate the input signal times the gain > without overflow. Unfortunately, because the filter relies on > differences of an integration, the integration has to be full precision > so that rounding errors do not get accumulated in the integrators. The > result is that the integrators cannot be truncated, and they have to > have enough bits to represent the maximum input times the gain of the > filter. You can reduce the word width between the integrator and comb > sections by simple truncation so that the comb section only has to be M > bits wider than the output (and can taper down one bit per stage as it > progresses to the output). Rounding isn't necessary if the width is > reduced before the comb sections because the difference operation of the > comb removes the bias anyway. > I think the integrators can be trimmed (see other response). Agree about the comb but it doesn't seem to me that xilinx is doing that optimization. In fact I don't know that it could for a CIC that supports multiple decimation rates. > A first order CIC is equivalent to an N*R stage boxcar filter. To get > the response of a 5th order CIC, you'd have to cascade 5 such filters > together, and you can't decimate until after the last stage. The adder > and subtractor still has to be wide enough to accommodate the gain of > the filter (N*R) at each stage. Like the CIC, you can reduce the width > of the subtractor, but the integrator has to be wide enough to > accommodate the max signal times N without overflow. You wind up with > adders that are only log2(N) bits wider than the input if you truncate > between stages instead of M*log2(N), but you also wind up with a memory > for each stage as well. Yes, but I have plenty of brams and dsp48s, I'm short on slices. Plus I want to minimize power consumption. > > If your CIC is decimating, you can take advantage of the lower rate > through the comb section by using bit or digit serial arithmetic, or by > sharing the comb section among multiple channels. I'm not convinced xilinx even does this optimization.Article: 121184
cpope wrote: >>No, the integrators all have to have enough bits to hold the input times >>the gain. Keep in mind each one is keeping a running accumulation of >>its input, and the modular overflow has to be above the bits you are >>taking out of the bank. You cannot use fewer MSBs on the first >>integrators because the CIC takes advantage of the modular property of >>the 2's complement system and doing so puts the modular overflow in the >>bit field you are taking out. > > > I'm not sure that's true. At least this reference (and a colleagues > optimized design implies they can be trimmed): > http://www.phptr.com/articles/article.asp?p=361985&seqNum=4&rl=1 > > see 11.4.2 > > -Clark > > I assumed the OP is asking about a decimating CIC, in which case my assertion is absolutely true. The article you cited also says the same thing: "In a down-sampling filter the growth appears immediately in the first integrator stage, and all subsequent integrators and comb filters must honor the most significant bit of the first integrator stage." It is possible he was asking about an interpolating (up-sampling) CIC, in which case the math is a little bit different, and as a result there are differences in how pruning can be applied.Article: 121185
"Rich Grise" <rich@example.net> wrote in message news:pan.2007.06.27.18.27.35.295523@example.net... > On Wed, 27 Jun 2007 10:40:01 -0700, Richard Henry wrote: >> On Jun 27, 9:09 am, Andy <jonesa...@comcast.net> wrote: >>> On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: >>> >>> > I need to extend a memory-mapped bus into another enclosure and >>> > thought that a bidirectional LVDS implementation with serial/ >>> > deserializer pairs at each end might work. Does anyone have any >>> > experience or guidance on such a setup? >>> >>> LVDS has a really low common mode voltage tolerance, so if you use >>> it >>> between enclosures, make very sure you have an excellent grounding >>> scheme and control of return currents between enclosures. Generally >>> not a good application of LVDS without some means of improving CMV >>> tolerance. >> >> The second device draws its power from the first, so they share a >> common ground. > > How far? With proper terminations, depending on the bus speed, you > could > use ordinary ribbon cable but with twice as many leads as signals, and > make every other line ground. > > I've made this work with 3 feet (~1m) of ribbon cable, but at fairly > low bus speeds. > > YMMV. :-) Erm... one (single-ended) application of LVDS I know of shoves a 25MHz clock down some ribbon cable... 10m of it. Seems to work. LVDS, being a current loop, tolerates this kind of (ab)use better than most. To the OP re bidirectional: it's not clear to me whether you expect to run two loops (one outgoing, one incoming), or shove data down one pair of wires in boith directions. If the latter, I'm not clear on where you'd put the receiver load - at both ends? If so, expect to see half the voltage across each receiver. Steve http://www.fivetrees.comArticle: 121186
On Jun 27, 12:35 pm, "Steve at fivetrees" <s...@NOSPAMTAfivetrees.com> wrote: > "Rich Grise" <r...@example.net> wrote in message > > news:pan.2007.06.27.18.27.35.295523@example.net... > > > > > > > On Wed, 27 Jun 2007 10:40:01 -0700, Richard Henry wrote: > >> On Jun 27, 9:09 am, Andy <jonesa...@comcast.net> wrote: > >>> On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: > > >>> > I need to extend a memory-mapped bus into another enclosure and > >>> > thought that a bidirectional LVDS implementation with serial/ > >>> > deserializer pairs at each end might work. Does anyone have any > >>> > experience or guidance on such a setup? > > >>> LVDS has a really low common mode voltage tolerance, so if you use > >>> it > >>> between enclosures, make very sure you have an excellent grounding > >>> scheme and control of return currents between enclosures. Generally > >>> not a good application of LVDS without some means of improving CMV > >>> tolerance. > > >> The second device draws its power from the first, so they share a > >> common ground. > > > How far? With proper terminations, depending on the bus speed, you > > could > > use ordinary ribbon cable but with twice as many leads as signals, and > > make every other line ground. > > > I've made this work with 3 feet (~1m) of ribbon cable, but at fairly > > low bus speeds. > > > YMMV. :-) > > Erm... one (single-ended) application of LVDS I know of shoves a 25MHz > clock down some ribbon cable... 10m of it. Seems to work. LVDS, being a > current loop, tolerates this kind of (ab)use better than most. > > To the OP re bidirectional: it's not clear to me whether you expect to > run two loops (one outgoing, one incoming), or shove data down one pair > of wires in boith directions. If the latter, I'm not clear on where > you'd put the receiver load - at both ends? If so, expect to see half > the voltage across each receiver. > > Stevehttp://www.fivetrees.com- Hide quoted text - > > - Show quoted text - I was contemplating the former as shown in National's application (Fig 2.4): http://www.national.com/appinfo/lvds/files/lvds_ch2.pdf It also has the precaution about lower voltages, but it predicts a 10m limit (my app is much shorter) and cautions against a noisy environment (one enclosure includes an rf transmitter).Article: 121187
"Rich Grise" <rich@example.net> wrote in message news:pan.2007.06.27.18.27.35.295523@example.net... > On Wed, 27 Jun 2007 10:40:01 -0700, Richard Henry wrote: >> On Jun 27, 9:09 am, Andy <jonesa...@comcast.net> wrote: >>> On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: >>> >>> > I need to extend a memory-mapped bus into another enclosure and >>> > thought that a bidirectional LVDS implementation with serial/ >>> > deserializer pairs at each end might work. Does anyone have any >>> > experience or guidance on such a setup? >>> >>> LVDS has a really low common mode voltage tolerance, so if you use >>> it >>> between enclosures, make very sure you have an excellent grounding >>> scheme and control of return currents between enclosures. Generally >>> not a good application of LVDS without some means of improving CMV >>> tolerance. >> >> The second device draws its power from the first, so they share a >> common ground. > > How far? With proper terminations, depending on the bus speed, you > could > use ordinary ribbon cable but with twice as many leads as signals, and > make every other line ground. > > I've made this work with 3 feet (~1m) of ribbon cable, but at fairly > low bus speeds. Further to earlier response: re-reading this carefully, I'd agree if we were talking about normal (TTL-esque) digital signals. But with LVDS, it *is* a differential current loop. A twisted pair is ideal, otherwise I'd put the two conductors side by side in a ribbon with a guard ground either side. YMMV ;) Steve http://www.fivetrees.comArticle: 121188
"Ray Andraka" <ray@andraka.com> wrote in message news:iWygi.202227$mJ1.153022@newsfe22.lga... > cpope wrote: > > >>No, the integrators all have to have enough bits to hold the input times > >>the gain. Keep in mind each one is keeping a running accumulation of > >>its input, and the modular overflow has to be above the bits you are > >>taking out of the bank. You cannot use fewer MSBs on the first > >>integrators because the CIC takes advantage of the modular property of > >>the 2's complement system and doing so puts the modular overflow in the > >>bit field you are taking out. > > > > > > I'm not sure that's true. At least this reference (and a colleagues > > optimized design implies they can be trimmed): > > http://www.phptr.com/articles/article.asp?p=361985&seqNum=4&rl=1 > > > > see 11.4.2 > > > > -Clark > > > > > I assumed the OP is asking about a decimating CIC, in which case my > assertion is absolutely true. The article you cited also says the same > thing: "In a down-sampling filter the growth appears immediately in the > first integrator stage, and all subsequent integrators and comb filters > must honor the most significant bit of the first integrator stage." > > It is possible he was asking about an interpolating (up-sampling) CIC, > in which case the math is a little bit different, and as a result there > are differences in how pruning can be applied. I'm the OP. That article says the LSBs can be trimmed in the decimating case, right?Article: 121189
On Jun 27, 3:43 pm, Richard Henry <pomer...@hotmail.com> wrote: > On Jun 27, 12:35 pm, "Steve at fivetrees" <s...@NOSPAMTAfivetrees.com> > wrote: > > > > > "Rich Grise" <r...@example.net> wrote in message > > >news:pan.2007.06.27.18.27.35.295523@example.net... > > > > On Wed, 27 Jun 2007 10:40:01 -0700, Richard Henry wrote: > > >> On Jun 27, 9:09 am, Andy <jonesa...@comcast.net> wrote: > > >>> On Jun 27, 10:39 am, Richard Henry <pomer...@hotmail.com> wrote: > > > >>> > I need to extend a memory-mapped bus into another enclosure and > > >>> > thought that a bidirectional LVDS implementation with serial/ > > >>> > deserializer pairs at each end might work. Does anyone have any > > >>> > experience or guidance on such a setup? > > > >>> LVDS has a really low common mode voltage tolerance, so if you use > > >>> it > > >>> between enclosures, make very sure you have an excellent grounding > > >>> scheme and control of return currents between enclosures. Generally > > >>> not a good application of LVDS without some means of improving CMV > > >>> tolerance. > > > >> The second device draws its power from the first, so they share a > > >> common ground. > > > > How far? With proper terminations, depending on the bus speed, you > > > could > > > use ordinary ribbon cable but with twice as many leads as signals, and > > > make every other line ground. > > > > I've made this work with 3 feet (~1m) of ribbon cable, but at fairly > > > low bus speeds. > > > > YMMV. :-) > > > Erm... one (single-ended) application of LVDS I know of shoves a 25MHz > > clock down some ribbon cable... 10m of it. Seems to work. LVDS, being a > > current loop, tolerates this kind of (ab)use better than most. > > > To the OP re bidirectional: it's not clear to me whether you expect to > > run two loops (one outgoing, one incoming), or shove data down one pair > > of wires in boith directions. If the latter, I'm not clear on where > > you'd put the receiver load - at both ends? If so, expect to see half > > the voltage across each receiver. > > > Stevehttp://www.fivetrees.com-Hide quoted text - > > > - Show quoted text - > > I was contemplating the former as shown in National's application (Fig > 2.4): > > http://www.national.com/appinfo/lvds/files/lvds_ch2.pdf > > It also has the precaution about lower voltages, but it predicts a 10m > limit (my app is much shorter) and cautions against a noisy > environment (one enclosure includes an rf transmitter). If you're going to use SERDES on the LVDS lines, I would assume your bit rate is fairly high. In this case I would advise against the bidirectional wire idea. Save yourself the headaches and use one set of wires for each direction. Certainly it is possible to use the circuit of figure 2.4, but you won't be able to change direction quickly, in addition to the reduced signal strength mentioned. The point of SERDES is to reduce the number of pairs significantly, so it shouldn't cost too much to assign the additional pairs to run independent one-way data paths. Just my 2 cents, GaborArticle: 121190
In comp.arch.fpga Steve at fivetrees <steve@nospamtafivetrees.com> wrote: ... > To the OP re bidirectional: it's not clear to me whether you expect to > run two loops (one outgoing, one incoming), or shove data down one pair > of wires in boith directions. If the latter, I'm not clear on where > you'd put the receiver load - at both ends? If so, expect to see half > the voltage across each receiver. That's what Bus-LVDS for. Called also M-LVDS, LVDM or ... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From rich@example.net Wed Jun 27 14:55:32 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!wns13feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc08.POSTED!dd653b87!not-for-mail From: Rich Grise <rich@example.net> Subject: Re: Bidirectional LVDS User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.06.27.21.55.47.193677@example.net> Newsgroups: sci.electronics.design,comp.arch.embedded,comp.arch.fpga References: <1182958775.879163.15750@a26g2000pre.googlegroups.com> <1182960585.995282.256300@k29g2000hsd.googlegroups.com> <1182966001.290721.158570@d30g2000prg.googlegroups.com> <pan.2007.06.27.18.27.35.295523@example.net> <f-ydnVL2gPtNIh_bnZ2dnUVZ8tChnZ2d@pipex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 23 Date: Wed, 27 Jun 2007 21:55:32 GMT NNTP-Posting-Host: 71.103.128.31 X-Complaints-To: abuse@verizon.net X-Trace: trnddc08 1182981332 71.103.128.31 (Wed, 27 Jun 2007 17:55:32 EDT) NNTP-Posting-Date: Wed, 27 Jun 2007 17:55:32 EDT Xref: prodigy.net sci.electronics.design:820275 comp.arch.embedded:255735 comp.arch.fpga:133046 X-Received-Date: Wed, 27 Jun 2007 17:55:32 EDT (newsdbm02.news.prodigy.net) On Wed, 27 Jun 2007 20:51:42 +0100, Steve at fivetrees wrote: > "Rich Grise" <rich@example.net> wrote in message ... >> use ordinary ribbon cable but with twice as many leads as signals, and >> make every other line ground. >> >> I've made this work with 3 feet (~1m) of ribbon cable, but at fairly >> low bus speeds. > > Further to earlier response: re-reading this carefully, I'd agree if we > were talking about normal (TTL-esque) digital signals. But with LVDS, it > *is* a differential current loop. A twisted pair is ideal, otherwise I'd > put the two conductors side by side in a ribbon with a guard ground > either side. > > YMMV ;) http://www.belden.com/pdfs/03Belden_Master_Catalog/07Flat_Cable/07FlatCable.pdf page 9. :-) Cheers! RichArticle: 121191
cpope wrote: > "Ray Andraka" <ray@andraka.com> wrote in message > news:iWygi.202227$mJ1.153022@newsfe22.lga... > >>cpope wrote: >> >> >>>>No, the integrators all have to have enough bits to hold the input times >>>>the gain. Keep in mind each one is keeping a running accumulation of >>>>its input, and the modular overflow has to be above the bits you are >>>>taking out of the bank. You cannot use fewer MSBs on the first >>>>integrators because the CIC takes advantage of the modular property of >>>>the 2's complement system and doing so puts the modular overflow in the >>>>bit field you are taking out. >>> >>> >>>I'm not sure that's true. At least this reference (and a colleagues >>>optimized design implies they can be trimmed): >>>http://www.phptr.com/articles/article.asp?p=361985&seqNum=4&rl=1 >>> >>>see 11.4.2 >>> >>>-Clark >>> >>> >> >>I assumed the OP is asking about a decimating CIC, in which case my >>assertion is absolutely true. The article you cited also says the same >>thing: "In a down-sampling filter the growth appears immediately in the >>first integrator stage, and all subsequent integrators and comb filters >>must honor the most significant bit of the first integrator stage." >> >>It is possible he was asking about an interpolating (up-sampling) CIC, >>in which case the math is a little bit different, and as a result there >>are differences in how pruning can be applied. > > > I'm the OP. That article says the LSBs can be trimmed in the decimating > case, right? > > In the comb section, and in certain cases on the last integrator sections at the price of increased noise. The variable R CIC can still drop LSBs between the integrator and comb sections by adding a shifter controlled by the decimation ratio between the stages so that you always keep the N most significant bits for that decimation ratio.Article: 121192
On Jun 27, 12:34 pm, gamer <csan...@gmail.com> wrote: > My goal is to implement a bit-error counter targeting 1GHz. The > datawidth is parametrizable. I started off this way, > > Verilog code: > ---------- > assign mismatch[datawidth-1:0] = input_data ^ expected_data; > assign matched = ~( | mismatch); // reduction NOR > > always @(posedge clk or posedge reset) begin > if (reset) > error_count = 0; > else if (~matched) > for (i=0; i<datawidth; i=i+1) > error_count = error_count + mismatch[i]; > end > ---------/////////---------------------- > The above meets timing for small datawidths (like 8-bits) and starts > failing to meet timing once the datawidth gets larger. I will be glad > for suggestions of alternate ways to implement this bit-error counter. > In practice our datawidths could go upto 256 bits. I know no verilog and am not even a C programmer, but ISTM that the summation could be highly parallel by using a tree of adders (perhaps using carry save to further accelerate the summation). Consider it like computing the population count followed by an ordinary addition: one can add together the even and odd mismatch bits in parallel, then add pairs of these sums, etc., finally adding the sum to error_count. (BTW, if I understand correctly one should not need the "reduction NOR" and the "if (~matched)" since if the popcount is zero, adding it to error_count would effectively be a no-op, assuming worst-case speed is the only consideration. As Gunther Jehle pointed out pipelining could provide higher throughput.) Paul A. Clayton just a technophileArticle: 121193
Frank Buss wrote: > Petter Gustad wrote: > > >>I once implemented a microcode assembler generator in Common Lisp. The >>specification for the mnemonics and arguments were written in Verilog >>(as `define statements). The program would read this specification and >>generate an assembler on the fly and then assemble the >>microprogram. > > > This sounds like a good idea for more complex designs, but I've simplified > my design again, now the whole VHDL CPU core is 173 line, including > comments, for which a generator would be overkill: > > http://www.frank-buss.de/forth/cpu1/ Impressive. > While developing the CPU, I implemented it in VHDL, first. Then I ported > the VHDL source to an emulator, and I tested it with an assembler, both > written in Forth. With the emulator it was easy to find some bugs, which > changed the VHDL source, too. Now it is a nice little CPU core, not very > fast (it needs 4-6 clock cycles per instruction), but small (423 LEs with > an Altera Cyclone I device, about 7% device utilisation). With a simple core, that is not clock constrained (ie spare cycles at the core), how feasible is it to time-share that core, with two code/data streams, so effectively you see two independant 'multi-processor' cores ? > > The next step is a Forth cross-compiler. This should be easy, because > basicly a colon definition needs only to define a constant with the highest > bit set to 1 for the address (because then this will be interpreted as a > call in other words by the CPU) and the content will be simply storing the > value of constants to memory. A bit more tricky will be loops and if/then. Not sure if I have mentioned IEC 61131 Instruction List pgm before, but this looks fairly close to that. Some quick reading on IL is http://en.wikipedia.org/wiki/Instruction_list http://www.61131.com/il.htm http://www.cse.unsw.edu.au/~rhuuck/sfedl04huuck.pdf http://www.eod.gvsu.edu/~jackh/books/plcs/chapters/plc_il.pdf I'd be interested in any comments you have, on doing an IL version of your FPGA.Forth ? I'd guess one would make MUL.DIV optional, and constrain the data types to shrink the core. -jgArticle: 121194
I upgraded my Modelsim XE-III 6.2c starter edition to Modelsm XE-III 6.2g starter edition. Before isntalling the new software, I uninstalled 6.2c (from Control Panel), and then I deleted the \modelsim_xe_starter directory on my hard-drive. After the upgrade, I recycled the license.dat file from the old modelsim starter edition. (The license checker says it's valid.) I tried running some Systemverilog testbenches I had... all of them produce the same fatal error. I can compile the code without problem. But when I try to start the simulation (using the 'vsim' command from the Modelsim command-line), I get the following error message: \modelsiim_xe_starter\win32xeoem/../sv_std is not compiled with XE simulator. My Systemverilog testbenches have a combination of Verilog-2001 and Systemverilog modules, but I tried a simple testcase with just a single Systemverilog module -- same problem. This was just a simple .sv file with an interface declaration (but no 'advanced' features that require the Questa license.) I also compiled a simple (single-file) VHDL testbench and (single-file) Verilog-2001 testbench. Both compiled and simulated just fine. i was going to suggest buying a few XE-III (full) licenses, but that was contingent upon, apparently, an undocumented/unofficial support for Systemverilog. Now, I'll probably suggest getting (Mentor) Modelsim-PE. Anyway, Modelsim XE-III 6.2c starter-edition ran Systemverilog simulations just fine. So did Xilinx remove this feature from XE-III 6.2g? Nowhere in Xilinx's online documentation, does Xilinx claim to support Systemverilog. But I'd like to get a definitive/official answer.Article: 121195
"Rich Grise" <rich@example.net> wrote in message news:pan.2007.06.27.21.55.47.193677@example.net... > On Wed, 27 Jun 2007 20:51:42 +0100, Steve at fivetrees wrote: >> "Rich Grise" <rich@example.net> wrote in message > ... >>> use ordinary ribbon cable but with twice as many leads as signals, >>> and >>> make every other line ground. >>> >>> I've made this work with 3 feet (~1m) of ribbon cable, but at fairly >>> low bus speeds. >> >> Further to earlier response: re-reading this carefully, I'd agree if >> we >> were talking about normal (TTL-esque) digital signals. But with LVDS, >> it >> *is* a differential current loop. A twisted pair is ideal, otherwise >> I'd >> put the two conductors side by side in a ribbon with a guard ground >> either side. >> >> YMMV ;) > > http://www.belden.com/pdfs/03Belden_Master_Catalog/07Flat_Cable/07FlatCable.pdf > page 9. :-) Oooh. *Great* timing. I was just looking for some twisted-pair ribbon cable blurb... ta! Steve http://www.fivetrees.com From rich@example.net Wed Jun 27 17:27:48 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!wns13feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc07.POSTED!dd653b87!not-for-mail From: Rich Grise <rich@example.net> Subject: Re: Bidirectional LVDS User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.06.28.00.28.05.336569@example.net> Newsgroups: sci.electronics.design,comp.arch.embedded,comp.arch.fpga References: <1182958775.879163.15750@a26g2000pre.googlegroups.com> <1182960585.995282.256300@k29g2000hsd.googlegroups.com> <1182966001.290721.158570@d30g2000prg.googlegroups.com> <pan.2007.06.27.18.27.35.295523@example.net> <f-ydnVL2gPtNIh_bnZ2dnUVZ8tChnZ2d@pipex.net> <pan.2007.06.27.21.55.47.193677@example.net> <o9udnaLLVcXdYh_bRVnytQA@pipex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 37 Date: Thu, 28 Jun 2007 00:27:48 GMT NNTP-Posting-Host: 71.103.128.31 X-Complaints-To: abuse@verizon.net X-Trace: trnddc07 1182990468 71.103.128.31 (Wed, 27 Jun 2007 20:27:48 EDT) NNTP-Posting-Date: Wed, 27 Jun 2007 20:27:48 EDT Xref: prodigy.net sci.electronics.design:820302 comp.arch.embedded:255743 comp.arch.fpga:133052 X-Received-Date: Wed, 27 Jun 2007 20:27:49 EDT (newsdbm02.news.prodigy.net) On Thu, 28 Jun 2007 01:22:21 +0100, Steve at fivetrees wrote: > "Rich Grise" <rich@example.net> wrote in message > news:pan.2007.06.27.21.55.47.193677@example.net... >> On Wed, 27 Jun 2007 20:51:42 +0100, Steve at fivetrees wrote: >>> "Rich Grise" <rich@example.net> wrote in message >> ... >>>> use ordinary ribbon cable but with twice as many leads as signals, >>>> and >>>> make every other line ground. >>>> >>>> I've made this work with 3 feet (~1m) of ribbon cable, but at fairly >>>> low bus speeds. >>> >>> Further to earlier response: re-reading this carefully, I'd agree if >>> we >>> were talking about normal (TTL-esque) digital signals. But with LVDS, >>> it >>> *is* a differential current loop. A twisted pair is ideal, otherwise >>> I'd >>> put the two conductors side by side in a ribbon with a guard ground >>> either side. >>> >>> YMMV ;) >> >> http://www.belden.com/pdfs/03Belden_Master_Catalog/07Flat_Cable/07FlatCable.pdf >> page 9. :-) > > Oooh. *Great* timing. I was just looking for some twisted-pair ribbon > cable blurb... ta! Thanks! :-) Sometimes I'm kinda psycho^Hic. ;-) Cheers! Rich From invalid@dont.spam Wed Jun 27 18:00:24 2007 Path: newsdbm02.news.prodigy.net!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!nx02.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny09.POSTED!933f7776!not-for-mail From: Phil Hays <invalid@dont.spam> Subject: Re: Xilinx ISE 9.1 - Version Control - VSS User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.06.28.01.00.23.813282@dont.spam> Newsgroups: comp.arch.fpga References: <1182880087_3275@sp12lax.superfeed.net> <u4pkt4w4r.fsf@trw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 43 Date: Thu, 28 Jun 2007 01:00:24 GMT NNTP-Posting-Host: 71.112.113.242 X-Complaints-To: abuse@verizon.net X-Trace: trndny09 1182992424 71.112.113.242 (Wed, 27 Jun 2007 21:00:24 EDT) NNTP-Posting-Date: Wed, 27 Jun 2007 21:00:24 EDT Xref: prodigy.net comp.arch.fpga:133053 X-Received-Date: Wed, 27 Jun 2007 21:00:25 EDT (newsdbm02.news.prodigy.net) Martin Thompson wrote: > "Jeremy" writes: >> ... software version control applications to manage ISE projects? More >> specifically what files are required to be maintained to keep a project >> intact, and which files can be regenerated through Synthesis and Place >> and Route? The best way I know of to verify that you have all required source files is to checkout the project to a new directory and do a build. Ideal case would be on a different computer. Good practice is to use relative paths for almost everything and to keep the sources in a different tree than the products. > To regenerate, you should just need your HDL source, ISE project file > and your UCF file. And if you use Coregen, I guess that'll have stuff > that needs saving, but I try and avoid that! There are disadvantages with putting a .ise file into source control. I recommend a Tcl build script. That gives the advantages of scripting and allows use of the GUI as well. Batch scripts and makefiles are also reasonable alternatives, however they don't allow usage of the GUI, and For Coregen, put the .xco file into source control, and regenerate with something like this in a batch script: cd ../corebuild coregen -b ../source/cores/corename.xco (slashes the other way "\" for Windows) Or in Tcl, add the .xco to the project "xfile add ../src/corename.xco", or if doing Tcl with EDIF flow, add "exec coregen -b ..." statements to the Tcl script to regenerate the cores before running the synthesis tool. -- Phil Hays (Speaking for myself)Article: 121196
On 6 27 , 7 35 , Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 27 Jun 2007 00:21:22 -0700, Perry <lipeng....@gmail.com> wrote: > >The device is v4fx60-ES. EDK and ISE versions are 9.1.02 and 9.1.03 > >seprately. > >The error message apears as follows: > ... > >DeleteInterpProc called with active evals > > >This application has requested the Runtime to terminate it in an > >unusual way > >Please contact the application's support team for more information. > > It's a new one on me. > > But often when PAR crashes for no good reason, re-running with a > different cost table seed (-t 3 for example) gets past the problem. > > - Brian I have tried with the option "-t 2", "-t 3", "-t 4", however, they didn't help. Maybe I have to contact with Xilinx support.Article: 121197
I have a specific application where the FPGA needs to generate SPI bus like interface to a device but at different electrical voltage. SPI is a three wire serial bus interface I will be running at relatively slow speed of about 20MHz. The FPGA will drive out serial data out and serial clock out to the target device using lvcmos25 pudhpull driver and will be receiving serial data in. The problem is that the traget device will have its vcc at 1.2V and and its Vee at -1.3V. As per my understanding FPGA can not drive out a waveform with 1.2v to -1.3V swing. How to do the voltage translatin without affecting the signal integrity? Any help will be greatly appreciated. Albert.Article: 121198
Albert Nguyen wrote: > I have a specific application where the FPGA needs to generate SPI bus like interface to a device but at different electrical voltage. SPI is a three wire serial bus interface I will be running at relatively slow speed of about 20MHz. The FPGA will drive out serial data out and serial clock out to the target device using lvcmos25 pudhpull driver and will be receiving serial data in. > > The problem is that the traget device will have its vcc at 1.2V and and its Vee at -1.3V. As per my understanding FPGA can not drive out a waveform with 1.2v to -1.3V swing. How to do the voltage translatin without affecting the signal integrity? > > Any help will be greatly appreciated. > > Albert. Wow, that is one strange setup. What exists now, are Dual Vcc translators, but with your setup, probably the best device is something like this 90MBd isolator from ADI & -1.3V of gnd skew is nothing to this device :) http://www.analog.com/en/prod/0,2877,ADuM1401,00.html -jgArticle: 121199
Albert Nguyen wrote: > I have a specific application where the FPGA needs to generate SPI bus like interface to a device but at different electrical voltage. SPI is a three wire serial bus interface I will be running at relatively slow speed of about 20MHz. The FPGA will drive out serial data out and serial clock out to the target device using lvcmos25 pudhpull driver and will be receiving serial data in. > > The problem is that the traget device will have its vcc at 1.2V and and its Vee at -1.3V. As per my understanding FPGA can not drive out a waveform with 1.2v to -1.3V swing. How to do the voltage translatin without affecting the signal integrity? > > Any help will be greatly appreciated. > > Albert. Often this kind of setup can be achieved by simply shifting your reference. If the "internal" circuitry can be changes to a 2.5V supply between -1.2V and +1.3V with no other ground-based reference, it's just a mental shift to get the right logic levels to/from the same places. If you have an external interface that's ground referenced in addition to your "split" supply, the technique won't work and level shifters will be needed. Can you get by without ground-referenced I/O?
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