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 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > a DATA2MEM (elf to bit file merge) is VERY important for softcore > > processors in FPGA's, and Altera kinda claims they have NIOS and > > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their > > toolchain!! > > You can get the same functionality using > > quartus_cdb --update_mif > > Petter > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? to my knowledge YOU CAN NOT if Quartus has generated a bit file (programming file) then this file (without access to the project database) CAN NOT BE updated with new memory file, unlike it is possible with xilinx data2mem tool AnttiArticle: 131001
Hi, I am using virtex4 device for my designs. In timing analysis i found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is that a way , i can reduce this gate delay by giving some constraints. ie is to reduce the gate delay by tools .Article: 131002
Hi, Simple question. Can I put a NiosII on an FPGA alone, no ROM no DRAM no SRAM no nothing, Just the FPGA ? (examples and kits put me on the opposite extreme) I understand that I would have little ram space etc... so programs will be small... etc etc... I just wonder if it is feasible and how to load all from the config device. --- OR is there anything else more appropriate to place inside an FPGA easy to put working alone. (micro controller I mean). Luis C.Article: 131003
LC pisze: > Hi, > > Simple question. > > Can I put a NiosII on an FPGA alone, no ROM no DRAM no SRAM > no nothing, Just the FPGA ? > > (examples and kits put me on the opposite extreme) > > I understand that I would have little ram space etc... > so programs will be small... etc etc... > I just wonder if it is feasible and how to load all from > the config device. > Hi, Yes, you can work with internal ram only. Yes you can store program in configuration memory used for FPGA. I tested. AdamArticle: 131004
<jamicrotech@gmail.com> wrote in message news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com... > Hi, > I am using virtex4 device for my designs. In timing analysis i > found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is > that a way , i can reduce this gate delay by giving some constraints. > ie is to reduce the gate delay by tools . > > In your .ucf file try something like this:- NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST; Or, better still, read the constraints guide. HTH., Syms.Article: 131005
Antti <Antti.Lukats@googlemail.com> writes: > On 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote: >> Antti <Antti.Luk...@googlemail.com> writes: >> > a DATA2MEM (elf to bit file merge) is VERY important for softcore >> > processors in FPGA's, and Altera kinda claims they have NIOS and >> > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their >> > toolchain!! >> >> You can get the same functionality using >> >> quartus_cdb --update_mif > to my knowledge YOU CAN NOT > > if Quartus has generated a bit file (programming file) > then this file (without access to the project database) CAN NOT BE > updated with new memory file, unlike it is possible with xilinx > data2mem tool If you have lost track of the source/project database (like the OP) you can not. But for the functional purpose where you run make on you NIOS software project and merge the generated mif/hex file into a new sof file without recompiling the project you can. I would disagree with you calling the former the most important tool for fpga-soc design. I would say that the latter is much more important. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 131006
On 8 Apr., 14:59, Petter Gustad <newsmailco...@gustad.com> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > On 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote: > >> Antti <Antti.Luk...@googlemail.com> writes: > >> > a DATA2MEM (elf to bit file merge) is VERY important for softcore > >> > processors in FPGA's, and Altera kinda claims they have NIOS and > >> > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their > >> > toolchain!! > > >> You can get the same functionality using > > >> quartus_cdb --update_mif > > to my knowledge YOU CAN NOT > > > if Quartus has generated a bit file (programming file) > > then this file (without access to the project database) CAN NOT BE > > updated with new memory file, unlike it is possible with xilinx > > data2mem tool > > If you have lost track of the source/project database (like the OP) > you can not. But for the functional purpose where you run make on you > NIOS software project and merge the generated mif/hex file into a new > sof file without recompiling the project you can. I would disagree > with you calling the former the most important tool for fpga-soc > design. I would say that the latter is much more important. > > Petter > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? Petter the all IDEA about the update is that you need 2 files 1) BIT file 2) ELF file and nothing else.. if based on those 2 files the elf can not be merged, then this is REALLY BAD!!! I dont know why Altera isnt understanding that. Xilinx is doing it for ages AnttiArticle: 131007
jamicrotech@gmail.com wrote: > Hi, > I am using virtex4 device for my designs. In timing analysis i > found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is > that a way , i can reduce this gate delay by giving some constraints. > ie is to reduce the gate delay by tools . Are your outputs synchronous with the output registers in the IOB? That's step 1. It sounds like you may have the FAST attribute turned on through I'm not as familiar with the V4 as the Spartan families. Double-check your pin report (pad report?) to verify your output has the I/O standard and FAST attribute you request. The next thing most designers consider is a DCM generated clock to effectively reduce the clock-to-out time. Getting onto the chip has delays. Getting off the chip has delays. There's no getting around the delays *but* you can compensate for some of this with the DCM. If your system clock is regular and reasonably jitter free, this is a superb way to go. If your system clock is irregular or subject to strong jitter hits, the DCM won't help but it's usable in most board designs. I'd suggest you dig far enough into any part datasheet before starting a design with the part to understand what the I/O timing should be to put together a system-level timing budget. If you have 5 ns periods with 4 ns clock-to out and 3 ns setup times, you may be starting with a non-solution. Since you already have your design, read up on how to use the DCMs and verify that the OBUF timing corresponds to what you would expect from the I/O numbers in the data sheet for that speed grade. If your outputs aren't registered with I/O registers, look into whether you can do that without otherwise crippling the design; it's the first tool to get good I/O numbers. - John_HArticle: 131008
Dear All, Austin in particular, I saw this and thought of you! Cheers, Syms. http://news.bbc.co.uk/1/hi/technology/7335322.stmArticle: 131009
Excellent, Would it be possible to have a bit more details on how to, just to ease my learning curve. Thanks. Luis C. Górski Adam wrote: > Hi, > > Yes, you can work with internal ram only. > Yes you can store program in configuration memory used for FPGA. > > I tested. > > AdamArticle: 131010
"Symon" <symon_brewer@hotmail.com> wrote in message news:ftfp5l$4go$1@aioe.org... > > <jamicrotech@gmail.com> wrote in message > news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com... >> Hi, >> I am using virtex4 device for my designs. In timing analysis i >> found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is >> that a way , i can reduce this gate delay by giving some constraints. >> ie is to reduce the gate delay by tools . >> >> > > In your .ucf file try something like this:- > > NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST; > > Or, better still, read the constraints guide. > > HTH., Syms. > > ...oh, and changing the drive strength will also affect the output delay. This can also be set by a UCF constraint. You've read DS302, right? HTH., Syms.Article: 131011
> Hi, > > Yes, you can work with internal ram only. > Yes you can store program in configuration memory used for FPGA. > > I tested. > > Adam Or you can store the program in internal RAM (functioning as ROM) too for a fully self-contained system. To make this easier, there is a mechanism to update the RAM initialization contents without needing to do a full re-synthesis and PAR each time. If you use SOPC Builder it is trivial to set this up.Article: 131012
- Just run SOPC Builder - make a system with nios ii , internall ram and for example port i/o. - generate system - put generated system into top schematic - build fpga image - load to fpga - run Nios ide - and have some fun That's all Adam > Would it be possible to have a bit more details > on how to, just to ease my learning curve. >> Yes, you can work with internal ram only. >> Yes you can store program in configuration memory used for FPGA. >> >> I tested.Article: 131013
Symon, Well, Cypress, Xilinx, IBM, and many others have made it no secret that neutrons at sea level are causing upsets, and we have done something about it (and presented the papers, and shown our results). Intel has also been working very quietly on this, with much less press. I suggest that if you are not thinking about single event effects, you should be, and demanding your vendor show you the proof of their design efforts in this regard. Virtex 5 is (as of today), 144 FIT/Mb for the config bits, 95% confidence interval from 100 to 200 FIT/Mb. This is from our 400 devices located on mountain tops in France (31.029 Giga-bit-years of test time, 35 events). Compare this to a 65nm ASSP or ASIC, which is at least 1000 FIT/Mb or 1000 FIT/million gates(!). Do nothing, and it gets worse. Do something, and it gets back to where it should be. These numbers from the SELSE II conference a few years back: the industry numbers are really a lot worse, but no one will admit it. There is a reason why Xilinx FPGA devices are finding their way into many high availability and high reliability applications: we are the only choice -- there is no competition whatsoever. AustinArticle: 131014
Antti <Antti.Lukats@googlemail.com> writes: > the all IDEA about the update is that you need 2 files > > 1) BIT file > 2) ELF file > > and nothing else.. if based on those 2 files the elf can not be > merged, then this is REALLY BAD!!! I can build my project and after that quickly build the hex/mif and merge it into the sof. Why do you think this is so bad? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 131015
"austin" <austin@xilinx.com> wrote in message news:ftg25m$p2m2@cnn.xsj.xilinx.com... > > Intel has also been working very quietly on this, with much less press. > Hi Austin, I wondered what were your thoughts on their patent where "The cosmic ray detector [built into the device] is therefore designed to spot when rays have caused interference and then tell the chip to repeat the command." ? I guess in an FPGA it could trigger a readback to ensure the device was still correctly configured and/or issue a user logic reset. Cheers, Syms.Article: 131016
On 8 Apr., 17:23, Petter Gustad <newsmailco...@gustad.com> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > the all IDEA about the update is that you need 2 files > > > 1) BIT file > > 2) ELF file > > > and nothing else.. if based on those 2 files the elf can not be > > merged, then this is REALLY BAD!!! > > I can build my project and after that quickly build the hex/mif and > merge it into the sof. Why do you think this is so bad? > > Petter > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? quit simple if you want to deliver a BITFILE only and allow the client to change the software but not the FPGA bit file itself. this is VERY simple with Xilinx tools and IMPOSSIBLE with Altera tools . How many times that needs to be explained? there is not even need to have all tools installed for bitstream update only the C compiler and merge tool AnttiArticle: 131017
On Apr 7, 8:15 pm, benn <benn...@hotmail.com> wrote: > I'm pretty new to fpgas, but theres an i2c core on opencores.org that > I'd like to use in my Altera project. I understand Wishbone is a > subset of Avalon, but what is involved in bridging these two together? > > I'm assuming its not too trivial since I could buy an IP bridge that > does it from Men Micro, but what exactly is involved if I were to try > tackling this myself? > > Thanks! It's not that tough. And a number of people have already done it, and published their work. Get familiar with niosforum and nioswiki. The answers are out there. G.Article: 131018
Symon, Well, that employee should be fired: that is the stupidest thing I have ever read. It isn't even science -- detecting neutrons! Pure BS! A neutron is an uncharged particle, that goes through 10 meters of concrete before it gets stopped. Detecting one is just......stupid.....idiotic..... (breathe in, breathe out.) Their PR folks are probably going nuts on this one! Was that April 1 dateline? Anyway, Intel is pretty savvy, and they are not standing still. If you use their parts, you need to request their Soft Error Effects roadshow. It is only given under NDA, so although I know it exists, and I suspect I know what is in it, I have never seen it. I have seen IBM's "show" and they certainly have their act together. As do we. IBM's "show" is under NDA, however, so I can't say anything about its contents. Our roadshow is available by request from your local friendly FAE, and it is no NDA is required (why would we hide we are the best?). Remember: per the JEDEC89A standard, there are three ways to characterize soft error effects. Be sure to ask which ones were used, and their degree of confidence. If they won't share this with you (under NDA), then they are hiding something, something very very bad. AustinArticle: 131019
Symon, First of all, there is no such thing as a single particle detector. Secondly, detecting the current spike (from a strike) requires a very complex circuit, itself subject to spikes (I know, we designed them for the USAF...) Thirdly, Intel has done far more than this, and deserved a better PR. Perhaps they should fire the PR firm? Austin Symon wrote: > "austin" <austin@xilinx.com> wrote in message > news:ftg25m$p2m2@cnn.xsj.xilinx.com... >> Intel has also been working very quietly on this, with much less press. >> > Hi Austin, > I wondered what were your thoughts on their patent where "The cosmic ray > detector [built into the device] is therefore designed to spot when rays > have caused interference and then tell the chip to repeat the command." ? I > guess in an FPGA it could trigger a readback to ensure the device was still > correctly configured and/or issue a user logic reset. > Cheers, Syms. > >Article: 131020
And, Yes, in S3A, S3AN, S3D, V4, V5 we are able to either reconfigure on detection of an upset, notify the user (and they decide what to do), or in V4 and V5, correct the flipped bit without having to reconfigure (or even go to the config flash/prom). Basically, in our road show, it is detailed how the user needs to decide what to do, and at what levels, in order to meet their availability and reliability numbers. Mitigation is part hardware, part system architecture, and part software. Depending on what you are doing, and how long you can tolerate being "off-line" there are different solutions. They are: -just reconfigure, start fresh -just fix the bit flip, continue on (as a flip does nothing 90% of the time, and seldom causes anything to 'crash') -fix the bit flip and reset or go back to a check point/known states -use dual redundancy, and check for agreement (if a fault is not tolerated - like in banking, accounting) repeat if no agreement -use full triple modular redundancy (when it must be correct, and 100% available), also scrub to fix bits that may flip so flips are not allowed to accumulate All methods are used by our customers, and they all work. We have reference designs and support for these models. And they can be tested by reconfiguring to flip bits while operating. One heck of a lot cheaper than using a proton beam, or neutron beam .... and more complete (we have folks who flip each bit, one by one, and prove their system meets its requirements). AustinArticle: 131021
"austin" <austin@xilinx.com> wrote in message news:ftg4j2$pop1@cnn.xsj.xilinx.com... > Symon, > > Well, that employee should be fired: that is the stupidest thing I have > ever read. > > It isn't even science -- detecting neutrons! Pure BS! A neutron is an > uncharged particle, that goes through 10 meters of concrete before it > gets stopped. Detecting one is just......stupid.....idiotic..... > Austin, Are you talking about the link I posted? I didn't see any reference to neutrons, am I missing something? Also, if what you say is true, that neutrons whizz through 10 meters of concrete, aren't you gonna be incredibly unlucky to get a direct neutron hit on a 45nm transistor? (BTW., A cursory web search would suggest some kind of boron based detector, which kinda makes sense as boron is used to absorb thermal neutrons in nuclear reactors. http://en.wikipedia.org/wiki/Neutron_detection) My rudimentary knowledge of cosmic rays is that they are not neutrons but mainly protons (and a few alpha and beta particles). I would expect them to be more detectable. Whatever, I'm confused now... Cheers, Syms.Article: 131022
Antti <Antti.Lukats@googlemail.com> writes: > if you want to deliver a BITFILE only and allow the client to > change the software but not the FPGA bit file itself. The client will still need the SDK and FPGA tools from the vendor. Or do you look at the bit-file as a method of protecting your HDL code from your customer? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 131023
At sea level, 93% of particles from the cosmic ray shower are neutrons, and 7% are protons (see JEDEC89A). There are 12.9 per square cm, every hour, passing through everything (for New York City, up to 25X more on mountain tops, 300X at 40K feet, less at the equator, 10X at the poles...). There are also electrons, muons, pions, and a host of more exotic stuff, but hose either don' matter (do not affect anything), or they are absorbed quickly, or decay (even a lone neutron decays in 11 minutes!). So, like I said, that is the dumbest PR I have read. It gets the first prize for ignorance about soft error effects. Some Real Science: http://www.xilinx.com/support/documentation/white_papers/wp286.pdf AustinArticle: 131024
On 8 Apr., 18:52, Petter Gustad <newsmailco...@gustad.com> wrote: > Antti <Antti.Luk...@googlemail.com> writes: > > if you want to deliver a BITFILE only and allow the client to > > change the software but not the FPGA bit file itself. > > The client will still need the SDK and FPGA tools from the vendor. > > Or do you look at the bit-file as a method of protecting your HDL code > from your customer? > > Petter > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? good god... how can it be that you dont understand... the ELF to BIT merge is much simpler than the cdb_mif update this is the reason why XILINX is doing it that way. this is how ALL FPGA vendors should do it, at least all FPGA VENDORS that offer soft-core solutions. sure its my opinion, but I am sure i am not the only one, who would like to see DATA2BIT tools (aka elf to programming file merge) for other FPGAs too, not only for Xilinx. Antti
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