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 91200

Article: 91200
Subject: Thank-you Xilinx!
From: Eli Hughes <emh203@psu.edu>
Date: Tue, 01 Nov 2005 09:40:47 -0500
Links: << >>  << T >>  << A >>
The Platform Flash configuration devices are finally available on the 
online store!




-Eli

Article: 91201
Subject: Re: Thank-you Xilinx!
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 1 Nov 2005 16:06:37 +0100
Links: << >>  << T >>  << A >>
"Eli Hughes" <emh203@psu.edu> schrieb im Newsbeitrag 
news:dk7upg$1bme$1@f04n12.cac.psu.edu...
> The Platform Flash configuration devices are finally available on the 
> online store!
>
> -Eli

My vote for the THANK YOU as well.

There are more device options than at digikey and 1 off pricing is lower 
than digikey 100 price break :)

anti 



Article: 91202
Subject: Re: Quartus II Simulation
From: "morpheus" <saurster@gmail.com>
Date: 1 Nov 2005 07:15:04 -0800
Links: << >>  << T >>  << A >>
Thanks...it solved my issue


Article: 91203
Subject: Xilinx V2P Speed Grades
From: "Simon Heinzle" <sheinzle@student.ethz.ch>
Date: Tue, 1 Nov 2005 16:15:28 +0100
Links: << >>  << T >>  << A >>
Hi there,

Has anyone of you experience with the speed gain on a Virtex2Pro when going 
from -5 to -6?

I mean, the difference in RocketIO or PowerPC is obvious (at least in the 
datasheet), but what about the logic and Block-RAM? In what order of ns is 
the difference?

Thanks for your answers,
Simon 



Article: 91204
Subject: Virtex4 temperature-sensing feature... does it work?
From: "I. Ulises Hernandez" <delete@e-vhdl.com>
Date: Tue, 1 Nov 2005 15:59:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello guys,

Has anyone used the DXP and DXN pins in Virtex-4 yet? If so and if the 
results were all right, what external sensor did you use...?

Thanks in advance,

-- 
Ignacio Ulises Hernandez
" I'm not normally a praying man, but if you're up there, please save me, 
Superman!" - Homer Simpson ;O) 



Article: 91205
Subject: Re: Virtex4 temperature-sensing feature... does it work?
From: "Chris" <cbernard353@gmail.com>
Date: 1 Nov 2005 08:14:35 -0800
Links: << >>  << T >>  << A >>
We are using it on the 4VFX-20 's without any problems.


Article: 91206
Subject: Re: Xilinx ML403 Error 1 LED
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Tue, 01 Nov 2005 08:18:06 -0800
Links: << >>  << T >>  << A >>
Try to power cycle the board a few times and see if it eventually starts up.

- Peter


kdfake@spam.com wrote:
> Hi
> 
> I just got two ML403 boards.
> 
> 2nd board when turned on with the cf card in the Error 1 LED is 
> displayed. There is no lcd output and VGA output seems scrambled.
> 
> The 1st board works as it should as described in getting started 
> guide.
> 
> Does this mean that this 2nd board is bad?
> 
> regards.


Article: 91207
Subject: Re: Virtex4 temperature-sensing feature... does it work?
From: Anthony Collins <acollins@xilinx.com>
Date: Tue, 01 Nov 2005 16:39:09 +0000
Links: << >>  << T >>  << A >>
Hi there,

 I'm actually using the thermal diode right now with the MAX6642 temp 
sensor IC. External diode sensor measurement range of this IC is 0C to 
150C. So far I've looked at approx 20 V-4 devices from a number of 
different lots. This external IC is accurate to ~ +/- 2C from 0C to 
105C. I'm using a calibrated temp forcing system from Temptronic (+/- 0.5C).

Regards,
Anthony

I. Ulises Hernandez wrote:

>Hello guys,
>
>Has anyone used the DXP and DXN pins in Virtex-4 yet? If so and if the 
>results were all right, what external sensor did you use...?
>
>Thanks in advance,
>
>  
>

