>was just thinking of extending SPI like comms using cheapest
>and ready made cabling
>
>so one pair in each direction only. was hoping to get 50mbit/s?

How far do you want to go?

Ethernet gets a gigabit in each direction over 4 pairs.  That
takes a lot of DSP magic and 3 level signaling.  Part of the
complication is to reduce EMI.

Ethernet uses transformers rather than capacitors.  I'm not sure
why.

You should also consider USB.

If you are using caps (or transformers) you have to do something
to make sure there are no long strings of 0s or 1.  Manchester
encoding does that at the cost of 2x in bandwidth.  (which may
not be a problem for short distances)  4b5b, 8b/10b type encoders
get back most of the bandwidth at the cost of some complexity
at each end.  Manchester is trivial to encode and pretty easy
to decode with a small state machine if you have a 8x clock
at the receiver.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

In comp.arch.fpga,
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote:
> On Mar 12, 10:20&#4294967295;pm, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid>
> wrote:
>> In comp.arch.fpga,
>>
>> Antti.Luk...@googlemail.com <Antti.Luk...@googlemail.com> wrote:
>>
>> > and.. i do not like any wires direct to FPGA or MCU either (going off
>> > board/cable),
>> > have seen a Atmel to bulk erase itself because the reset line was
>> > in 2 meter long cable parallel to wire carrying 12V (reed relay
>> > switched)
>> > (well Atmel claimed such bulk erase is impossible...
>> > but it happened twice and second time i had another
>> > guy to witness it, so i wasnt seeing ghosts)
>>
>> A little off-topic perhaps, but now i'm curious. What atmel chip did
>> you experience this erase with? We have just experienced a few
>> spontanious erases (over a couple of months) of the first sector of an
>> atmel dataflash on one of our boards. Another board in the same system
>> uses a dataflash for MCU code and one for FPGA configuration and we have
>> not had trouble with those.
>>
>> --
>> Stef &#4294967295; &#4294967295;(remove caps, dashes and .invalid from e-mail address to reply by mail)
>>
>> New York's got the ways and means;
>> Just won't let you be.
>> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; -- The Grateful Dead
>
>
> it was the VERY first samples of ATmega32
>
> those samples had m32 written with pencil on top
>
> no i am lying, it was atmega163 and we tried to program those m32
>
> the erasure did erase ALL memory, application sector and boot sector
> at same time, and there is no IAP command todo that.. so it should
> never happen

OK, thanks for the info. No obvious relation to our problem, we keep
searching.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

A programming language is low level when its programs require attention
to the irrelevant.

On Mar 12, 10:20=A0pm, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid>
wrote:
> In comp.arch.fpga,
>
> Antti.Luk...@googlemail.com <Antti.Luk...@googlemail.com> wrote:
>
> > and.. i do not like any wires direct to FPGA or MCU either (going off
> > board/cable),
> > have seen a Atmel to bulk erase itself because the reset line was
> > in 2 meter long cable parallel to wire carrying 12V (reed relay
> > switched)
> > (well Atmel claimed such bulk erase is impossible...
> > but it happened twice and second time i had another
> > guy to witness it, so i wasnt seeing ghosts)
>
> A little off-topic perhaps, but now i'm curious. What atmel chip did
> you experience this erase with? We have just experienced a few
> spontanious erases (over a couple of months) of the first sector of an
> atmel dataflash on one of our boards. Another board in the same system
> uses a dataflash for MCU code and one for FPGA configuration and we have
> not had trouble with those.
>
> --
> Stef =A0 =A0(remove caps, dashes and .invalid from e-mail address to repl=
y by mail)
>
> New York's got the ways and means;
> Just won't let you be.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- The Grateful Dead


it was the VERY first samples of ATmega32

those samples had m32 written with pencil on top

no i am lying, it was atmega163 and we tried to program those m32

the erasure did erase ALL memory, application sector and boot sector
at same time, and there is no IAP command todo that.. so it should
never happen

Antti

