Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 121175

Article: 121175
Subject: Re: CameraLink to Hotlink-II video converter
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Wed, 27 Jun 2007 16:49:08 +0100
Links: << >>  << T >>  << A >>
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.html

Article: 121176
Subject: Re: corgen cic = terrible efficiency?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 27 Jun 2007 11:52:22 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Bidirectional LVDS
From: Andy <jonesandy@comcast.net>
Date: Wed, 27 Jun 2007 09:09:45 -0700
Links: << >>  << T >>  << A >>
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


Article: 121178
Subject: Re: corgen cic = terrible efficiency?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 27 Jun 2007 12:13:15 -0400
Links: << >>  << T >>  << A >>
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
Subject: Bit error counter - how to make it faster
From: gamer <csanjay@gmail.com>
Date: Wed, 27 Jun 2007 09:34:06 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit error counter - how to make it faster
From: "GŁnther Jehle" <jehle@gmx.at>
Date: Wed, 27 Jun 2007 18:46:13 +0200
Links: << >>  << T >>  << A >>
> 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 Jehle 



Article: 121181
Subject: Re: Bidirectional LVDS
From: Richard Henry <pomerado@hotmail.com>
Date: Wed, 27 Jun 2007 10:40:01 -0700
Links: << >>  << T >>  << A >>
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!
Rich


Article: 121182
Subject: Re: corgen cic = terrible efficiency?
From: "cpope" <cepope@nc.rr.com>
Date: Wed, 27 Jun 2007 15:11:34 -0400
Links: << >>  << T >>  << A >>


>
> 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



Article: 121183
Subject: Re: corgen cic = terrible efficiency?
From: "cpope" <cepope@nc.rr.com>
Date: Wed, 27 Jun 2007 15:19:52 -0400
Links: << >>  << T >>  << A >>

"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
Subject: Re: corgen cic = terrible efficiency?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 27 Jun 2007 15:31:09 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Bidirectional LVDS
From: "Steve at fivetrees" <steve@NOSPAMTAfivetrees.com>
Date: Wed, 27 Jun 2007 20:35:44 +0100
Links: << >>  << T >>  << A >>
"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.com 



Article: 121186
Subject: Re: Bidirectional LVDS
From: Richard Henry <pomerado@hotmail.com>
Date: Wed, 27 Jun 2007 12:43:21 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Bidirectional LVDS
From: "Steve at fivetrees" <steve@NOSPAMTAfivetrees.com>
Date: Wed, 27 Jun 2007 20:51:42 +0100
Links: << >>  << T >>  << A >>
"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.com 



Article: 121188
Subject: Re: corgen cic = terrible efficiency?
From: "cpope" <cepope@nc.rr.com>
Date: Wed, 27 Jun 2007 15:54:12 -0400
Links: << >>  << T >>  << A >>

"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
Subject: Re: Bidirectional LVDS
From: Gabor <gabor@alacron.com>
Date: Wed, 27 Jun 2007 13:04:14 -0700
Links: << >>  << T >>  << A >>
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,
Gabor


Article: 121190
Subject: Re: Bidirectional LVDS
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 27 Jun 2007 20:06:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
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!
Rich


Article: 121191
Subject: Re: corgen cic = terrible efficiency?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 27 Jun 2007 18:13:49 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit error counter - how to make it faster
From: "Paul A. Clayton" <paaronclayton@earthlink.net>
Date: Wed, 27 Jun 2007 15:48:00 -0700
Links: << >>  << T >>  << A >>
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 technophile


Article: 121193
Subject: Re: another Forth CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 28 Jun 2007 11:17:01 +1200
Links: << >>  << T >>  << A >>
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.

-jg



Article: 121194
Subject: Xilinx Modelsim XE-III 6.2g no more Systemverilog support?
From: "Xilinx User" <anonymous@net.com>
Date: Wed, 27 Jun 2007 17:11:55 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Bidirectional LVDS
From: "Steve at fivetrees" <steve@NOSPAMTAfivetrees.com>
Date: Thu, 28 Jun 2007 01:22:21 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: A strange error during PAR process in EDK, could anyone in xilinx help me?
From: Perry <lipeng.net@gmail.com>
Date: Wed, 27 Jun 2007 18:58:32 -0700
Links: << >>  << T >>  << A >>
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
Subject: Xilinx FPGA to interface to special I/O
From: "Albert Nguyen" <>
Date: Wed, 27 Jun 2007 19:35:09 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx FPGA to interface to special I/O
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 28 Jun 2007 15:41:41 +1200
Links: << >>  << T >>  << A >>

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

-jg


Article: 121199
Subject: Re: Xilinx FPGA to interface to special I/O
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 28 Jun 2007 04:09:12 GMT
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search