Article: 91208
Subject: Re: Virtex4 temperature-sensing feature... does it work?
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 1 Nov 2005 08:50:54 -0800
Links: << >>  << T >>  << A >>
"I. Ulises Hernandez" <delete@e-vhdl.com> wrote in message 
news:dk83ch$eki$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
> Hello guys,
>
> Has anyone used the DXP and DXN pins in Virtex-4 yet? If so and if the 
> results were all right, what external sensor did you use...?
>
Works just fine in V2PRO. I use a MAX6695.
http://pdfserv.maxim-ic.com/en/ds/MAX6695-MAX6696.pdf
Cheers, Syms. 



Article: 91209
Subject: can ethereal detect an ethernet packet for which crc is wrong
From: "ashwin" <achiluka@gmail.com>
Date: 1 Nov 2005 09:24:37 -0800
Links: << >>  << T >>  << A >>
Hello everyone,

   I am sending an ethernet  packet(64 bytes) from the fpga to the PC
in order to test the ETHERNET PHY chip onboard.
   The interface from the fpga to the ethernet PHY for the data is 4
bits.

 My PC mac address is 00-01-80-3F-6C-E6

a)So should i send the LSBs first like
in this order, 6,E,C,6,F,3,0,8,1,0,0,0 or the MSBs first


b) I have installed ethereal software on my PC and i am unable to
detect the ethernet  packet in it.
     1) I am pretty sure my CRC is wrong for whatever data i have, so
can ethereal still detect even when crc is wrong?

     2)i used the scope , and i am able to see some data going from
fpga to the ethernet PHY. But the nothing gets detected in the PC. What
could be the reason?

      One of the member in this group recommended not to see the data
coming out of the ETHERNET  phy , since its at 125 mhz and its not
being detect correctly using a scope.


3)Can anyone compute the crc check for whole ethernet packet for which
my destination addres is as above? Data doesnt matter,it can be any
value.?Source address also doesnt matter, since it is fpga mac address.

4) Can anyone guide me on hardware implementation of crc using
 vhdl


Article: 91210
Subject: Lead To Lead Free ROHS help?
From: "dolbowent" <dolbowent@hotmail.com>
Date: 1 Nov 2005 09:28:57 -0800
Links: << >>  << T >>  << A >>
If you need some ROHS help I work as a component engineer out in San
Diego county California. I have a service that helps you convert your
BOM, Soldering profile, and rework training to ROHS compliant. We are
engineers who have gotten together to start this new service. If you
need we can telecommute to help you get started in ROHS.

Check us out at "A total green planet solution"  www.atotalgps.com

Thank you

Mike Dolbow
Component Engineering
A total green planet solution
www.atotalgps.com


Article: 91211
Subject: Re: Sigma-Delta A/D
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 1 Nov 2005 09:42:49 -0800
Links: << >>  << T >>  << A >>
Marco wrote:
> "John Monro" <johnmonro@optusnet.com.au> wrote in message
> news:43671713$0$25854$afc38c87@news.optusnet.com.au...
> > Marco,
> > Unfortunately, the DAC output voltage needs to be very well defined and
> > noise-free, even though it is derived from a one-bit value, and no digital
> > output is able to achieve this.
> >
> > I don't think there is any chance of realising CD-quality (16-bit) audio
> > by trying to make a digital chip perform any analog functions at all.
> > Digital noise on the ground and supply lines for example make it a
> > hopeless job at the quality level you want.
> >
> > If it is essential to use a single chip, you could investigate the Lattice
> > Semiconductor programmable combined analog/digital chips.
> >
> >
> > Regards,
> > John
>
> I understand... so a way to do it could be buying a analog devices ad7400
> (isolated sigma delta modulator (1 bit out)) and building the digital filter
> into the fpga to obtain 16 bit output data.
>
> What do you think about it?

I think you should ring up Analog Devices, TI, AKM or Cirrus and buy a
$2 ADC that'll kick the ass out of anything you can bodge up in your
FPGA.  An I2S interface is about six lines of VHDL.

