Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
The Platform Flash configuration devices are finally available on the online store! -EliArticle: 91201
"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 :) antiArticle: 91202
Thanks...it solved my issueArticle: 91203
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, SimonArticle: 91204
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
We are using it on the 4VFX-20 's without any problems.Article: 91206
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
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
"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
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: 91210If 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.comArticle: 91211
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. -aArticle: 91212
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: 91213I 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
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. ZoltanArticle: 91215
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: 91216Antti 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 ? -jgArticle: 91217
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 93Article: 91218
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 93Article: 91219
>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
> 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
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
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, JeremyArticle: 91223
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
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:
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