In comp.arch.fpga,
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote:
>
> and.. i do not like any wires direct to FPGA or MCU either (going off
> board/cable),
> have seen a Atmel to bulk erase itself because the reset line was
> in 2 meter long cable parallel to wire carrying 12V (reed relay
> switched)
> (well Atmel claimed such bulk erase is impossible...
> but it happened twice and second time i had another
> guy to witness it, so i wasnt seeing ghosts)

A little off-topic perhaps, but now i'm curious. What atmel chip did
you experience this erase with? We have just experienced a few
spontanious erases (over a couple of months) of the first sector of an
atmel dataflash on one of our boards. Another board in the same system
uses a dataflash for MCU code and one for FPGA configuration and we have
not had trouble with those.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

New York's got the ways and means;
Just won't let you be.
		-- The Grateful Dead

On Mar 12, 7:09=A0pm, newsgr...@johnhandwork.com wrote:
> On Mar 11, 3:35=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > if i think of it, it should be doable?
>
> > but i do not recall any projects that would use such transmit method
>
> > normal FPGA LVDS are fast enough that it would be possible just
> > capacitive decoupling
> > sure some encoding should be applied but that shouldnt also be a
> > problem
>
> > Antti
>
> I'm curious why you're interested in capacitive coupling. =A0And - if
> you're looking at distant devices with grounds that can be a few volts
> off from each other - what data rates are you targeting? =A0I'm thinking
> it might be reasonable to use ethernet magnetics to get rid of the
> bias problem yet still keep your data rates reasonable. =A0The Cat5
> system I did in a Spartan3e was fed (eventually) by the same power
> supply so isolation wasn't an issue for me. =A0I designed for 600 Mb/s
> per channel but scaled back to about 400 Mb/s in the final design.
>
> - John_H

curiuos?

was just thinking of extending SPI like comms using cheapest
and ready made cabling

so one pair in each direction only. was hoping to get 50mbit/s?

eSata uses capacitive decoupling, so i do not see big issues
for cap decoupled LVDS, but yes special IC maybe more robust.

and.. i do not like any wires direct to FPGA or MCU either (going off
board/cable),
have seen a Atmel to bulk erase itself because the reset line was
in 2 meter long cable parallel to wire carrying 12V (reed relay
switched)
(well Atmel claimed such bulk erase is impossible...
but it happened twice and second time i had another
guy to witness it, so i wasnt seeing ghosts)

so i would normally design some buffer or at least current limiting
resistor for any wires going off board

Antti

On Mar 11, 3:35=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> if i think of it, it should be doable?
>
> but i do not recall any projects that would use such transmit method
>
> normal FPGA LVDS are fast enough that it would be possible just
> capacitive decoupling
> sure some encoding should be applied but that shouldnt also be a
> problem
>
> Antti

I'm curious why you're interested in capacitive coupling.  And - if
you're looking at distant devices with grounds that can be a few volts
off from each other - what data rates are you targeting?  I'm thinking
it might be reasonable to use ethernet magnetics to get rid of the
bias problem yet still keep your data rates reasonable.  The Cat5
system I did in a Spartan3e was fed (eventually) by the same power
supply so isolation wasn't an issue for me.  I designed for 600 Mb/s
per channel but scaled back to about 400 Mb/s in the final design.

- John_H

Symon wrote:

> "doug" <xx@xx.com> wrote in message 
> news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet...
> 
>>
>>Antti wrote:
>>
>>
>>>if i think of it, it should be doable?
>>>
>>>but i do not recall any projects that would use such transmit method
>>>
>>>normal FPGA LVDS are fast enough that it would be possible just
>>>capacitive decoupling
>>>sure some encoding should be applied but that shouldnt also be a
>>>problem
>>>
>>>Antti
>>
>>Yes it is possible, no, it is not a good idea. Running cables
>>through the world always get you transients. It is much better
>>to put a hardened lvds driver onto external cables since they
>>are easier to replace than fpgas. We have done this both
>>ways.
> 
> 
> Doug,
> I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, and 
> judicious routing beats 'hardened lvds drivers' every time. On cost, 
> reliability, performance, manufacturability and board space.
> I would like to take this opportunity revise my original post, and recommend 
> 8B10B coding to get rid of DC bias problem. 8B10B is out of patent now...
> HTH., Syms. 