-a


Article: 91212
Subject: Re: hex rep. in VHDL
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 01 Nov 2005 09:47:47 -0800
Links: << >>  << T >>  << A >>
Mark McDougall wrote:
> Mike Treseler wrote:
> 
>> I can tolerate
>>  foo(4 downto 0) <= "11111";    -- or
>>  foo(4 downto 0) <= "1" & x"F";
>> to get compile time width checking
>> on all vectors.
> 
> Warning #1034: X"1F" width 8 truncated to width 5 in assignment.

Yes.
Your example has a width mismatch.
Those above do not.
Try it and see.

         -- Mike Treseler

Article: 91213
Subject: Re: Mitrion-C
From: "Kunal" <kunal.shenoy@gmail.com>
Date: 1 Nov 2005 10:02:26 -0800
Links: << >>  << T >>  << A >>
I used CoDeveloper for a Mandelbrot image generation project and had a
pretty good experience. Support from Impulse was outstanding.
I have never used any other C-to-HDL software, so I can't compare it to
others.
CoDeveloper can't compete with HDL which is hand written, and I don't
think it claims to. Its more for a software engineer who wants to use
PPC/Microblaze/Altera uP + FPGA fabric.


Article: 91214
Subject: Re: can ethereal detect an ethernet packet for which crc is wrong
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 1 Nov 2005 10:10:57 -0800
Links: << >>  << T >>  << A >>
There are more CRCs in a ethernet packet:

1. PHY level. The very last 4 bytes. In linux ifconfig  will show you
the number of packet errors on a  NIC. Ethereal won't detect it because
the network driver throws away the packet if it's bad. Some driver
won't even generate interrupt for bad packets, in that you cannot see
the error unless you recompile the driver and enable interrupts for bad
packets.

2. CRCs in IP headers. ethereal will detect it.

Zoltan


Article: 91215
Subject: Re: can ethereal detect an ethernet packet for which crc is wrong
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 01 Nov 2005 10:43:42 -0800
Links: << >>  << T >>  << A >>
ashwin wrote:

>       One of the member in this group recommended not to see the data
> coming out of the ETHERNET  phy , since its at 125 mhz and its not
> being detect correctly using a scope.

Yes. Look on the data side, not the line side.
Scrambling will make an idle link look the
same as a busy one.

       -- Mike Treseler

Article: 91216
Subject: Re: Antti's Logic Assembler ( was Spartan-3E starter kit )
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 02 Nov 2005 07:56:40 +1300
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag 
> news:4366a1ff$1@clear.net.nz...
> 
>>Antti Lukats wrote:
>>
>><snip>
>>
>>>sneak preview: on my harddisk I have a tool I call 'Logic Assembler' it 
>>>can serve as front end for almost any FPGA/PLD for what the vendor 
>>>fitter/mapper exists.
>>
>>Hi Antti,
>> Care to post some code examples ? Output format(s) ?
>>-jg
>>
> 
> main output format is vendor specific EDIF
> 
> input formats supported for now are logic assembler text mode or xilinx ISE 
> schematics.
> also working on netlist imports from CAE tools.
> 
> below is test code that work on Atmel FPSLIC starterboard.
> the output is processed with Atmel Figaro.
> 
> ----------------------
> .vendor atmel
> .family at94k
> .library at94k
> 
> input I
> output O
> 
> input I1
> output O1
> 
> 
> ibuf I_IBUF
> obuf O_OBUF
> 
> ibuf I_IBUF1
> obuf O_OBUF1
> 
> O = O_OBUF.PAD
> I_IBUF.PAD = I
> O_OBUF.A = I_IBUF.Q
> 
> O1 = O_OBUF1.PAD
> I_IBUF1.PAD = I1
> O_OBUF1.A = I_IBUF1.Q
> ----------------------
> 
> really simple.

