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
We were just sending the design to the layout guys. What's that saying? "Don't shoot the messenger!!!" Thanks for the heads up. Years ago Phillips did the same thing to me on a stepper driver. They need to forecast a little better. Now that I've been burned twice I think it's time to take them off my "favorites" list. (I think I said that last time.) I never looked into the eval board. Colin "jakab tanko" <jtanko@ics-ltd.com> wrote in message news:bk59jk$pf2$1@news.storm.ca... > I have looked at that one some time ago but there was a message on > the Philips website that the chip is going obsolete and that scared me > away... > I tried to confirm with the Philips rep. here in Ottawa,Canada but > all I got to talk to was an answering machine!. Did you manage to get an > eval board for it? > --- > jakab > "Colin Jackson" <jacksoncolin@fake_yahoo.com> wrote in message > news:1sOdnZlEhZ77j_uiU-KYuA@comcast.com... > > I'm working on a project with USB to a XILINX FPGA. > > The interface chip I'm going with is Phillips ISP-1501 > > http://www.semiconductors.philips.com/cgi-bin/pldb/pip/isp1501 > > > > Good Luck, > > Colin > > > > "jakab tanko" <jtanko@ics-ltd.com> wrote in message > > news:bk4g4g$j0f$1@news.storm.ca... > > > Hi, > > > > > > I am looking for an USB transceiver chip that can be interfaced to an > > > FPGA WITHOUT microcontroller. USB 2.0 would be ideal, 1.1 is also ok. > > > Any suggestions? > > > > > > Thanks, > > > --- > > > jakab > > > > > > > > > > > >Article: 60551
On Mon, 15 Sep 2003 22:29:18 +0000, Jan Panteltje wrote: > On a sunny day (Mon, 15 Sep 2003 14:01:17 -0500) it happened Srikanth Anumalla > <srikanth@unlserve.unl.edu> wrote in <bk523v$355$1@unlnews.unl.edu>: > >>Hi >> >>I am quite new in this field, Please excuse me if I talk something >>nonsence. I have 10 pressure sensors which measure pressure in 10 >>different points in a field. I need to aggregate all these values in >>realtime and send to a remote computer.For this, somebody suggested me >>to use fpga, I made little research and found out that we can actually >>run an some programs on fpga. I have this idea now, to build an fpga >>board which can read data from the sensor and send that data to a >>central computer in the field over a wireless network. and I will have >>an fpga at each sensor. CEntral computer will aggregate the data and >>send to a remote location via phone line etc. For this to be realized I >>have to know whether an fpga is capable of collecting date from a sensor >>and send the same data over a wireless network. Please give me pointers >>on this . Any help would be greatly appreciated. >> >>Thanks >>Srikanth >> >> > If your pressure sensors have analog output, then why use FPGA? > Use a PIC micro with build in AD and 4 channel input mux. > 3 of these or one with an external mux, use the serial port of the PIC > or make your own protocol or whatever. > 12F675 is only 8 pins DIL, has a 10 bits AD with 4 input mux, internal oscillator, > costs 2 dollars, so 4 of these set you back 8 dollars and the microchip tools are > free from www.microchip.com > Why use FPGA? The reason I went for fpga was to have wireless networking (802.11) Actually, the sensors are 3-4 miles apart, I need the data until a base station from where I will transfer the data to the internet. the base station is located in the filed and will be 1-2 miles distant from each sensor. So how do I transfer (in realtime) the data until the base station from the sensor. Is it possible with PCI micro. Please suggest me if there is a better solution other than fpga cpu for doing this (wireless networking). Thanks in advance SrikanthArticle: 60552
I talked with Phil, and he mentioned that his metastability tests that generated the figures showing some oscillation were actually done with Xilinx XC4000 devices. So I stand corrected. If this type of behavior still exists in Virtex ( and I do not have Phil's sophisticated trigger set-up ), then I might have underreported the delay by up to a factor of 2. This should not be a real problem, since we are really talking about much larger orders of magnitude, like millions and billions of years. But yes, I was wrong in claiming that CMOS latches cannot oscillate for one period... Eating humble pie, Peter Alfke =================== Ray Andraka wrote: > > Peter, > > My understanding was that those pictures were of Xilinx parts. Of course if > you sample them at a low enough rate, it looks like an unpredictable delay > even if it is not. > > Peter Alfke wrote: > > > I have a lot of respect for Phil, we are personal friends and have > > worked together for over 20 years. I think he used old TTL pictures. > > -- > --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, 1759Article: 60553
On a sunny day (Tue, 16 Sep 2003 14:57:06 +0200) it happened "Sergio Tassinari" <xszyjk@yahoo.it> wrote in <bk71aj$mm2$1@stargate1.inet.it>: >Hi all! >I'd like to buy an FPGA prototyping board and, >after some searches, I am oriented to the Digilent Digilab 2. >They sell directly, but I live in Italy, and I am a little >scared about customs and shipping fees. > >Is there anybody out there living in Europe that has bought >a board from Digilent? >How much did you pay for shipping and customs charges? > >Many thanks! > >Sergio Tassinari The digilab was 99$, the shipping was > 20, and the custom was > 20, so that made it 147 or so Euro. Not digilentic's fault, I wrote a protest letter to the customs, they referred me to the post guys, I gave up. If you have someone who visits the states regulary perhaps ask them to bring one. The board is OK, make sure you order a EUROPEAN (240 V) adapter. JPArticle: 60554
Hi. I have a wide bus between 2 virtex2 devices. This bus is HSTL type, and thus every bit has resistor to Vref. The bus has long idle times. My question is what should I drive on the bus in idle times to minimize power consumption. One possibility is to drive a fixed value, then the resistors to Vref will consume power. Another possibility is to put the driver on tristate. In this scenario I fear from: a. I am used to CMOS where it is not recommanded to put a net without a driver for too long. b. I fear that the Vref value will cause power consumption inside the receiver fpga device. What is your advice ? ThankX , NAHUMArticle: 60555
In principle is as you said, but my experience is that XST get confused pretty quickly when your design is more complicated than just having a clk signal LOCed to one IGCLK pad. So I prefer to instantiate all BUFG, IBUFG etc, to have full control. This is not usually necessary for normal I/Os (unless they are bidir, tristate, special voltage levels etc) Tullio On 15 Sep 2003, rider wrote: > I have a query regarding Xilinx FPGAs and the XST. In many documents > relating FPGA designs, there are such statements as: > > BUFG instance_name (.O (user_O), > .I (user_I)); > > My question is that do we really need to instantiate BUFG, IBUFG etc > in this manner? Isn't this automatically done by the tool(XST etc)? > Lets say i am using a clk signal in my design. I LOC this clk signal > to one of FPGAs IGCLK pad. Wont' the IBUFG primitive be used > automatically? Similarly, does the tool not automatically insert IBUF > and OBUF at the input/output signals? > > ThanksArticle: 60556
Hello, Has anyone bought anything from www.dragonsources.com? I'm having trouble finding any distributor in the US that will sell the XCS10-3PC84C (old, 5V Spartan) in less than 300 pc quantities, or for less than $42 ea. These guys claim they have them for $12 ea., but I don't know if they are for real. They are apparently in China, or thereabouts. Thanks for any experiences with them. JonArticle: 60557
you create a small flash loader that you use to program your flash, then you run your programs from flash. optionally you may copy to sram but it in your case I think it doesnt make sense. the flash loader is not a problem, but for programs that are then executed from flash you need to use custom linker script and optionally copy some segments to sram, also you should use sram for stack and heap, as the blockrams get low for that too. if you have not done that before it will take you approx 2 weeks to get fully it runnging and set up. antti agaztelu@ikerlan.es (Arkaitz) wrote in message news:<b79e7ab9.0309160241.3eef5362@posting.google.com>... > Hi all, > > I'm trying to design a Microblaze system which uses an external SRAM > as instruction memory. I'm using the V2MB1000 board from Insight Memec > with P160 Communication module. > > The SRAM is conected to Microblaze through an external memory > controller conected to the Instruction side OPB bus. > The thing is that I don't know how to save my "executable.elf" file to > the external SRAM. > I've seen other microprocessors that firstly they copy the program > from flash or another Read Only storage device to a faster memory, > such as SRAM. They use a boot program, stored in FLASH, to do this. > > But in my system I don't know neither how to save it to the FLASH > because my program is too large and it can't be stored in the Block > RAMs. > > I'll very grateful if someone could help me. > > Thanks a lot. > > Arkaitz.Article: 60558
> The reason I went for fpga was to have wireless networking (802.11) > Actually, the sensors are 3-4 miles apart, I need the data until a > base station from where I will transfer the data to the internet. > the base station is located in the filed and will be 1-2 miles distant > from each sensor. So how do I transfer (in realtime) the data until the > base station from the sensor. Is it possible with PCI micro. > Please suggest me if there is a better solution other than fpga cpu > for doing this (wireless networking). Doing wireless with FPGA is not easier (nor harder) than with CPUs or MCUs. You probably will end up using some kind of off-the-selves wireless card and connect it to your custom application. Of what I understand of your application probably a wireless USB card would be the best for your application. Processing power is not an issue in your case. In that case you need to choose (or implement) a USB host controller but for control even an 8-bit CPU (PIC or AVR or whatever) should be adequate. I don't know of any 8-bit micro that has an USB host (not function!) controller, but there's a USB interface IC from Cypress, the SL811HS, that can be used as both a host and a slave controller. So, my suggestion would be: - Use an 8-bit microcontroller with an external bus (68HC11 from Motorola) or one with enough of I/O pins (ATmega from Atmel) and probably a with built-in A/D for the pressure sensors. - Use the SL811HS from Cypress to implement the USB host controller - Stick a wireless USB adapter to the unit to implement wireless - For 1-2 miles you probably need high-gain, directed antennas so choose an adapter that has external antenna connectivity. Regards, Andras TantosArticle: 60559
Hi Jon, This sounds pretty exciting. I have some questions. 1) What board are you using. I am assuming its some board with Virtex II Pro. 2) Where did you download the kernel sources from? 3) What bootload/monitor program did you use (U-boot/Red boot). Or you arent using one? 4) Do you have ethernet support? I know you are still at debugging stage but any information will be useful to us as we are in the process of getting Linux running on Memec's V2P4 evaluation board. Thanks, Shamile Jon Masters <jonathan@jonmasters.org> wrote in message news:<vlrf2keihait3c@corp.supernews.com>... > Hi, > > I thought I would let you know that I have now got Linux booting and > running a sash shell on the serial console. > > I use the Microblaze serial driver, a little of the Mind patches > (however I had to rewrite the interrupt controller driver because of the > swapped registers and fix other bits) and stuff I have written myself. > This runs on stock 2.4.21, not the Montavista kernel. > > There are a few issues like busybox having problems because of a bug in > the page table code which causes problems for shared binaries. > I had to implement a fix for the Xilinx TLB errata and a few other bits > and I think this has introduced a subtle bug somewhere. > > More info when the port is complete at which point I will post a link. > > Jon.Article: 60560
"Ken Land" <kland1@neuralog1.com> wrote in message news:<vme5iv66sv911@news.supernews.com>... > Is it free? :) its free but I cant give yout the url, tried to find it again for you but failed, searching on japanese sites is a bit difficult :) it is from some-one who wrote it for XSP-009 board, but there are no links to it from XSP-009 official site(s) as much as I see. I have the files, can send you per email if you wish, let me know anttiArticle: 60561
The Spartan-3 pinout tables are described in the Spartan-3 data sheet, which also provides a direct link to a ZIP file containing all the ASCII text tables. The Spartan-3 applications team slightly modified the text format to make it easier to parse with a simple script. Likewise, you can open the files directly into Excel for easy sorting and massaging. All the tables are comma-delimited entries and includes additional information that makes it easier to create sorted lists. All pins are typed according to the descriptions in the data sheet. Likewise, all BGA pins include both the row and column values for each pin. That way, you can create sorted lists where ball "AK1" precedes ball "AK2". Otherwise, sorting the pins alphabetically has ball "AK1" preceding ball "AK10". See the "readme.txt" file in the ZIP file for a complete description. Similarly, the ZIP file contains footprint diagrams in Microsoft Excel format. Now, here are the direct links. Spartan-3 Data Sheet: Pinout Information http://direct.xilinx.com/bvdocs/publications/ds099-4.pdf Spartan-3 Pinout Tables http://www.xilinx.com/bvdocs/publications/s3_pin.zip We welcome any and all feedback to make these text files more useful. BTW, personal opinion, I agree that documents are sometimes difficult to find on the Xilinx web site. We're working with the Xilinx web team to improve things. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASIC "John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:bk5jmk$iko$1@bunyip.cc.uq.edu.au... > Hi folks, > > Does anybody know if there are machine readable versions of the Spartan3 > pin tables, like those that exist for V2 and V2pro? > > e.g. http://www.xilinx.com/products/virtex2pro/package/2vp7fg456.txt > > I've tried extrapolating the naming scheme to make a guess at the url, > but no luck. > > For Xilinx, a quick gripe: I spend a lot of time at the xilinx website, > accessing it on an almost daily basis, and am a professional researcher. > Yet still, I am often unable to navigate to information that I *know* > is present. For example, I ended up finding these V2/V2Pro pin tables > by digging out an old one I'd saved to my hard drive, and doing a google > search on the file name. > > Anyway, enough whinging - how about those S3 pin tables? > > Thanks, > > John >Article: 60563
"Jake Janovetz" <jakespambox@yahoo.com> ha scritto nel messaggio
news:d6ad3144.0309151854.54e599c2@posting.google.com...
> Has anyone tried 6.1i yet? I took a Spartan IIE design
> and compiled
> it under 6.1i (from 5.2i, previously). It failed timing
> by about 20%
> where it previously passed.
You are lucky! I have just upgraded from WebPack 4.2 to 5.2, and a SpartanII
project that previuosly worked, now it doesn't even map... :(
map report with 4.2:
Design Information
------------------
Command Line : map -p xc2s100-tq144-5 -cm area -k 4 -c 100 -tx off
main.ngd
Target Device : x2s100
Target Package : tq144
Target Speed : -5
Mapper Version : spartan2 -- $Revision: 1.58 $
Mapped Date : Wed Jul 23 16:28:06 2003
Design Summary
--------------
Number of errors: 0
Number of warnings: 1
Number of Slices: 1,198 out of 1,200 99%
Number of Slices containing
unrelated logic: 269 out of 1,198 22%
Number of Slice Flip Flops: 1,127 out of 2,400 46%
Total Number 4 input LUTs: 2,133 out of 2,400 88%
Number used as LUTs: 1,974
Number used as a route-thru: 159
Number of bonded IOBs: 54 out of 92 58%
IOB Flip Flops: 14
Number of Tbufs: 416 out of 1,280 32%
Number of Block RAMs: 5 out of 10 50%
Number of GCLKs: 2 out of 4 50%
Number of GCLKIOBs: 2 out of 4 50%
Total equivalent gate count for design: 107,305
Additional JTAG gate count for IOBs: 2,688
map report with 5.2:
Design Information
------------------
Command Line : C:/Xilinx/bin/nt/map.exe -quiet -p xc2s100-tq144-5 -cm area
-detail -ignore_keep_hierarchy -pr b -r -k 4 -c 100 -tx off -o main_map.ncd
main.ngd main.pcf
Target Device : x2s100
Target Package : tq144
Target Speed : -5
Mapper Version : spartan2 -- $Revision: 1.4 $
Mapped Date : Tue Sep 16 13:54:09 2003
Design Summary
--------------
Number of errors: 1
Number of warnings: 1
Logic Utilization:
Number of Slice Flip Flops: 1,108 out of 2,400 46%
Number of 4 input LUTs: 2,279 out of 2,400 94%
Logic Distribution:
Number of occupied Slices: 1,281 out of 1,200
106%
(OVERMAPPED)
Number of Slices containing only related logic: 978 out of 1,281
76%
Number of Slices containing unrelated logic: 303 out of 1,281
23%
*See NOTES below for an explanation of the effects of unrelated
logic
Total Number 4 input LUTs: 2,432 out of 2,400 101% (OVERMAPPED)
Number used as logic: 2,279
Number used as a route-thru: 153
Number of bonded IOBs: 54 out of 92 58%
IOB Flip Flops: 32
Number of Tbufs: 416 out of 1,280 32%
Number of Block RAMs: 5 out of 10 50%
Number of GCLKs: 2 out of 4 50%
Number of GCLKIOBs: 2 out of 4 50%
Total equivalent gate count for design: 108,827
Additional JTAG gate count for IOBs: 2,688
--
Lorenzo
Article: 60564In-maintenance folks have supposedly been receiving 6.1i since the beginning of September. I received mine on Monday. Since I work from both a laptop and desktop, I decided to try it on the laptop and see how the performance compared. I haven't done much in-depth. Jake antti@case2000.com (Antti Lukats) wrote in message news:<80a3aea5.0309152346.7e1ed7f5@posting.google.com>... > jakespambox@yahoo.com (Jake Janovetz) wrote in message news:<d6ad3144.0309151854.54e599c2@posting.google.com>... > > Has anyone tried 6.1i yet? I took a Spartan IIE design and compiled > > it under 6.1i (from 5.2i, previously). It failed timing by about 20% > > where it previously passed. > > > > Anyone have similar "luck" ? > > > > Jake > > where did you get 6.1i ? dont see it been released on xilinx website? > anttiArticle: 60565
Guiseppe- This was with SP1 (as you mentioned later) applied. I find it interesting that there is a service pack available by the time I receive my first media. Why would I have to regenerate with PACE? I do this stuff by hand, so I've never used PACE. Is there some intermediate file that it updates now? The constraints file does contain placement and pin locations, but those seem to be followed as is indicated by the post-PR floorplan look. (and FPGA editor) Jake "Giuseppeł" <miaooaim@inwind.it> wrote in message news:<bk6kph$qb16m$1@ID-61213.news.uni-berlin.de>... > Had you regenerate the ucf file with PACE? > I regenerate copletely this file and the time constrain return to the > original (5.2 version) > > Bye > Giuseppe > > "Jake Janovetz" <jakespambox@yahoo.com> ha scritto nel messaggio > news:d6ad3144.0309151854.54e599c2@posting.google.com... > > Has anyone tried 6.1i yet? I took a Spartan IIE design and compiled > > it under 6.1i (from 5.2i, previously). It failed timing by about 20% > > where it previously passed. > > > > Anyone have similar "luck" ? > > > > JakeArticle: 60566
Like Virtex-II and Virtex-II Pro, the Spartan-3 FPGA pre-configuration pull-up resistors are controlled by the HSWAP_EN pin. 0 = Enables weak pull-up resistors on all pins not actively involved in the configuration process. 1 = No pull-up resistors during configuration. After configuration, this pin is not used and should be kept at a logic 0 or 1. See page 13 of the Spartan-3 data sheet (Module 4, Pinouts) for more information. http://direct.xilinx.com/bvdocs/publications/ds099-4.pdf --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASIC "Amontec Team" <laurent.gauch@www.DELALLCAPSamontec.com> wrote in message news:3f65851f$1@news.vsnet.ch... > Hi, > > For the Spartan-II, the preconfiguration pullup resistors were selected > by the M2 configuration pin. What about for the Spartan-3? > > My new design has to connect an ARM7TDMI bus to the SPARTAN-3. I need to > make sure my ucLinux will boot correctly, and so make sure about the IO > pins states of the SPARTAN-3 on the poweron. > > Regards, > Laurent >Article: 60567
Antti Lukats wrote: > "Kenneth Land" <kland1@neuralog1.com> wrote in message news:<vmcl99c2s5jgc0@news.supernews.com>... > >>Have you looked at the USB 1.1 and 2.0 IP Cores at www.opencores.com? >> >>I looked very closely at the 1.1 version and found it took only 6 pins and >>$1.75 transceiver chip. >> >>Ken > > > there is a japanese design (VHDL, and Visual basic host example) > that uses no tranceiver at all, ie USB DM,DP directly to FPGa > > antti I've thought about that, two pins programmed for 3V3-cmos should be good for tx and rx of SE0 but I never got around to checking if one of the differential standards on the FPGA would be within spec for USB? -LasseArticle: 60568
Hello Christian, Thanks a lot for your help, as you suspected my problem was the missing constraint. Do you know of any constraints for the VCC primitive? I used the "LOC" constraint, but it issues me this warning: "WARNING:MapLib - Property LOC on VCC_clk_dll not supported for simple gates - ignoring."Article: 60569
"Ken Land" <kland1@neuralog1.com> wrote in message news:<vme5iv66sv911@news.supernews.com>... > Is it free? :) google usb.lzh => http://member.nifty.ne.jp/fpga/freeip/usb/ :) found! anttiArticle: 60570
Lasse Langwadt Christensen wrote: > > Antti Lukats wrote: > > "Kenneth Land" <kland1@neuralog1.com> wrote in message news:<vmcl99c2s5jgc0@news.supernews.com>... > > > >>Have you looked at the USB 1.1 and 2.0 IP Cores at www.opencores.com? > >> > >>I looked very closely at the 1.1 version and found it took only 6 pins and > >>$1.75 transceiver chip. > >> > >>Ken > > > > > > there is a japanese design (VHDL, and Visual basic host example) > > that uses no tranceiver at all, ie USB DM,DP directly to FPGa > > > > antti > > I've thought about that, two pins programmed for 3V3-cmos should be good > for tx and rx of SE0 but I never got around to checking if one of the > differential standards on the FPGA would be within spec for USB? > > -Lasse It has been awhile since I looked at the USB spec, but I seem to recall that there is a non-standard state that is used to signal the rate or some other aspect of the interface. I want to say this state is both signals high or both low at the same time. Am I out to lunch on this? If there is a non-standard state on these pins, you would not be able to use an LVDS driver. You would need two independant outputs. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60571
Jake Janovetz wrote: > > Guiseppe- > > This was with SP1 (as you mentioned later) applied. I find it > interesting that there is a service pack available by the time I > receive my first media. > > Why would I have to regenerate with PACE? I do this stuff by hand, so > I've never used PACE. Is there some intermediate file that it updates > now? The constraints file does contain placement and pin locations, > but those seem to be followed as is indicated by the post-PR floorplan > look. (and FPGA editor) > > Jake Don't be surprised about the service packs. The "features" that are part of each release are planned well in advance. When bugs are encountered, they priortize them and only fix the "critical" bugs prior to release. The lesser bugs and other features are then planned into later releases, again according to priority. A conversation I had with a Xilinx person indicated that they have bug fixes and new features planned at least two service packs ahead. I think it is pretty good that Xilinx was able to release the first service pack so soon. To me this shows that they did a good job of triage, planning and execution on both the 6.1 release and the first service pack. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60572
Andras Tantos wrote: >>The reason I went for fpga was to have wireless networking (802.11) >>Actually, the sensors are 3-4 miles apart, I need the data until a >>base station from where I will transfer the data to the internet. >>the base station is located in the filed and will be 1-2 miles distant >>from each sensor. So how do I transfer (in realtime) the data until the >>base station from the sensor. Is it possible with PCI micro. >>Please suggest me if there is a better solution other than fpga cpu >>for doing this (wireless networking). > > > Doing wireless with FPGA is not easier (nor harder) than with CPUs or MCUs. > You probably will end up using some kind of off-the-selves wireless card and > connect it to your custom application. Of what I understand of your > application probably a wireless USB card would be the best for your > application. Processing power is not an issue in your case. In that case you > need to choose (or implement) a USB host controller but for control even an > 8-bit CPU (PIC or AVR or whatever) should be adequate. I don't know of any > 8-bit micro that has an USB host (not function!) controller, but there's a > USB interface IC from Cypress, the SL811HS, that can be used as both a host > and a slave controller. So, my suggestion would be: > > - Use an 8-bit microcontroller with an external bus (68HC11 from Motorola) > or one with enough of I/O pins (ATmega from Atmel) and probably a with > built-in A/D for the pressure sensors. > - Use the SL811HS from Cypress to implement the USB host controller > - Stick a wireless USB adapter to the unit to implement wireless > - For 1-2 miles you probably need high-gain, directed antennas so choose an > adapter that has external antenna connectivity. > > Regards, > Andras Tantos > > The solution seems promising, what kind of wireless technology can be used ? can I use 802.11 or blue tooth or any other.Article: 60573
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<qoocmv4dr277d3hu3tem6qbik3ap5ju1g7@4ax.com>... > Does anyone know what to do with the pin on V2P called "RSVD"? > > I guess I'm meant to leave it open, but I haven't found anything in > the datasheet or the Xilinx answers database that says for sure. http://direct.xilinx.com/bvdocs/userguides/ug012.pdf Table 5-1 page 345 in the Virtex II-Pro Platform FPGA User Guide says RSVD Reserved pin - do not connect Alan Nishioka alann@accom.comArticle: 60574
On a sunny day (Tue, 16 Sep 2003 16:37:28 GMT) it happened "Srikanth Anumalla" <srikanth@unlserve.unl.edu> wrote in <pan.2003.09.16.16.37.32.378218@unlserve.unl.edu>: >On Mon, 15 Sep 2003 22:29:18 +0000, Jan Panteltje wrote: > >> On a sunny day (Mon, 15 Sep 2003 14:01:17 -0500) it happened Srikanth Anumalla >> <srikanth@unlserve.unl.edu> wrote in <bk523v$355$1@unlnews.unl.edu>: >> >>>Hi >>> >>>I am quite new in this field, Please excuse me if I talk something >>>nonsence. I have 10 pressure sensors which measure pressure in 10 >>>different points in a field. I need to aggregate all these values in >>>realtime and send to a remote computer.For this, somebody suggested me >>>to use fpga, I made little research and found out that we can actually >>>run an some programs on fpga. I have this idea now, to build an fpga >>>board which can read data from the sensor and send that data to a >>>central computer in the field over a wireless network. and I will have >>>an fpga at each sensor. CEntral computer will aggregate the data and >>>send to a remote location via phone line etc. For this to be realized I >>>have to know whether an fpga is capable of collecting date from a sensor >>>and send the same data over a wireless network. Please give me pointers >>>on this . Any help would be greatly appreciated. >>> >>>Thanks >>>Srikanth >>> >>> >> If your pressure sensors have analog output, then why use FPGA? >> Use a PIC micro with build in AD and 4 channel input mux. >> 3 of these or one with an external mux, use the serial port of the PIC >> or make your own protocol or whatever. >> 12F675 is only 8 pins DIL, has a 10 bits AD with 4 input mux, internal oscillator, >> costs 2 dollars, so 4 of these set you back 8 dollars and the microchip tools are >> free from www.microchip.com >> Why use FPGA? > > >The reason I went for fpga was to have wireless networking (802.11) >Actually, the sensors are 3-4 miles apart, I need the data until a >base station from where I will transfer the data to the internet. >the base station is located in the filed and will be 1-2 miles distant >from each sensor. So how do I transfer (in realtime) the data until the >base station from the sensor. Is it possible with PCI micro. >Please suggest me if there is a better solution other than fpga cpu >for doing this (wireless networking). > >Thanks in advance >Srikanth OK, wireless networking I dunno what you do. If your sensors are analog output you still need the AD converter(s). IMHO you can do wireless network both with FPGA and a microprocessor. It depends on how much you want to do in software, dedicated chips? Or do the whole thing in FPGA (and perhaps use a processor core). The variations are endless. I cannot possibly tell you what is the best solution for you. Even using a fiber optic link (from the PICs) over that distance is possible. It would be more reliable then a radio link. But of cause if your sensors are on the move or they are digging there that won't be a good idea. You decide. If you want to get familar with FPGA nice project, but think how much time it will take you. So many factors. JP
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