It kind of depends on how long you want them to work. One good chip
giving several reliable lines takes no more spaces than your set of
protectors.  It also depends on how hard it is to get to the circuit
to fix it. If it is on your bench, that is easy. If it is thousands
of miles away well inside other assemblies, that is another issue.
I would prefer to err on the side of conservatism.  But I am not
in a situation where the last penny counts.


> 
> 

On Thu, 12 Mar 2009 00:39:32 -0000, "Symon" <symon_brewer@hotmail.com> wrote:

>
>"doug" <xx@xx.com> wrote in message 
>news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet...
>>
>>
>> Antti wrote:
>>
>>> if i think of it, it should be doable?
>>>
>>> but i do not recall any projects that would use such transmit method
>>>
>>> normal FPGA LVDS are fast enough that it would be possible just
>>> capacitive decoupling
>>> sure some encoding should be applied but that shouldnt also be a
>>> problem
>>>
>>> Antti
>>
>> Yes it is possible, no, it is not a good idea. Running cables
>> through the world always get you transients. It is much better
>> to put a hardened lvds driver onto external cables since they
>> are easier to replace than fpgas. We have done this both
>> ways.
>
>Doug,
>I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, and 
>judicious routing beats 'hardened lvds drivers' every time. On cost, 
>reliability, performance, manufacturability and board space.
>I would like to take this opportunity revise my original post, and recommend 
>8B10B coding to get rid of DC bias problem. 8B10B is out of patent now...
>HTH., Syms. 

If the patent was ever valid. The BBC were using a form of 8B10B coding
(not,AFAIK, the exact same form as was patented but one with a delightfully
simple implementation) for digital video transmission in early 1982; somewhat
ahead of the priority date on the most-often quoted patent (though there may be
other patents)

- Brian

On Mar 12, 2:39=A0am, "Symon" <symon_bre...@hotmail.com> wrote:
> "doug" <x...@xx.com> wrote in message
>
> news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet...
>
>
>
>
>
> > Antti wrote:
>
> >> if i think of it, it should be doable?
>
> >> but i do not recall any projects that would use such transmit method
>
> >> normal FPGA LVDS are fast enough that it would be possible just
> >> capacitive decoupling
> >> sure some encoding should be applied but that shouldnt also be a
> >> problem
>
> >> Antti
>
> > Yes it is possible, no, it is not a good idea. Running cables
> > through the world always get you transients. It is much better
> > to put a hardened lvds driver onto external cables since they
> > are easier to replace than fpgas. We have done this both
> > ways.
>
> Doug,
> I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, a=
nd
> judicious routing beats 'hardened lvds drivers' every time. On cost,
> reliability, performance, manufacturability and board space.
> I would like to take this opportunity revise my original post, and recomm=
end
> 8B10B coding to get rid of DC bias problem. 8B10B is out of patent now...
> HTH., Syms.

Hi thanks for all the answers, i also think it should be doable
without external drivers

Xilinx MGTs are qualified for PCIe and SATA, so I assume they might be
used for
PCIe over cable and eSATA, and in such cases there would be same
situation
as using ac decoupled CAT5 with LVDS I/Os,

transient protection is of course good thing for any external cabling!

Antti

"doug" <xx@xx.com> wrote in message 
news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet...
>
>
> Antti wrote:
>
>> if i think of it, it should be doable?
>>
>> but i do not recall any projects that would use such transmit method
>>
>> normal FPGA LVDS are fast enough that it would be possible just
>> capacitive decoupling
>> sure some encoding should be applied but that shouldnt also be a
>> problem
>>
>> Antti
>
> Yes it is possible, no, it is not a good idea. Running cables
> through the world always get you transients. It is much better
> to put a hardened lvds driver onto external cables since they
> are easier to replace than fpgas. We have done this both
> ways.

Doug,
I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, and 
judicious routing beats 'hardened lvds drivers' every time. On cost, 
reliability, performance, manufacturability and board space.
I would like to take this opportunity revise my original post, and recommend 
8B10B coding to get rid of DC bias problem. 8B10B is out of patent now...
HTH., Syms.