Very interesting, I'm always a fan of KISS.
Do you have any examples of Fields, number bases, volatile variables, 
and Macros ?  [ or am I running ahead here ? ]

Can you mix this with HDL flows ?

-jg


Article: 91217
Subject: Re: can ethereal detect an ethernet packet for which crc is wrong
From: "Gavin" <google@embisi.com>
Date: 1 Nov 2005 11:02:27 -0800
Links: << >>  << T >>  << A >>
I run tethereal for all my packet analysis. Two options to use:
tethereal -x -i eth0 (or whatever your interface is) - complete data
dump
tethereal -V -i eth0 (or ...) - protocol level dump

I believe tethereal will give you invalid FCS (CRC) packets.

A sample ethernet packet from 08:00:46:63:ca:e3 with destination
00:13:20:0a:25:db is here. The first byte on the wire is given first -
so transmit the MAC address bytes from left to right. Bits 0-3 go first
on the wire, 4-7 afterwards

0000  08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10   ..Fc....
.%...E.
0010  00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01
.t>.@.@..S...@..
0020  11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18
.+.......e.F.I..
0030  0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f
..6.......\T(..o
0040  69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9
i.p.....)..S....
0050  e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75
.F....m...c.YwJu
0060  e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb
.......:....A...
0070  13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64
.....0C..b...1.d
0080  43 9b                                             C.

It is probably best to start out broadcasting packets for your tests -
send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
Also it is worth writing ethernet rx before tx - make sure you can
receive packets with the correct FCS from the wire, and then you can
get your tx to work with your known working rx code.

Anyway, a packet to your destination address from MAC address
01:23:45:67:89:a0 with total packet length including MAC addresses and
FCS, with other content 00, is...

00 01 80 3f 6c e6 01 23
45 67 89 a0 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 75 78 03 93


Article: 91218
Subject: lenght/type not included
From: "ashwin" <achiluka@gmail.com>
Date: 1 Nov 2005 12:40:16 -0800
Links: << >>  << T >>  << A >>
Hello Gavin,
 Thanks for sending an ethernet packet which includes my destination
address.
 Does the last 4 bytes represent CRC of all the data.
 You didnt inlude the length/type, 2 bytes , which comes after source
address. I guess we need to compute the crc for that also.

Please check and advice

thanks
ashwin



Gavin wrote:
> I run tethereal for all my packet analysis. Two options to use:
> tethereal -x -i eth0 (or whatever your interface is) - complete data
> dump
> tethereal -V -i eth0 (or ...) - protocol level dump
>
> I believe tethereal will give you invalid FCS (CRC) packets.
>
> A sample ethernet packet from 08:00:46:63:ca:e3 with destination
> 00:13:20:0a:25:db is here. The first byte on the wire is given first -
> so transmit the MAC address bytes from left to right. Bits 0-3 go first
> on the wire, 4-7 afterwards
>
> 0000  08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10   ..Fc....
> .%...E.
> 0010  00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01
> .t>.@.@..S...@..
> 0020  11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18
> .+.......e.F.I..
> 0030  0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f
> ..6.......\T(..o
> 0040  69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9
> i.p.....)..S....
> 0050  e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75
> .F....m...c.YwJu
> 0060  e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb
> .......:....A...
> 0070  13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64
> .....0C..b...1.d
> 0080  43 9b                                             C.
>
> It is probably best to start out broadcasting packets for your tests -
> send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
> Also it is worth writing ethernet rx before tx - make sure you can
> receive packets with the correct FCS from the wire, and then you can
> get your tx to work with your known working rx code.
>
> Anyway, a packet to your destination address from MAC address
> 01:23:45:67:89:a0 with total packet length including MAC addresses and
> FCS, with other content 00, is...
>
> 00 01 80 3f 6c e6 01 23
> 45 67 89 a0 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 75 78 03 93


Article: 91219
Subject: Re: can ethereal detect an ethernet packet for which crc is wrong
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 01 Nov 2005 15:09:55 -0600
Links: << >>  << T >>  << A >>
>2. CRCs in IP headers. ethereal will detect it.

