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
"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:deC7d.330173$vG5.246020@news.chello.at...
>
> I could not find the 'Design Space Explorer' in Quartus. If you mean the
> Resource/Timeing Opt. Adviser under 'Tools' than I'm in bad luck. This
> function is not available with the web edition of Quartus.
>
Hi Martin,
The easiest way to use the DSE is to go the project directory, and type
1. quartus_sh --dse
If you want help on this feature type
2. quartus_sh --help=dse
Please make sure that the quartus\bin is in your path.
Additional information is available in the Quartus handbook at
http://www.altera.com/literature/hb/qts/qts_qii52008.pdf
Here is the header from the help when you type in quartus_sh --help=dse
THE ALTERA DESIGN SPACE EXPLORER (DSE)
The Design Space Explorer (DSE) is a tool for exploring the
complex flow parameters in the Quartus(R) II software. DSE takes
the "guess work" out of selecting parameter values and exposes
the optimal Quartus II software settings for a design.
VERSION
2.1
SYNOPSIS
Usage: quartus_sh --dse [options]
Options:
-nogui
-project <project name>
-revision <revision name>
-seeds <seed list>
-llr-restructuring
-exploration-space <space>
-optimization-goal <goal>
-search-method <method>
-custom-file <filename>
-stop-after-gain <stop-after-gain value>
-stop-after-time <stop-after-time value>
-ignore-failed-base
-archive
-run-assembler
-slaves <slave list>
-use-lsf
-slack-column <column name>
-help
Note: To use DSE in command-line mode, specify the "-nogui"
option. If you do not specify this option, the DSE graphical
user interface (GUI) starts, regardless of the other
command-line options used.
EXAMPLES
quartus_sh --dse
This command launches the DSE GUI.
quartus_sh --dse -nogui -project main
This command starts a default command-line exploration. The
default seeds are used along with the default exploration
space, optimization goal, and search method.
quartus_sh --dse -nogui -project main -seeds 2,4,8-10
-exploration-space "Extra Effort Search"
This command starts a command-line exploration of an
"Extra Effort Search" space using the seeds 2, 4, 8
through 10, the default optimization goal, and the default
search method.
.............................
Hope this helps.
Subroto Datta
Altera Corp.
Article: 74051"Kolja Sulimma" <news@sulimma.de> wrote in message news:b890a7a.0410021025.23160984@posting.google.com... > "Antti Lukats" <antti@case2000.com> wrote in message news:<cjlt48$uvo$01$1@news.t-online.com>... > > > Antti Lukats wrote: > > > I could be wrong, but I thought open source cores that run uCLinux were > > > already available for FPGAs. The only difference is that this one is > > > code compatible with uBlaze. Am I wrong about this? > > > > Yes, if there would be similar reference platform for OR1100, but it is not > > available. LEON is real nice system, but the ref system hardly fits into > > XCV2000 !! > LEON is an implementation that is focused on a radiaton hard operation > of an architecture (SPARC) that was designed for ASICs. > Whereas MB is an architecture that was optimized from the beginning > for a small FPGA implementation. There will never be a SPARC > implementation that will get the same performance per LUT as MB does. > AFAIK the OR1k architecture also is not optimzed for FPGA > implementation and is therefore rather large. > > So I think it is great to see an open source implementation of MB. > Can you comment on how many LUTs your implementation requires? > Also: You mention on your web site that some instructions are not > impleneted. Which instruection are these? > > Kolja Sulimma First: its not my implementation at all, I am just trying to find some funding for the original author, actually openchip is already sponsoring the project a little Device utilization summary: --------------------------- Selected Device : 2v1000fg256-5 Number of Slices: 614 out of 5120 11% Number of Slice Flip Flops: 347 out of 10240 3% Number of 4 input LUTs: 972 out of 10240 9% Number of bonded IOBs: 34 out of 172 19% Number of BRAMs: 4 out of 40 10% Number of GCLKs: 1 out of 16 6% Timing Summary: --------------- Speed Grade: -5 Minimum period: 8.573ns (Maximum Frequency: 116.645MHz) The above includes 256 words distributed ROM CPU itself is even smaller. The current release does not have any optional instructions what as such is not a problem. There is also no interrupt implemented yet, so that is biggest issue at the moment for the uCLinux at least, but I have done pretty many useful Microblaze design without using interrupts so its not useless at all. I just did make a example test implementation similar to xilinx ultracontroller, ie bram on dataside and bram other side to gpio and I would say that open source MB could be very nice ultracontroller-lite already at this stage of development! And being so tiny and being supported with GNU toolchain its a nice beastie ! Ha, I see Martin has also already responded, for I just offered to donate my acex jopcore PCB to the MB designer, so it goes for good cause at last! And for others too, if somebody has some FPGA development board, the open-source microblaze author does not have *any* FPGA hardware to test with at all, all the work is done with plain testbenching using free verilog simulator - so if there is some overleft FPGA board (preferable suitable for uCLinux i.e. with rs232 and at least 4MB RAM) please consider donating it for the open-MB/uCLinux project. I am not asking it for myself, I have most of the boards I want (except that I am looking for MAX2 devboard) - unfortunatly i dont have so much suitable boards for donation myself (what I have overleft I have already promised to give away to the project) Antti RE: LEON/Sparc and OR1K, yes both are HUGE !! OR1K with only UART and all stuff stripped out is 77% of V2-1000 I dont have stripped out LEON synth but its possible even larger. same for nnARM its huge as well :( so as for the moment the open-MB is the smallest free-open IP-core with "proven" gnu toolchain support I would say, or does some better alternative exist ??Article: 74052
"Christian E. Boehme" wrote: > > B. Joshua Rosen wrote: > > > You can put a constraint from anything to anything in the UCF file. > > Not quite. I had a similar problem with a high frequency clock input > that is divided down inside the CPLD and the low freq clock distributed > to all flipflops on a global clock net. Added a NET "<low-freq-clock-name>" > BUFG = CLK; constraint to the UCF but it's appily ignored and doesn't even > appear in the constraints editor (the comments, however, do appear). I am > using the ``free'' tools that come with the ISE 6.2i WebPack, BTW. > > > You can also put period constraints on all of your clocks. Read the CGD manual. > > I did but that did not help too much as explained above. I'm not sure what you are saying. But if you put a clock period constraint on a net, it may not be used if the signal does not pass through a BUFG. Have you checked to see if a BUFG was used for this internally generated clock? -- 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: 74053
austin wrote: > > Rick, > > Configuration of a test pattern can make efficient use of our partial > reconfiguration capabilities. I can not say how many seconds an FPGA > spends in the tester, but it is less that an ASIC does. There also may > be much faster ways to configure that we can use, but do not offer to > customers. Austin, if you don't know how much time it takes to test your FPGAs, then how can you possibly say it is faster than an ASIC that you also don't know the test time for??? I think you and Peter are talking through your hats on this one. Much like the other arguments that FPGAs are better than ASICs that pretty much ignore the fact that an ASIC can be done using several generations older technology to get the same overall costs. Your 90nm chips may be very dense, but they are using the most expensive equipment around and automatically have a 10:1 hit in most areas of cost. > Why can we do 1,000's of BIST patterns faster? Well one obvious reason > is that a BIST pattern in a FPGA can run at the speed of the FPGA, which > is often 10X to 100X faster than the tester. It might have to run for > 1000 clocks to finish, and then go on to the next test, which might be > different by the contents of a few LUTs. > > If you are really curious of how we perform this magic, you can research > all of our BIST patents and think about what you would do if you faced > such a problem. > > Again, Peter is right. I am sure Peter is right about a lot of stuff. But you don't provide any information that shows he is right about this. -- 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: 74054
austin wrote: > > Rick, > > Bad hair day? Austin, Peter sends me private emails asking me to ignore your nonsense. He tells me you are a valuable asset to this group because you have significant knowledge. But your BS is enormous. This comment is the sort of thing that is not welcome in the group, at least by me. If you want to discuss the issues, then leave the crap at home. I find you to be a very unprofessional representative for Xilinx and I have even told my local sales people that. I don't know if this ever makes it back to your managers, but I sincerly hope that I never have to depend on you for any sort of support. In fact, you personally are one of the reasons that I keep looking at the solutions offered by Altera, and have ended up filling at least one of the sockets on our boards with an Altera part. > Answers below, > > Austin > > rickman wrote: > > Austin Lesea wrote: > > > >>Jon, > >> > >>Peter is right: ASIC testing rarely gets more than 95% coverage. The > >>best is about 98% coverage. > >> > >>We can get an arbitrarily high coverage by just increasing our patterns > >>(99.9%+) for 0 added silicon cost. ASICs can not do that. > > > > > > But as Peter pointed out, silicon cost is not the only variable cost. > > The longer testing adds to the unit cost just as larger silicon does. > > > > Completely different costs. You can not change silicon every week, but > you can change BIST patterns. Patterns can be improved continually, > which drives down costs. Your reply is a non-sequitur. No one is talking about changing silicon. The tests are data that are used to drive the signals to the chip and examine the outputs from the chip, be it an FPGA or an ASIC. The cost of silicon is the cost of making the chip which is a function of silicon area among other things. As has been pointed out, the silicon area gives ASICs a 10:1 advantage in cost that part of the cost. > >>To get any better, they either have to add more logic for BIST (30%+ of > >>a Pentium IV is BIST logic) which increases area and cost and decreases > >>yield, or just be happy with the coverage of the scan chain (which is > >>not all that good). > > > > > > Nonsense. There are design techniques to measure testability to allow > > as high testing coverage as is required by improving the test. If there > > is no way to determine a fault in a node, then by definition, it won't > > affect the operation of the chip! Any fault that makes a difference in > > chip operation is observable, the only question is how to stimulate the > > chip to detect it. That is a well understood problem. > > > > So 98% is as good as you get in an ASIC, and we can get an arbritrariy > higher coverage with no silicon area penalty. Then we can take our time > to improve the patterns till they take very little time to run. Where did you come up with the 98% figure??? Test coverage is a function of the test, not of the chip or the technology used to make it. > What does "unobservable" error have to do with this? I am talking about > that last 2% of errors that ASICs do not catch, and could be observable > (if they took infinite time, and infinite resources). Why would it take an "infinite" amount of time and resources? The only limiting factor is the cost of testing vs. the cost of missing a fault. > >>Each BIST or scan chain is unique, and software, test vectors, etc. muct > >>be developed each time anything is new or different. > > > > > > Yes, but that does not mean excess test development time. Much of this > > process is automated. > > > > True, but then you have to see what the automation missed. The software *measures* the coverage that the tests provide. What are we not communicating? > >>FPGAs have 0% extra area for BIST (they are 100% BIST with a different > >>bitstream!). > > > > > > No, by definition an FPGA has extra area for BIST, that is what makes it > > an FPGA, all the *extra* stuff in it!!! What is the area overhead for > > an FPGA vs. an ASIC; 10X, 20X? Even if you build an ASIC that is two > > generations back such as 150 nm vs. 90 nm, the ASIC will be smaller, > > faster and therefore cheaper. > > > > > > Unfair. ASICs do have fewer transistors to do the same job, but do not > then use the fact that FPGAs have more to justify that ASICs have a > better approach to testing: they do not. > > A certain very lasge ASIC manufacturer might be adding FPGA cores to > their ASICs, not for any direct customer benefit, but because it might > be easier and cheaper with more coverage to test them that way. I have no idea what you are talking about. An ASIC has a 10:1 silicon area advantage over FPGAs. I never said they have a "better" approach to testing. I simply said that you only have to test an ASIC to the specific requirements it was designed to. An FPGA must be tested to assure that all the many different potential designs will work. I have also acknowledged that an FPGA can be custom tested to the specific ASIC-like design a given customer may have for it. But then you are doing the same tests that they do on the ASIC. > >>You must understand that the 405PPC, MGT, DCM, and other "hardened IP" > >>are just like ASICs, so we already know everything there is to know > >>about ASICs, their design, and testing. In fact Xilinx the 3rd largest > >>'ASIC' manufacturer in the world (behind IBM and NEC -- > >>Gartner/Dataquest 'ASIC/FPGA Vendor Ranking 2003'). > >> > >>FPGA vendors may be the last stronghold of full custom ASIC design left > >>in the world. ASIC houses are mostly standard cell, or structured > >>(basically same thing), with little or no full custom. > >> > >>Our customers tell us that if they want to play with the latest and > >>greatest technologies and designs (like 10 Gbs MGTs), they need to use > >>our FPGAs, because the ASIC cells are a generation behind. > > > > > > How is using the "latest and greatest technologies" an advantage when it > > comes with a 10X area premium??? > > Well, first off, the ppc, mgt, etc have no area (or cost) premium. In > fact some would consider them free. Does Xilinx consider them free? I doubt it. > And the 'premium' you claim for FPGAs must not be much, as we keep > selling them for less $$, and have more features with each generation. So an FPGA sells for the same unit cost as an ASIC? Too bad my local sales office has not learned about this. They keep quoting me FPGA prices! -- 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: 74055
Martin Schoeberl wrote: > > > Ha, I see Martin has also already responded, for I just offered to > donate my > > acex jopcore PCB to the MB designer, so it goes for good cause at last! > > > Hi Antti, > > that's really nice (and funny) how much used this single board gets ;-) > And a MB on an Altera FPGA, that's the end of the world. > BTW: I have some more ACEX boards. I could donate them (or a small fee..) > for projects that can convince me... I am looking at prototyping boards for a CPU in an ACEX 1K50. Do you have anything with that chip? How much would you want for it? -- 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: 74056
Antti Lukats wrote: > > Ha, I see Martin has also already responded, for I just offered to donate my > acex jopcore PCB to the MB designer, so it goes for good cause at last! > > And for others too, if somebody has some FPGA development board, the > open-source microblaze author does not have *any* FPGA hardware to test with > at all, all the work is done with plain testbenching using free verilog > simulator - so if there is some overleft FPGA board (preferable suitable for > uCLinux i.e. with rs232 and at least 4MB RAM) please consider donating it > for the open-MB/uCLinux project. > > I am not asking it for myself, I have most of the boards I want (except that > I am looking for MAX2 devboard) - unfortunatly i dont have so much suitable > boards for donation myself (what I have overleft I have already promised to > give away to the project) If the project needs a board, what exactly do they need? I belive there is a Spartan 3 dev board for $100. I would be willing to spring for one of those if that would do the job. -- 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: 74057
Nicholas Weaver wrote: > > In article <415E3568.DEA2A396@yahoo.com>, rickman <john@bluepal.net> wrote: > >BTW, that brings up the issue of RAM cell size. I recall that Mosys has > >a 1T sram cell using a single transistor and a capacitor. This sounds > >like a DRAM to me. Anyone know how this works? To the best of my > >knowledge it does not require any refreshing or is that somehow done > >invisibly? They don't call this peusdo-SRAM and I believe they have > >some patents on it. > > It is Pseudo-SRAM: It provides an SRAM interface, and hides the > refreshing process, but underneeth it all, its a small bank fast DRAM > design. Do you know this *specifically* about the Mosys design? Exactly how do they work the refresh into the ram without disturbing the timing? These are not asynch parts, but synch parts running at up to 200 MHz IIRC. -- 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: 74058
rickman wrote: > austin wrote: > >>Rick, >> >>Bad hair day? > > > Austin, Peter sends me private emails asking me to ignore your > nonsense. He tells me you are a valuable asset to this group because > you have significant knowledge. But your BS is enormous. This comment > is the sort of thing that is not welcome in the group, at least by me. > If you want to discuss the issues, then leave the crap at home. I find > you to be a very unprofessional representative for Xilinx and I have > even told my local sales people that. I don't know if this ever makes > it back to your managers, but I sincerly hope that I never have to > depend on you for any sort of support. In fact, you personally are one > of the reasons that I keep looking at the solutions offered by Altera, > and have ended up filling at least one of the sockets on our boards with > an Altera part. Whoa, Lighten up guys! Austin may not be destined for a job in the diplomatic corps, but he does provide useful information. I believe any discussion that tries to place ASIC and FPGA testing in the same pigenhole is going to founder. Yes, ASICs are smaller, but FPGAs can use their own fabric for testing. Sure, FPGAs use more expensive process, but does the end user care what process their chips use ? FPGA vendors have a very stong impetus to get very good at test coverage, whilst to the average ASIC user, testing is not given the same engineering resource. Thus it really is comparing apples and oranges. -jgArticle: 74059
"Mike Delaney" <mmdst23@pitt.edu> wrote in message news:eb4ab45b.0410021519.4bda26d9@posting.google.com... > As part of a signal processing design I'm working on (I was given > C/Matlab code, and told "go make it hardware"), I need to calcuate > log(1+B^d). So far, I've found some information on CORDIC and 2 > software approximations. I need to do this in 32 bit floating point, > and the requirements call for "as much accuracy as you can get" as no > one has been able to figure out how much we really need yet. There's > also a large possible difference betwen the biggest and smallest > numbers that are used in this calcuation, so using some fixed-point > system is most likly more work then it's worth. > > I'm thinking that I could calcuate B^d as e^(d * LN(B)), since I'm > hoping that whatever way I end up using to find log(x) can be reversed > to find e^x as well. > > The approximations I've found so far have all been software based, and > didn't seem that accurate (about 5 or so decimal digits when tested in > Matlab). It also seems like taking the iterative/software-based > approach is the wrong way to go, and could easily lead to the log/exp > unit needing over a hundred cycles to execute. The two approximations > I've looked at are the one from glibc and the one used in the VHDL > Real Math package. > > CORDIC seemed more promising at first, but it looks like it's not > widly used for floating point. However, I haven't been able to find > any deatails on what other methods might be better. > > Can anyone suggest a better way? Are there any approximations that > are more hardware then software based? Or would I be better off > either using one of them, or CORDIC? > > Thanks, > Mike This doc has some interesting ideas. They are not meant to be synthesizable, but can be made so easily. http://www.cse.lehigh.edu/~caar/marnold/papers/sanjose_hdlcon.doc You should mention your clock rate and how many cycles you have. If you've got lots of time, you can use an embedded processor. The hard part is doing everything quickly. Lookup tables can be done easily with the deep Xilinx ROMs. What precision is required? Do you really need floating point? Can you normalize the radix points by successive single shifts, or do you need a barrel shifter? The Taylor approach is very good if you have an embedded multiplier and if you have several cycles you can reuse the same multiplier. Use the Horner algorithm to reduce the number of multiplications required. -KevinArticle: 74060
> > that's really nice (and funny) how much used this single board gets ;-) > > And a MB on an Altera FPGA, that's the end of the world. > > BTW: I have some more ACEX boards. I could donate them (or a small fee..) > > for projects that can convince me... > > I am looking at prototyping boards for a CPU in an ACEX 1K50. Do you > have anything with that chip? How much would you want for it? > Yes, the boards are with the ACEX 1K50. Is EUR 75,- ok? MartinArticle: 74061
> Martin- It makes sense that integrating ram replacing external memory would > reduce pin count etc, the confusing part of your message is realted to this > thread being NV memory oriented. Do you want your 128KB on chip memory > truly for ram or for code storage? Does that relate to the NV aspect of the > discussion for those low density devices you mention? > -cheers It does not direct relate to the NV aspect, but Paul was talking about the SRAM contained in an FPGA. So I throwed in my larger SRAM wish. For code memory I'm happy with larger serial Flash chips when I can access them from the FPGA. Here the pin count is not so problematic and I know Flash integration is problematic from the technology point. Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/ > > "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message > news:pIF7d.330373$vG5.20442@news.chello.at... > > > Incorporating extra functionality in an FPGA is usually done because it > > > provides some additional advantage beyond absorbing external > > components. > > > Let's look for a second at incorporating volatile RAM. Altera clearly > > > thinks it is worth including medium-sized SRAM blocks (hence the 512 Kb > > rams > > > in Stratix and Stratix II). Designs often require one or two large > > RAMs > > > (off-chip) for long-term data storage, and a few medium RAMs for > > buffering > > > > I would like to add my 'wish-list' for an FPGA: > > As I'm working with processors in FPGA I always need external SRAM: > > costing money, PCB space, routing troubles, more pins... > > I would like to see more SRAM on-chip. I don't need it as super-fast > > dual-ported block RAMs. I would be happy with a single port 10-20ns > > access RAM, but larger. Let's say 128KBbytes (not bit) to 1MB in > > EP1C3-EP1C12 devices. When the system memory is integrated I will vote > > for smaller packages: tqfp100 or even tqfp44. The idea is the same as for > > microcontrollers in very small packages. > > And an open documentation (not only as feature in NIOS) how to write to > > the serial config Flash from within the FPGA. > > > > my 2c > > Martin > > ---------------------------------------------- > > JOP - a Java Processor core for FPGAs: > > http://www.jopdesign.com/ > > > > > > > >Article: 74062
"Martin Schoeberl" <martin.schoeberl@chello.at> skrev i meddelandet news:KvC7d.330190$vG5.63863@news.chello.at... > > LEON is an implementation that is focused on a radiaton hard operation > > of an architecture (SPARC) that was designed for ASICs. > > It is designed for radiation hard per se? Isn't it just an open source > SPARC. > Do you knwo how to design for radiation hard applications, especially in > an FPGA? > Redundant structures and hoping that the synthesizer does not detect them > and optimize it away... > > Martin > The Leon project was funded by the European Space Agency, and the goal was to produce a radiation hardened processor for their Satellites controllers. The rad hardening does not have any effect on the VHDL code AFAIK -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 74063
"Antti Lukats" <antti@case2000.com> wrote in message news:<cjmtqd$3uh$03$1@news.t-online.com>... (OpenCores Microblaze Implementation) > Device utilization summary: > --------------------------- > Selected Device : 2v1000fg256-5 > Number of Slices: 614 out of 5120 11% > Number of Slice Flip Flops: 347 out of 10240 3% > Number of 4 input LUTs: 972 out of 10240 9% > Number of bonded IOBs: 34 out of 172 19% > Number of BRAMs: 4 out of 40 10% > Number of GCLKs: 1 out of 16 6% > > Timing Summary: > --------------- > Speed Grade: -5 > Minimum period: 8.573ns (Maximum Frequency: 116.645MHz) > > The above includes 256 words distributed ROM CPU itself is even smaller. So the Open Cores implementation is even smaller than the original and not much slower? Good work. KoljaArticle: 74064
"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:<KvC7d.330190$vG5.63863@news.chello.at>... > > LEON is an implementation that is focused on a radiaton hard operation > > of an architecture (SPARC) that was designed for ASICs. > > It is designed for radiation hard per se? Isn't it just an open source > SPARC. Yes and no ;-) The standard version is just an open source SPARC, but it was designed by ESA with radiation hard ASIC implementations in mind. Therefor it is not optimized for FPGA area and not even for ASIC area but for reliability. Also, there is a version with redundancy available. > Do you knwo how to design for radiation hard applications, especially in > an FPGA? > Redundant structures and hoping that the synthesizer does not detect them > and optimize it away... Either faith as you suggested or keep attributes. Also, you do not need to replicate the whole datapath but you can use error detection codes to reduce the logic overhead. At least for some functions the logic to calculate (in the simplest case) the parity of the result is much smaller than computing the result and then the parity of it. Kolja SulimmaArticle: 74065
> > i need to implement gigabit ethernet in FPGA.. > > now all is almost done (MAC in FPGA , PHY), and need to implement a simple > > protocol that will ensure proper delivery of all data from digital camera (1 > > picture = 128MB). I thought about IP/UDP and own protocols with handshake > > and retransmition of lost packets, but maybe there exists something > > simpler - already used and implemented protocols - i just need to make > > programmer's life easier at the other end of cable:) > > > > At that point you might as well use TCP... implementing TCP is not > that hard if you don't care about super-high performance across very > long distances. The problem is, that i need to have transfer about 70MB/s I thought about TCP/IP and it really doesn't look so bad..The CRC calculation can be done in hardware on fly and the rest implemented using 8bit microcontroller,that i already have in design or NIOS. > > See for example uIP or lwIP for small TCP/IP stacks that can be run on > a small microcontroller which can easily be synthesized in an FPGA. > > If you want to use UDP or raw Ethernet packets you probably want to do > something like TFTP. > Thanks, i will have a look for it.Article: 74066
ei anyone can help me with the algorithm on how to control a servomotor... cause we are gonna use it on our thesis... by the it's called "FPGA based intravenous infusion monitoring and control system" can anyone help us out on how to control a servomotor...will be using the servomotor to clamp the tube of an I.V.(intravenous) tube... the flow of the algorithm will bw this... first a personnel will input how many dosage a patient gets and then the servomotor will clamp the I.V. tube so that the desired dosage is achive... by the way will be using optical sensors to monitor the drops of the I.V. fluid i will be placed at the outside of the drip chamber... but we have a problem what if the drip of the fluid change how will the servomotor adjust it so that the dosage will be maintained...will use a feedback but how are we gonna implement it on FPGA.. got any suggestion on the algorithm... or any sites that can help us solve this problemArticle: 74067
Occasionally, I've discovered that the result of synthesis (default effort)
depends on the instances order. I can bring a complete example but in short
the illustration is following:
-- 24 LUTs
architecture RTL is
begin
U1: entity ..
U2: entity ..
-- 27 LUTs
architecture RTL is
begin
U2: entity ..
U1: entity ..
This fact complicates comparition of different design configurations. Is it
normal? I've checked Synplify -- it always gives the same results
irrespecively to the units order.
Article: 74068Mike Delaney wrote: I've already implemented these for the VHDL-200x. http://www.eda.org/vhdl-200x/vhdl-200x-ft/files.html Take a look at "fphdl_base_alg_pkg.vhd", in floating point. You will also find synthesizable fixed and floating point packages here. Please give them a try, we need more people pounding on this code. These series are debugged and working, but not optimized, which is why they are not being made part of the standard. > Does anyone have any suggestions on how to do Logs and Powers? > Part of the design I'm working on has "log(1 + B^d)", and we're pretty > much stuck there. > So far, the ideas being kicked around are to either use the Taylor > series (I'm not the biggest fan of this), or to try to use CORDIC. > I haven't found any free/open IP that looked like it would work, the > closest being a couple of (fixed-point) CORDIC cores from Open Cores. > Accuracy and speed are the two main concerns, but memory is tight, so > I don't know if a lookup table is doable. Are there any other > approximations that might work, and might be easier to implement using > floating point? And how do the hardware implementations in some FPU's > work? > > Thanks, > MikeArticle: 74069
"Hal Murray" <hmurray@suespammers.org> wrote in message news:i56dne1Ozfe12MPcRVn-vw@megapath.net... > You might get down to 2 cycles by using the other edge of the clock > for WE and putting it in the middle of the pair. OE would go on the > second cycle. (Probablby work fine in the middle too - bus would > just float a half cycle.) Indeed, is the technique I used in the XSOC/xr16 interface to async SRAM (http://fpgacpu.org/papers/xsoc-series-drafts.pdf page 19 and 24), where I demonstrate how to issue two back to back writes, each in 3 clock edges (1.5 clock cycles), total 3 cycles. Jan GrayArticle: 74070
Martin Schoeberl wrote: > > > > that's really nice (and funny) how much used this single board gets > ;-) > > > And a MB on an Altera FPGA, that's the end of the world. > > > BTW: I have some more ACEX boards. I could donate them (or a small > fee..) > > > for projects that can convince me... > > > > I am looking at prototyping boards for a CPU in an ACEX 1K50. Do you > > have anything with that chip? How much would you want for it? > > > Yes, the boards are with the ACEX 1K50. Is EUR 75,- ok? The price sounds good. Where can I get some info on these boards? -- 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: 74071
Geoffrey Wall wrote:
> i am trying to implement an image convolution filter that has negative
> values in it on a spartan IIe fpga.
> So i need to perform (for instance) A*B + C*D where A,B,C,D are all signed
> numbers in the ieee std logic int range.
> what is the best way to implement this? It seems that the way i am doing it
> now (using std_logic_vector) fails for negative values of the filter coeffs.
> can anyone give a suggestion how to fix this (the best way to code it in
> vhdl). What is the best way to do a numerical comparison (ie. A < B in vhdl
> (that is also synthesizeable), where A,B are signed integers)
Use the "numeric_std" type "signed" to represent the numbers. Then
multiply them together.
Same thing, just use the "<" out of numeric_std. Like this:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
....
signal A, B, C, D : signed (3 downto 0);
signal ab, cd, abcd : signed (7 downto 0);
....
multp : process (clk) is
if rising_edge (clk) then
if (reset = '1') then
ab <= (others => '0');
cd <= (others => '0');
abcd <= (others => '0');
else
ab <= a * b;
cd <= c * d;
abcd <= ab + cd;
end if;
end process multp;
Because these are signals and not variables, none of the results will be
evaluated until the "end process" is hit. Thus you have a nicely build
in pipeline. You can add variables if you want more pipeline delays.
Trick with Xilinx parts. Use a synchronous clear, not an asynchronous
one when writing this code. The Spartan IIe does not have build in
multipliers, but you need to do this or they won't be inferred in parts
that have them. There are 3 pipeline delays in each of these multipliers.
Article: 74072Followup to: <cjos65$56p$1@news.onet.pl> By author: "greg" <xgrzes@poczta.onet.pl> In newsgroup: comp.arch.fpga > > > > At that point you might as well use TCP... implementing TCP is not > > that hard if you don't care about super-high performance across very > > long distances. > > The problem is, that i need to have transfer about 70MB/s > I thought about TCP/IP and it really doesn't look so bad..The CRC > calculation can be done in hardware on fly and the rest implemented using > 8bit microcontroller,that i already have in design or NIOS. > If so, you really want to either: a) Just to full-blown TCP, using your microcontroller or NIOS (Altera has a fairly nice low-overhead TCP/IP library for NIOS, too.) b) Use a "windowed spew" protocol; effectively TCP without the congestion control. Just spew a bunch of sequenced-number packets out the wire, and expect to get an ACK back clearing all packets up to the packet specified. The big issue with ANY of these protocols is how much buffer memory do you devote to it: you want to have enough buffer memory that you can send at least ~2 roundtrips worth of data before you have to stall until your ACK gets back. > > See for example uIP or lwIP for small TCP/IP stacks that can be run on > > a small microcontroller which can easily be synthesized in an FPGA. > > > > If you want to use UDP or raw Ethernet packets you probably want to do > > something like TFTP. > > > Thanks, i will have a look for it. Using a ping/pong protocol like TFTP would be an absolute performance killer in your application. -hpaArticle: 74073
Hi I am working EMAC and PHY on a Virtex II board. I have the EMAC core and phy integrated on the board through .mhs file. I am able to compile the core adn synthesize the project. I am using EDK 6.2. Now I am working Xilinx low level drivers that provided functionality of fifo, DMA, read\write and loopback (selftest). within my code I am calling EMAC drivers functions and able to successfully initialize the device but the emac self-test Fails (specifically the loopback test), did anyone had this problem before with the xilinx drivers? any suggestions and help would be appreciated. thanks MIke K Farmingdale EDUArticle: 74074
Hi I would like to quote Martin Schoeberl: "And a MB on an Altera FPGA, that's the end of the world." Well the end of the world must then be TODAY? MB is working in Cyclone FPGA, screenshots available: http://uclinux.openchip.org/forum/viewtopic.php?t=11 some comments - the program that is running in the FPGA is compiled using GPL GNU toolchain so there can be no legal issues with that type of useage. If something is GPL you have rights to use it and give away for free. So using GPL GNU toolchain for M*Blaze Cyclone implementation is defenetly allowed use. Xilinx licensing and restrictions apply only to the MicroBlaze netslist, source code and reference design and other documentation that is released under different licenses. a funny thing is that Xilinx ISE/EDK that are using GNU and GPL stuff as much as I can see the GPL license text is not shipped with EDK distribution, what itself is violation of the GPL license ASFAIK ?, well maybe I was blind and the GPL license is somewhere hidden. Altera OTOH *does* comply with 3rd party licenses and included copies of the relevant licenses with Quartus/SOPC builder. the M*Blaze/uCLinux has already received first donation offers, but more donations are welcome of course, specially in form of FPGA development hardware. Antti PS I am not the author of the open-source M*Blaze, neither is the M*Blaze IP-Core downloadable from openchip, the primary download location for the M*Blaze IP-Core is the opencores website, project name aeMB.
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