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
On a sunny day (Tue, 27 Jan 2004 11:18:07 -0500) it happened bob <kmart@nospam.com> wrote in <gb3d105893fkahc14d6eh0veh62frit83g@4ax.com>: >Hi I want to make a project that uses an image sensor (any perhaps a >low power cmos from Micron or Kodak) connected to a FPGA (or CPLD). >with the apropriate VHDL or Veralog code. > >Has anyone done this who would be willing to share there hardware >and/or software designs to get me started? >Or is there any examples on the web that I can explore? > >Martin >mart NO inb SPAM AT magma DOT ca > >Remove the NO SPAM and put no spaces. Also replace the AT for @ and >the >DOT for . > >or post replies > >Thanks Somebody in Spain did a VHDL version of my mcam soft, uses the Creative webcam II look for document: Sistemacapturaimagenfin.pdf This webcam uses a 8052 processor to talk to the sensor itself. So the fpga talks to the 8052. The sensor is 4 bits bus with serial control, but I no longer have the datasheet. It is in Spanish. This sensor is likely superceded by better ones. http://www.home.zonnet.nl/panteltje/mcam/ for my C version. The VHDL version will learn you how to emulate a PC parport.... I think, given the datasheet of the sensor, it is pretty straight forward. Talking directly to the sensor eliminates such protocols as par port / usb, whatever. But you may still need that to send the data anywhere else... JPArticle: 65401
Clark, Thanks for the information. I recently got the board and have been playing with it. I agree with you that it was easy to get there demos up and running, but I must say I am a litte confused when trying to modify them. For example I have the 2VP7 Pro chip and was looking at the PLB external memory example. This code/data is in the I&D BRAM and thus has limited space. I would like to modify the code to run in SRAM which starts at 0x00000000 in their example. I was able to find the start address location to modify, but how can you specific the data location in memory? I would like the code to run in IBRAM and the data to reside in SDRAM (or is it possible to use both DBRAM and SDRAM for your data). Also do you or anyone else have any example programs outside the ones they give you to help weed through some of these issues. Any help would be greatly appreciated. AJ "Clark Pope" <cepope@mindspring.com> wrote in message news:<KwXNb.10087$q4.8777@newsread3.news.atl.earthlink.net>... > I have an Avnet board. It comes with evaluation versions of EDK and ISE. It > comes with a compact flash card containing several demo .bit files. By > default it boots into Linux but you can make it boot any one of several > sample designs. It had everything I need and ran out of the box in about 10 > minutes. > > The one bad thing is that all of the documentation comes on CDs. I ended up > printing about 500 pages of material so I could leaf to info easily. Also, > it would be nice if they posted the documents to the web. > > "AJ" <AirJosh69@hotmail.com> wrote in message > news:af0645be.0401160818.150fc01a@posting.google.com... > > Hello FPGA users, > > > > I am thinking about purchasing the Avnet Virtex-II ProT Development > > Kit and would like to find out if anyone is using it or has used it > > recently. I want to make sure I am not missing anything. It seems like > > it comes with all the tools, but I find it difficult to get a > > straight/consistant answer sometimes from Avnet. My confusion lies in > > the PowerPC tools and startup. I want to make sure that the board and > > tools (ISE 6.1 Foundation and EDK) are sufficient to get going. I > > don't need an RTOS for my project so I just want to be able to run my > > code on the PowerPC either from external RAM or internal BRAM. > > > > Confusion is about the BOOT up process and wether I will have to write > > alot of system level code. Can someone help me out or point me to a > > document that might clear up my concerns. > > > > I would love to talk with someone that is currently using this > > product. Please e-mail me. > > > > Thanks in advance, > > AJArticle: 65402
Thanks, Paul, for the detailed answer. Very much appreciated. If I understand the handbook correctly, each LAB can drive an R4 to its left or right. But I haven't found out how many signals in total can be driven on the various MultiTracks (ie. how wide are they?). Also, does Altera have training courses that describe the architecture to this level of detail? I understand most people are not concerned or interested in it, so it may not be practical to have seminars on it. -- Pete "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<g3kRb.52563$iLV.46589@twister01.bloor.is.net.cable.rogers.com>... > Hi Peter, > > The delay of the interconnect is both easy and complicated to give you. The > quick answer is yes, we know the average delay of these resources (see > unofficial table below). I'll enquire as to why we don't have delays or > delay ranges specified in the data sheet. > > The long answer is that the delay of a given resource in Quartus will vary > due to a variety of reasons. > - # of active fanouts along the line (usually 1-2, but could be high > depending on route) > - # of inactive loads long the wire (doesn't vary too much) > - # of partially active loads -- these can happen when a two-stage mux has > multiple 1st stage inputs turned on due to sharing of configuration RAM > bits. > - Distance traveled. If you travel only four units along an R24 wire, you > won't get the full RC delay due to resistive shielding of down-stream > capacitance. > - Edge rate of incoming signal. This in turn is affected by the resource > used previously -- a R24 -> R4 could have different edge rate than R4 -> R4. > It will also be affected by that resource's loading. > - Blocks passed. An R4 wire that passes over four LABs will be different in > length (physically) than an R4 that crosses an M4K block + three LABs. > Also, a C4 wire next to a clock spine may have slightly greater loading than > one between two LABs. > - Exact wire used. Two different R4 wires that appear identical in all > these ways can have different timing due to what metal layer they are routed > on or due to physical proximity to other wires being different. > - Rising/falling transition. Delay can vary depending on whether the input > is a rising or falling transition. > > Quartus will give you the right answer to routing delay. All these factors > do is make it a little more difficult to predict the precise delay you will > see in advance of timing analysis. The allocation of delay to a particular > resource in a full routing path is somewhat arbitrary and depends on > measurement points and how we choose to bin the delay. > > The following data was extracted from the critical paths of a large number > of typical user designs, and thus is representative of the types of paths > that tend to occur on the critical path. It is not the maximum nor minimum > delay you will see on this type of resource. > > Stratix -5 Routing Delays (Mux + Buffer + Wire): > > R4 303 ps > R8 373 ps > R24 503 ps > C4 467 ps > C8 650 ps > C16 525 ps > LAB Line 463 ps > LE Output 231 ps > Local Line 353 ps > > Regards, > > Paul Leventis > Altera Corp.Article: 65404
Hi, I set up and maintain a lab at San Jose State University. > 1. Which operating system supplies the best performance > environment for Xilinx development? I read that the > supplied ModelSim II XE works only on PCs, not on > Solaris or Linux. So would you prefer a PC, because > of the included simulation environment? I have a strong preference for Windows 2000. Yes, the availability of CAD tools is decent but beyond that, your university probably has a site license for other Microsoft products, like Word and Powerpoint. If you install these, the lab is also good for writing reports, etc. Originally, the department was maintaining the lab, but every week another machine would get corrupted because students treat lab equipment like their personal property. We had all kind of viruses, porn, broken iSE installs. It got to the point where I had 6 functional machines out of 16, and it impacted my ability to teach the class. Also, I felt it left a bad impression on students, I want their first use of Xilinx FPGAs to be positive. Over one summer, I configured all 16 machines in the lab identically (W2K, MS office, Acrobat, Xilinx iSE, etc...) and then installed DriveShield, which you can read about: http://www.centuriontech.com This "restores" the disk to how I left it each time the power is cycled. The lab has been up and running, bullet proof, for two years now. The initial setup was some work but it has really paid off. I highly recommend DriveShield! > 3. Which Download Cable would you recommend? Does the > Parallel Cable only work with a PC (I read that somewhere)? > Or would you prefer the Multilinx Cable? (If so, why?) Don't use any cables. They are easy to break and easy to steal. Instead, buy prototyping boards that have this function integrated. You can get boards like this from Digilent, http://www.digilentinc.com All that is required is a standard parallel cable (comes with the board). EricArticle: 65405
This was an interesting topic, so I've tagged it with a better title than 'Spirit on Mars...' for later searchers -jg Austin Lesea wrote: > Ray, > > Excellent summary of the operation. All perfectly correct. > > V2P QPRO is still in progress, as we were "in the beam" at LANSCE just > last week. So far, so good. > > Austin > > Ray Andraka wrote: > >> Austin, >> >> I don't think I said it corrupted the contents. I thought I said it >> corrupted the user >> read of the contents. The point is, you can't read the BRAM while the >> user circuit is >> running without messing up the user function. You either need to stop >> the clock, or the >> user circuit has to somehow know it can't expect good data from the >> BRAM and deal with it >> accordingly. One work around would be to use ECC and spread the read >> word width over >> multiple BRAMs situated in different columns. Again, the designer has >> to be aware that >> this behavior happens during readback. I don't think this particular >> one was documented >> when we were looking at it, even though it was apparently an >> intentional behavior. >> >> In the case of CLBRAM or SRL16's, one must be even more careful, >> because there, a readback >> at the wrong time can actually corrupt the contents rather than just >> the read value. I >> believe that one is a problem if the user circuit is changing the lut >> content (eg clocking >> with WE='1') while a readback of that cell is occuring. That one >> seemed like it was not an >> intentional behavior, and I've yet to see it documented anywhere. >> I've had two customers >> run into this one, fortunately with the second one as soon as they >> told me that they were >> doing readback, I knew what the problem was. >> >> Keep up the good work. BTW, what is the latest on availability dates >> for the QPRO version >> (space qual'd) virtexII? I've got a project right now where a V2 >> would save a bunch of >> headache, but it has to be real relatively soon in order to make the >> launch schedule. I >> can use which ever one comes out first. The design is currently >> slated for a pair of >> V1000's, only because of the internal memory requirements. 75% of the >> logic in the V1000 >> prototype is SRL16's used as a delay buffer because we used up the BRAMs. >> >> >> Austin Lesea wrote: >> >> >>> Ray, >>> >>> I was correct (still correct). Readback does not corrupt BRAM contents. >>> But the config logic does take over the control of BRAM, so the user >>> may not see what they expect while you are reading back (takes total >>> control of ports A and B). >>> >>> I agree that readback has not been comprehensively described, and that >>> is something that we are working on, since reading back is now becoming >>> so useful and interesting. >>> >>> Austin >>> >>> Ray Andraka wrote: >>> >>>> Thanks, I appreciate it. It would be helpful to have a >>>> comprehensive readback >>>> appnote that detailed all of the gotchas, both the ones that are by >>>> design and the >>>> 'ah-shits'. I know we stumbled on one or two during some of the >>>> radiation testing >>>> experiments. In any event, I haven't seen anything that documents >>>> it as a complete >>>> package. Readback induced problems can be subtle, and I imagine >>>> could be a nightmare >>>> to diagnose without the nice patterns we were testing with. It >>>> would be very >>>> beneficial to have all the data available to anyone who is >>>> attempting it. I'm once >>>> again running into a "if you show me the documentation, I'll believe >>>> you"' situations >>>> once again. >>>> >>>> Austin Lesea wrote: >>>> >>>> >>>> >>>>> Ray, >>>>> >>>>> As we all know, I am certainly not perfect, so I could be wrong >>>>> here. I >>>>> am checking. I was pretty confident that changing the address while >>>>> trying to read hte LUTs affected the contents as they have to share >>>>> circuitry, but the BRAM is a two port plus the config access, or >>>>> really >>>>> a three port memory as the addressing of the config is independent. >>>>> >>>>> I will post as soon as I know for sure.... >>>>> >>>>> Austin >>>>> >>>>> Ray Andraka wrote: >>>>> >>>>> >>>>> >>>>>> Austin, >>>>>> >>>>>> Are you sure this is true for BRAM? As I understood it, the >>>>>> readback logic for >>>>>> the BRAM in virtex is shared with part of the operational logic >>>>>> and you will >>>>>> corrupt a user read if readback is performed on a BRAM while a >>>>>> user read is also >>>>>> happening, ie, you need to either shut down the clock or have the >>>>>> user circuit >>>>>> ignore read data. I'm hoping this was not conveyed to me >>>>>> properly, but my >>>>>> source was rather emphatic (source was involved with the radiation >>>>>> testing at >>>>>> LANL). >>>>>> >>>>>> Austin Lesea wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> If that BRAM was storing constants/lookup info (read only), then >>>>>>>> I can see a need to verify the table is actually still correct ? >>>>>>> >>>>>>> >>>>>>> If BRAM or LUTRAM is storing constants, then you may include it >>>>>>> in the >>>>>>> readback verify. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -jg >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --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 >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> --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 >>>> >>>> >> >> >> -- >> --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: 65406
Wow Austin, you really should cut down on the caffeine!!! Austin Lesea wrote: > > Thomas, > > You need to contact one of our FAEs! > > See below, > > Austin > > Thomas Stanka wrote: > > > Hi, > > > > Austin Lesea <austin@xilinx.com> wrote: > > > >>radioactive after spending so much time in the beam. Oh, and none of > >>them ever suffer any damage -- they power on and meet all specs after > >>hundred and hundreds of rads. > > > > > > What about 100 krad? I'm just curios. In our company we have problems > > to use devices without qualification for at least 30krad. > > Better than 100Krad. Ask for the FAE for radiation test results. > > > > > > >>>Analysis > >> > >>This is a standard procedure, and we are the ONLY company that actually > >>KNOWS how our parts are affected by cosmic neutron showers, alpha > >>particles, etc in REAL applications from sea level to 60,000 feet (I > >>can't talk about the programs we have for mil/aerospace until you sign > >>an NDA). > > > > > > This seems a bit too overconfident. > > Actually I didn't know your effort, but I know the effort Actel is > > doing for its devices. And they prove very sufficient analyses beside > > the analyses spacecompanies are doing with Actel Fpgas for themself. > > No, it is not. Some competitors are spreading information that is > patently false, and misleading (there, I said it). They compare us with > commercial SRAM, which is false and misleading, as we are not commercial > SRAM, have nothing to do with commercial SRAM, and do not use commercial > SRAM technology or cells. We use our own design cmos configuration > latches, which are shown to be 20X to 100X more robust for the same > technology. As for their own tests, they only talk about their fuses, > and not their logic, or flip flops. How fair is that? With a part that > is one tenth the size of ours. Tens times smaller, is also ten times > fewer upsets. > > How to lie with numbers. > > > > > > >>Competitors > >> > >>Other companies out there are in a state of "blissful ignorance" and > >>when (not if) they start to have customers complain of failures, they > >>will be saying, "gee, we don't see anything (because we can't), must be > >>something you are doing." Why can't they see anything when a customer > >>complains? > > > > > > I'm shure you wouldn't tell names, but did you _ever_ tried the > > hotline of another fpga vendor? Tell us a bit about your experience. > > I'm very satisfied the way Actel is reacting on complaints. > > > > OK, let us try it: Competitors? What is your cross section for logic? > Cross section for flip flops? Cross section for config bits, RAM? Go > ahead, let us all know your data. Ours is very simple, you can not > upset our logic or flip flops as they are so heavily loaded. And the > rest of our data is in the power point MAPLD presentation that RK has so > kindly provided the link to.Article: 65407
simon <ssteineg@ee.ethz.ch> wrote in message news:<4016b07a$1@pfaff2.ethz.ch>... > Hello, > Is anyone out there experienced in building macros. As soon as my macros > contain external pins I cannot reopen them in "FPGA Editor". "FPGA > Editor" crashes displaying the following message: > > FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start > property read <0xfffcacc>. Process will terminate. To resolve this > error, please consult the Answers Databas and other online resources at > http://support.xilinx.com. If you need further assistance, please open a > Webcase by clicking on the "WebCase" link at http://support.xilinx.com > > I'm a student, so I am not allowed to open a webcase... > > Regards > Simon Hello Simon, I have found a known problem that appears to be a good match for your problem. This problem only occurs when more than one save operation is performed per FPGA Editor session. Try defining all of your external pins at once without intermediate saves. If there are too many of them for that to be practical, I suggest that you close the editor after saves before continuing. BTW, if you are using our current tools, you may want to consider using RPM Macros combined with Directed Routing constraints instead of Hard Macros. It depends on what you are trying to accomplish with the macro. Regards, BretArticle: 65408
bob wrote:
> Hi I want to make a project that uses an image sensor (any perhaps a
> low power cmos from Micron or Kodak) connected to a FPGA (or CPLD).
> with the apropriate VHDL or Veralog code.
>
> Has anyone done this who would be willing to share there hardware
> and/or software designs to get me started?
> Or is there any examples on the web that I can explore?
>
I think this directly connects with a CMOS sensor (figure 3)
Article (from Xcell Journal)
http://www.xilinx.com/publications/xcellonline/xcell_46/xc_freesw46.htm
(get the pdf with pictures at page bottom)
Alternative location:
http://www.linuxdevices.com/articles/AT6411901280.html
"FPGA Code
Most of the system functionality is implemented in the Xilinx Spartan-IIE
FPGA. The code is written in Verilog HDL and is available for download at
my Elphel website under the GNU/GPL (general public license) license. It is
designed around a four-channel SDRAM controller that uses embedded block
RAM modules as "ping-pong" buffers to provide quasi-simultaneous block
access for the following data sources and receivers:
Image data from the sensor, either processed or raw, one- or two-bytes per
pixel, arranged as 256 (128) pixel lines
Calibration data to the FPN elimination module prepared by software in
advance, 128x16-bit blocks
Data to the JPEG compressor, arranged as square blocks of 16x16 bytes
CPU access to the SDRAM (normally used to read raw sensor data and write
back the calibration data for the FPN elimination). The JPEG encoder uses
two-thirds of the FPGA resources, as shown in Figure 3. The encoder
consists of the chain of the processing modules, some of which use block
RAM for data buffering and table storage:
- Bayer-to-YCbCr converter
- 8x8 DCT based on the Xilinx XAP610, modified to provide
block-asynchronous operation and to increase dynamic range
- Quantizator and zigzag encoder
- RLL encoder
- Huffman encoder
- Bit stuffer."
http://www.elphel.com/
--
Roger Larsson
Skellefteċ
Sweden
Article: 65409Ralph, Would you believe I drink decaf? Hard to imagine. Austin Ralph Malph wrote: > Wow Austin, you really should cut down on the caffeine!!! > > > > Austin Lesea wrote: > >>Thomas, >> >>You need to contact one of our FAEs! >> >>See below, >> >>Austin >> >>Thomas Stanka wrote: >> >> >>>Hi, >>> >>>Austin Lesea <austin@xilinx.com> wrote: >>> >>> >>>>radioactive after spending so much time in the beam. Oh, and none of >>>>them ever suffer any damage -- they power on and meet all specs after >>>>hundred and hundreds of rads. >>> >>> >>>What about 100 krad? I'm just curios. In our company we have problems >>>to use devices without qualification for at least 30krad. >> >>Better than 100Krad. Ask for the FAE for radiation test results. >> >> >>> >>>>>Analysis >>>> >>>>This is a standard procedure, and we are the ONLY company that actually >>>>KNOWS how our parts are affected by cosmic neutron showers, alpha >>>>particles, etc in REAL applications from sea level to 60,000 feet (I >>>>can't talk about the programs we have for mil/aerospace until you sign >>>>an NDA). >>> >>> >>>This seems a bit too overconfident. >>>Actually I didn't know your effort, but I know the effort Actel is >>>doing for its devices. And they prove very sufficient analyses beside >>>the analyses spacecompanies are doing with Actel Fpgas for themself. >> >>No, it is not. Some competitors are spreading information that is >>patently false, and misleading (there, I said it). They compare us with >>commercial SRAM, which is false and misleading, as we are not commercial >>SRAM, have nothing to do with commercial SRAM, and do not use commercial >>SRAM technology or cells. We use our own design cmos configuration >>latches, which are shown to be 20X to 100X more robust for the same >>technology. As for their own tests, they only talk about their fuses, >>and not their logic, or flip flops. How fair is that? With a part that >>is one tenth the size of ours. Tens times smaller, is also ten times >>fewer upsets. >> >>How to lie with numbers. >> >> >>> >>>>Competitors >>>> >>>>Other companies out there are in a state of "blissful ignorance" and >>>>when (not if) they start to have customers complain of failures, they >>>>will be saying, "gee, we don't see anything (because we can't), must be >>>>something you are doing." Why can't they see anything when a customer >>>>complains? >>> >>> >>>I'm shure you wouldn't tell names, but did you _ever_ tried the >>>hotline of another fpga vendor? Tell us a bit about your experience. >>>I'm very satisfied the way Actel is reacting on complaints. >>> >> >>OK, let us try it: Competitors? What is your cross section for logic? >> Cross section for flip flops? Cross section for config bits, RAM? Go >>ahead, let us all know your data. Ours is very simple, you can not >>upset our logic or flip flops as they are so heavily loaded. And the >>rest of our data is in the power point MAPLD presentation that RK has so >>kindly provided the link to.Article: 65410
Whiel running modular design i get a single error at the end of active module implementation phase => Unrouted net GLOBAL_PSEUDO/CLK. The thing abt. this net is that it is inserted by the mapper alongwith a bunch of other signals that help the router route the inter-module signals properly. This CLK is what goes to the intermodule signal registers that map is inferring automatically at the boundary of the module. So this signal is not really a part of my design. And clearly there are plently of empty areas around it as is evident when viewing it in FPGA editor. Any pointers? regards, nachiket.Article: 65411
Hi Peter, > If I understand the handbook correctly, each LAB can drive an R4 to > its left or right. But I haven't found out how many signals in total > can be driven on the various MultiTracks (ie. how wide are they?). The "cross-section" of the routing channel in Stratix is 160 R4 wires, 48 R8 wires, 80 C4 wires, 32 C8 wires, 24 R24 wires, and 16 R16 wires. Each LE can drive C4/C8 wires in the channels to the left and right of the LE, as well as R4/R8 wires that start "above and to the left" and "above and to the right" of the LE. Of course, this is all very fuzzy since this is a logical, not a physical, representation of things. But basically it means that you can get from an LE to another LE that is up to four or eight LABs away (not including the first one) in either direction in a single hop. You get onto the R24/C16 wires from R4 wires, and they can drive R24/C16/R4/C4 wires to eventually get to other blocks. On top of this, there are paths that take you from an LE output to the LAB line of adjacent labs, bypassing the routing. Things are little trickier near the DSP, M4K, and MRAM blocks. For the DSP and M4K blocks, basically pretend there are two LABs worth of routing that are accessable by the DSP/M4K block, minus the vertical channel. BTW, another way to see the routing that was used (rather than using Chip Editor) is to back-annotate your fitting, including the routing. This will produce a file named <design>.rcf in your project directory that contains the routing. You can also create your own routing constraints, with wild-carding, by editing the RCF file. See the QUIP documentation (http://www.altera.com/education/univ/quip/quip-overview.html) for more information on the RCF file format. > Also, does Altera have training courses that describe the architecture > to this level of detail? I understand most people are not concerned or > interested in it, so it may not be practical to have seminars on it. Looking at our web site, "Fundamental Design Techniques for Stratix Devices" looks like it could cover this material, but probably not in too much more detail. I'd contact Altera Customer Training (custrain@altera.com) for help in determining if an appropriate training session exists. My guess is that knowing the routing architecture to this level of detail isn't too handy to the typical end user. The router is quite good at optimizing things, though it is good to know how far you can go before you must add additional routing hops, especially when floorplanning a design manually via LogicLock. I believe that there is a way in the Timing Closure floorplan view to see a histogram of the delays from a source LE to destination LEs -- it tells you where you can reach in what amount of delay. But I don't recall how to get to this feature as I don't actually get to use Quartus too much myself. Looking at this view can give you a good intuition on the directional bias (speed-wise) of the routing architecture as well as where things should be placed relative to one another for maximum speed. Regards, Paul Leventis Altera Corp.Article: 65412
Yes it is hard to believe sometimes... ;) Austin Lesea wrote: > > Ralph, > > Would you believe I drink decaf? Hard to imagine. > > Austin > > Ralph Malph wrote: > > Wow Austin, you really should cut down on the caffeine!!! > > > > > > > > Austin Lesea wrote: > > > >>Thomas, > >> > >>You need to contact one of our FAEs! > >> > >>See below, > >> > >>Austin > >> > >>Thomas Stanka wrote: > >> > >> > >>>Hi, > >>> > >>>Austin Lesea <austin@xilinx.com> wrote: > >>> > >>> > >>>>radioactive after spending so much time in the beam. Oh, and none of > >>>>them ever suffer any damage -- they power on and meet all specs after > >>>>hundred and hundreds of rads. > >>> > >>> > >>>What about 100 krad? I'm just curios. In our company we have problems > >>>to use devices without qualification for at least 30krad. > >> > >>Better than 100Krad. Ask for the FAE for radiation test results. > >> > >> > >>> > >>>>>Analysis > >>>> > >>>>This is a standard procedure, and we are the ONLY company that actually > >>>>KNOWS how our parts are affected by cosmic neutron showers, alpha > >>>>particles, etc in REAL applications from sea level to 60,000 feet (I > >>>>can't talk about the programs we have for mil/aerospace until you sign > >>>>an NDA). > >>> > >>> > >>>This seems a bit too overconfident. > >>>Actually I didn't know your effort, but I know the effort Actel is > >>>doing for its devices. And they prove very sufficient analyses beside > >>>the analyses spacecompanies are doing with Actel Fpgas for themself. > >> > >>No, it is not. Some competitors are spreading information that is > >>patently false, and misleading (there, I said it). They compare us with > >>commercial SRAM, which is false and misleading, as we are not commercial > >>SRAM, have nothing to do with commercial SRAM, and do not use commercial > >>SRAM technology or cells. We use our own design cmos configuration > >>latches, which are shown to be 20X to 100X more robust for the same > >>technology. As for their own tests, they only talk about their fuses, > >>and not their logic, or flip flops. How fair is that? With a part that > >>is one tenth the size of ours. Tens times smaller, is also ten times > >>fewer upsets. > >> > >>How to lie with numbers. > >> > >> > >>> > >>>>Competitors > >>>> > >>>>Other companies out there are in a state of "blissful ignorance" and > >>>>when (not if) they start to have customers complain of failures, they > >>>>will be saying, "gee, we don't see anything (because we can't), must be > >>>>something you are doing." Why can't they see anything when a customer > >>>>complains? > >>> > >>> > >>>I'm shure you wouldn't tell names, but did you _ever_ tried the > >>>hotline of another fpga vendor? Tell us a bit about your experience. > >>>I'm very satisfied the way Actel is reacting on complaints. > >>> > >> > >>OK, let us try it: Competitors? What is your cross section for logic? > >> Cross section for flip flops? Cross section for config bits, RAM? Go > >>ahead, let us all know your data. Ours is very simple, you can not > >>upset our logic or flip flops as they are so heavily loaded. And the > >>rest of our data is in the power point MAPLD presentation that RK has so > >>kindly provided the link to.Article: 65413
Ralph Malph <noone@yahoo.com> wrote: : Yes it is hard to believe sometimes... ;) Ralph, is it really needed to full quote 90 lines of nearly unrelated text. This only fills up the archives with redundancy and makes them hard to search. <Posted, as no valid mailing address is given> Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 65414
Hello Bret, I just read some xilinx documents about RPMs and Directed routing. I'm not quite sure if these are useful in my case. I'm working on a dynamically partial reconfigurable design and I want to model communication lines across reconfigurable modules as hard macros. I assume that this will prevent (or rather minimize) discontinuation of the signal flow when the module is reconfigured. Regards, Simon Bret Wade wrote: > simon <ssteineg@ee.ethz.ch> wrote in message news:<4016b07a$1@pfaff2.ethz.ch>... > >>Hello, >>Is anyone out there experienced in building macros. As soon as my macros >>contain external pins I cannot reopen them in "FPGA Editor". "FPGA >>Editor" crashes displaying the following message: >> >>FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start >>property read <0xfffcacc>. Process will terminate. To resolve this >>error, please consult the Answers Databas and other online resources at >>http://support.xilinx.com. If you need further assistance, please open a >>Webcase by clicking on the "WebCase" link at http://support.xilinx.com >> >>I'm a student, so I am not allowed to open a webcase... >> >>Regards >>Simon > > > Hello Simon, > > I have found a known problem that appears to be a good match for your > problem. This problem only occurs when more than one save operation is > performed per FPGA Editor session. Try defining all of your external > pins at once without intermediate saves. If there are too many of them > for that to be practical, I suggest that you close the editor after > saves before continuing. > > BTW, if you are using our current tools, you may want to consider > using RPM Macros combined with Directed Routing constraints instead of > Hard Macros. It depends on what you are trying to accomplish with the > macro. > > Regards, > BretArticle: 65415
I'm trying to create a bit file for a virtex xcv800 using ISE 6.1 but I can't select the virtex family. can I download it of the xilinx site somewhere? thanks DAveArticle: 65416
what can cause this error : ERROR: a gnd net is driven by primitive gate(s) -- NET: GND0 ???Article: 65417
Thanks to bad its in spanish. your software looks interesting. On Tue, 27 Jan 2004 18:55:18 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote: >On a sunny day (Tue, 27 Jan 2004 11:18:07 -0500) it happened bob ><kmart@nospam.com> wrote in <gb3d105893fkahc14d6eh0veh62frit83g@4ax.com>: > >>Hi I want to make a project that uses an image sensor (any perhaps a >>low power cmos from Micron or Kodak) connected to a FPGA (or CPLD). >>with the apropriate VHDL or Veralog code. >> >>Has anyone done this who would be willing to share there hardware >>and/or software designs to get me started? >>Or is there any examples on the web that I can explore? >> >>Martin >>mart NO inb SPAM AT magma DOT ca >> >>Remove the NO SPAM and put no spaces. Also replace the AT for @ and >>the >>DOT for . >> >>or post replies >> >>Thanks >Somebody in Spain did a VHDL version of my mcam soft, uses the Creative >webcam II look for document: Sistemacapturaimagenfin.pdf >This webcam uses a 8052 processor to talk to the sensor itself. >So the fpga talks to the 8052. >The sensor is 4 bits bus with serial control, but I no longer have the >datasheet. >It is in Spanish. >This sensor is likely superceded by better ones. >http://www.home.zonnet.nl/panteltje/mcam/ for my C version. >The VHDL version will learn you how to emulate a PC parport.... >I think, given the datasheet of the sensor, it is pretty straight forward. >Talking directly to the sensor eliminates such protocols as par port / usb, >whatever. >But you may still need that to send the data anywhere else... >JPArticle: 65419
XAPP290 says references to Vitex also apply to Spartan 2 devices, therefore partial reconfig should be possible, right? er yeah. So, I assume one should use bm_4b.mnc (bus macro for Virtex) for cross module communication as in a Virtex design. However, when running initial budgeting (ngdbuild -modular initial <design_name>) I get the following error: ERROR:PhysSimExpander:68 - Macro "D:\Work\partialbuild/bm_4b.nmc" is not compatible with the target architecture. This macro cannot be automatically retargeted because it was created with part v50bg256-4, which is no longer valid. So, am I using the wrong bus macro, do I have to generate my own one? (I have never used/built a macro before!!) I would be most gratefull for any help. Thanks in advance :) Ian.Article: 65420
H.Azmi <haythamazmi@hotmail.com> wrote: : what can cause this error : : ERROR: a gnd net is driven by primitive gate(s) -- NET: GND0 You overwhelm us with information. Do you do schematic capture for your design? I guess you connected some gate output to ground. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 65421
As a recent student, and having strong preferences toward the *NIX and open source philosophies, I feel the need to counter-balance some of the points made: Eric Crabill wrote: >>1. Which operating system supplies the best performance >> environment for Xilinx development? I read that the >> supplied ModelSim II XE works only on PCs, not on >> Solaris or Linux. So would you prefer a PC, because >> of the included simulation environment? > > > I have a strong preference for Windows 2000. Yes, the > availability of CAD tools is decent but beyond that, your > university probably has a site license for other Microsoft > products, like Word and Powerpoint. If you install these, > the lab is also good for writing reports, etc. The OpenOffice suite is more than good enough for 99% of users, is free, and is multi-platform. And anyway, everyone in University should be learning LaTeX :). And anyway, you don't need as performant a machine for writing reports as for synthesis and simulation, so unless you have computers to spare, it might not be a good idea to encourage people to write reports on these machines (we have separate labs for general purpose use). As to CAD tools, ISE 6.1 is available for Linux, Solaris, and Windows. I would recommend that you not limit your students to Modelsim XE, but instead get a site license. Mentor Graphics has a University Program that will provide you with rebates on these. Using FlexLM, the licenses will be available from anywhere on the network (independant of the machine's OS), which allows more flexibility. Using this setup, we have Modelsim SE running on both Windows 2000 and RedHat boxes. An added bonus to *NIX boxes is that the programs can be run remotely, meaning that the computers can be shared by different groups simultaneously. I also always appreciated not having to physically go to the lab just to run that one simulation that I had forgotten to run during my lab period... > Originally, the department was maintaining the lab, but > every week another machine would get corrupted because > students treat lab equipment like their personal property. > We had all kind of viruses, porn, broken iSE installs. > It got to the point where I had 6 functional machines > out of 16, and it impacted my ability to teach the class. > Also, I felt it left a bad impression on students, I want > their first use of Xilinx FPGAs to be positive. It sounds as if users had admin privileges! Most of these problems would be avoided by students having their own network drive space and only having write access to "scratch" space on local drives (and of course, no privilieges whatsoever when it comes to installing and modifying programs). Admittedly, this can be done as easily with Windows as *NIX, what's hard is finding a good sysadmin to handle it all. -- Pierre-Olivier -- to email me directly, remove all _N0SP4M_ from my address --Article: 65422
On Wed, 28 Jan 2004 03:25:03 -0800, Dave Pedlow wrote: > I'm trying to create a bit file for a virtex xcv800 using ISE 6.1 but I can't select the virtex family. can I download it of the xilinx site somewhere? > thanks > DAve Virtex is included in the 6.1 release. Did you install the virtex family when you did the install?.Article: 65423
simon <ssteineg@ee.ethz.ch> wrote in message news:<40177bdc$1@pfaff2.ethz.ch>... > Hello Bret, > I just read some xilinx documents about RPMs and Directed routing. I'm > not quite sure if these are useful in my case. I'm working on a > dynamically partial reconfigurable design and I want to model > communication lines across reconfigurable modules as hard macros. I > assume that this will prevent (or rather minimize) discontinuation of > the signal flow when the module is reconfigured. > > Regards, > Simon Hello Simon, I don't see why Directed Routing constraints couldn't replace the functionality of the Bus Macro in the partial reconfig flow, but since the penalty for not doing exactly the right thing is higher there, I recommend staying with the documented hard macro flow. If you do try the Directed Routing method, pay attention to the section in the .par file that tells you if all the DIRT constraints were successfull. Regards, BretArticle: 65424
My Xilinx distributor shipped an affected lot to us and we are now in a line-down situation. We've been told that lead-time is 10 weeks. I'm looking for 50 XC2V6000-4BF957C from an unaffected lot. Thanks.
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