That's not the hardware level CRC at the end of the packet.
It's not even a CRC, just a 1's complement add.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 91220
Subject: Re: can ethereal detect an ethernet packet for which crc is wrong
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 01 Nov 2005 15:13:31 -0600
Links: << >>  << T >>  << A >>
> a)So should i send the LSBs first like

Do they still make Ethernet gear that runs on coax?  If you
can find some of that the bit order will be pretty obvious.

> 3)Can anyone compute the crc check for whole ethernet packet for which
> my destination addres is as above? Data doesnt matter,it can be any
> value.?Source address also doesnt matter, since it is fpga mac address.

Send a packet from your PC.  Grab the bits with a scope.
Then you can make your CRC agree with one that is known to work.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 91221
Subject: Re: lenght/type not included
From: "Gavin" <google@embisi.com>
Date: 1 Nov 2005 13:17:14 -0800
Links: << >>  << T >>  << A >>
Ethereal will happily receive the above packet - it will tell you all
sorts of errors about it, though... Don't worry about the length etc
until you can get a blank packet correct. If you can do that, then you
should have the FCS code all working, and you are at a different debug
level.
The last 4 bytes are FCS.


Article: 91222
Subject: Re: can ethereal detect an ethernet packet for which crc is wrong
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Wed, 02 Nov 2005 10:26:09 +1300
Links: << >>  << T >>  << A >>
Gavin wrote:
> It is probably best to start out broadcasting packets for your tests -
> send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
> Also it is worth writing ethernet rx before tx - make sure you can
> receive packets with the correct FCS from the wire, and then you can
> get your tx to work with your known working rx code.

I'd second that - the lazy way to work this out is to instrument the 
image on the rx side (ie using something like chipscope), transmit some 
packets on the network, and see if it matches what you expect.  It can 
be easy to to get caught out.  You can then write a simple state machine 
to dump the data you saw on the rx side out the tx side.

The rx side is easier to get working first, since you can:
a) Get your crc code right first by checking crcs on recieved packets 
(quite likely to be correct)
b) You can then simulate a loopback situation to check that your rx crc 
code and tx crc code match
c) It forces you to recheck your assumptions on nybble/byte ordering, 
since if what you expected was different from what you recieved from the 
packet, then you're probably wrong :)

Also, if your crc code is incorrect, it's easier if you have a 'golden' 
source, as you can then run simulations or a c program using a known 
good piece of code (from a bsd kernel or something like that) to see 
where you went wrong.  It helps to localise the error if you are using a 
  known good source.

My 2c,
Jeremy

Article: 91223
Subject: Re: ISE 8.1, EDK 8.1 any pre-release info available?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 01 Nov 2005 16:31:54 -0500
Links: << >>  << T >>  << A >>
Eric Smith wrote:

>I'm hoping for:
>
>    * supported on Red Hat Enterprise Linux 4 (vs. RHEL3)
>    * Parallel Cable 4 and Platform Cable USB support on Linux 2.6.x
>    * Parallel Cable 4 and Platform Cable USB support on 64-bit Linux
>    * ISE Simulator on Linux
>
>But I don't have any information about 8.1i, so I have no idea whether they've
>done any of that.
>
>Eric
>  
>
Gee, I'm just hoping they didn't break anything. It took 4 service packs 
to get 7.1 to a usable state.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 91224
Subject: Re: Sigma-Delta A/D
From: Ray Andraka <ray@andraka.com>
Date: Tue, 01 Nov 2005 16:49:27 -0500
Links: << >>  << T >>  << A >>
Marco wrote:

>
>I understand... so a way to do it could be buying a analog devices ad7400 
>(isolated sigma delta modulator (1 bit out)) and building the digital filter 
>into the fpga to obtain 16 bit output data.
>
>What do you think about it? 
>
>
>  
>
That works just fine, and it can be done in a small FPGA with careful 
design.  I did an 8 channel one in an XC2S15 using external DS modulators.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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