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
First Call for Papers
2002 MAPLD International Conference
Kossiakoff Conference Center
The Johns Hopkins University - Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, Maryland 20723-6099
September 10-12, 2002
Abstracts are now being solicited for the 5th annual MAPLD
International
Conference. Programmable devices and technologies, as well as digital
engineering and related fields, will comprise the major emphasis of
this
Conference geared towards military and aerospace applications.
The Technical Program will consist of oral and poster technical
presentations and Industrial and Government Exhibits. We are planning
an exciting program with presentations by Government, industry,
academia,
and consultants, including talks by select Invited Speakers. Select
papers will be published in the AIAA Journal of Spacecraft and Rockets.
This conference is open to US and foreign participation and is
unclassified. For conference information, please see the
http://klabs.org.
We are especially interested in papers emphasizing design and analysis
techniques with respect to reliability and fault tolerance,
high-performance, and low power for digital circuits. Papers on
state-of-the-art military and aerospace applications and ‘lessons
learned’ are also strongly encouraged. As in past years, we expect a
large number of papers on programmable logic, digital engineering, and
components. We will continue our series of Invited History Talks.
Birds-of-a-Feather Sessions: For the first time, at 2001 MAPLD
International Conference, a "birds-of-a-feather" session on
reconfigurable computing was held. The BOF sessions will continue as
an MAPLD feature, and we are soliciting proposals for such sessions.
If you would like to lead a session, please submit your idea with
session title, a brief description, and contact information to
mapld2002@klabs.org.invalid.
Seminars and Tutorials will be again be offered (with a separate
registration). Seminars and tutorials will be on September 9th, 2002.
Topics include (but are not limited to) the following:
Design and Analysis
CPU
Logic
Low-Power Techniques
High-Speed Techniques
Applications
Military (Ground, airborne, artillery, etc.)
Spaceborne
Arithmetic and Signal Processing
Encryption Systems
Devices
Advanced Devices, Technologies, and Software and Their
Impact on Critical System Reliability
Programmable Technologies and State-of-the-Art Devices and
Programmable Elements
Device Architecture
Systems and Software
System-on-Chip
Software Tools for Design/Analysis - HDLs, Synthesis,
Design Entry Systems
Translation from High Level Languages
Intellectual Property
Reliability
Experience and "Lessons Learned" from Mission Experience
Radiation Effects, Device Reliability and Element
Characteristics
Fault Tolerance
Use of COTS Devices in the Military and Spaceflight
Environment
Testing and Analysis Techniques
Advanced Packaging including Known-Good-Die, MCMs, and
chip-scale packaging.
Adaptive Computing Systems
Evolvable Hardware
Reconfigurable Computing
The conference is sponsored by:
NASA Goddard Space Flight Center
JHU/Applied Physics Laboratory
National Security Agency
Electronics Radiation Characterization Project
Digital Engineering Institute
Military & Aerospace Programmable Logic Users Group
American Institute of Aeronautics and Astronautics
IEEE Aerospace & Electronic Systems Society (AESS)
Air Force Research Laboratory
For more conference information, please see the MAPLD pages
on http://klabs.org or contact:
Richard Katz - Conference Chair
NASA Goddard Space Flight Center
mapld2002@klabs.org.invalid
Tel: (301) 286-9705
Alan W. Hunsberger - Conference Co-Chair
National Security Agency
awhunsb@afterlife.ncsc.mil.invalid
Tel: (301) 688-0692
Ann Darrin - Conference Co-Chair
Johns Hopkins University
Applied Physics Laboratory
ann.darrin@jhuapl.edu.invalid
Tel: (240) 228-4952
Tanya Vladimirova - Conference Co-Chair for the AIAA
Journal of Spacecraft and Rockets.
University of Surrey
T.Vladimirova@ee.surrey.ac.uk.invalid
+44(0)1483 879137
Conference Co-Chair, European Liaison
Hans Tiggeler
hans@klabs.org.invalid
Abstracts should be approximately 2 pages long. Please send abstracts
to mapld2002@klabs.org. Your abstract must be in an attached file,
named using this format: LastName_A.ext - where last name is the name
of the first author - e.g., Katz_A.txt. Please include first author
information for point of contact (name, affiliation, phone number, and
e-mail address). All abstracts must be unclassified.
Abstracts are due May 28th, 2002. Late papers will be accepted for the
Poster Session, only. The program will be announced no later than
July 3, 2002.
Industrial exhibit reservations should be sent to mapld2002@klabs.org
and should include company name and contact information (phone and
email). Please see Conference www site for additional information.
Article: 38651--------------A7A4CA83258DEA02D81BEB96 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit All this is described in the Data Sheet. Download the 600 Kbytes from http://xilinx.com/partinfo/ds003.pdf. (I prefer the Virtex data sheet, it is clearer, and Virtex is functionally identical with Spartan2) What is o-chip? On-chip or off-chip? BTW, on-chip we make a distinction between clock delay ( which the DLL eliminates) and on-chip skew ( the difference in arrival time at the many flip-flop clock inputs), which cannot be eliminated, but is kept very low by clever circuit design. Peter Alfke ================================ sitaram wrote: > Can we use DLL for reducing o-chip skew?If we can, please tell me the methods.Article: 38652
Nios v2.0 is currently in Beta. You may want to contact your local Altera FAE to see if you could get a copy of the beta for your project. -Pete- James Srinivasan <James_Srinivasan@nospam.yahoo.com> wrote in message news:a2e28c$m0a$1@pegasus.csx.cam.ac.uk... > Please can anyone from Altera comment on the availability of the Nios v2 > softcore processor? > > Many Thanks, > > James > >Article: 38653
Benny <whg@hf.kjh> wrote in message news:<ee7452c.-1@WebX.sUN8CHnE>...
> how do i implement my thinking?
> ***********************************
> K have an initial value,when one condition(n==8) meets ,k will subtract 1.otherwise keeps.k's initial value depends on a 32bit register .so it is variable. when k equal 0,the 32bit register only will change.i will procedd other according k value change.
> eg:k=24.when (n==8) meets,it subtract 1.it equals 23.othersize 24.next time,when (n==8) meets.it subtract 1.it equals 22.othersize 23.it will stops forever until it equals 0.if it equals 0,the 32bit register value will change.at this time, k will have a new initial value.so forever .
> my code is:
> reg [5:0] k;
> > integer n;
> >
> > always @(posedge Clock or negedge Rst_N )
> > begin
> > if (!Rst_N)
> > k<=0;
> > else
> > begin
> > k<=A;//(initial value (variable))
> > if(n==8) //meet one condition
> > k<=k-1;//subtract 1
> > else
> > k<=k; //keep
> > end
> > end
> > when i simulate with modelsim,it was wrong.
> verilog is unlike C.it can be given a difference value in two difference always clause.when synthesised,it will report more than one driver error.
> can you advise me?or how to implement ?
Benny,
I've been doing VHDL for the last 3 months, and apparently I have
forgotten how to do Verilog (temporarily I hope :,).
I didn't quite follow what you really wanted, but the following may
get you closer.
...
if(!Rst_N)
k <= A;
else
begin
if( n == 8)
if( k == 6'b000000)
k <= A;
else
k <= k - 1;
end
...
Newman
Article: 38654You want to post this on JBits@yahoogroups.com --not that its wrong here, just the JBits people are all there. If you contact Xilinx and get JBits (JBits@xilinx.com or something like that), it has information and example code. Hope this helps. A :) Paddy Mullan <paddymullan@hotmail.com> wrote in message news:418d0214.0201191613.76b7f5f3@posting.google.com... > Can anyone send me information, and/or example code of the partial > reconfiguration API using JBits?Article: 38655
but A value is not get only on reset.On reset,A equals 0.it was read out from one 32bit register.Article: 38656
Steve Holroyd wrote: > > The FPGA array card aim is to support many designs (each potentially > completely different) and to operate at very high bit rates. I assume that you are looking to evaluate the performance of the devices compared to price, right? Or is the price not particularly important and you just want the biggest, fastest chips you can get? If you need to consider price, you will need to get direct quotes from your distributors. The web pricing is nowhere near what they will give you to win your volume business. You can get as much as 50% off in a high volume application. The price and density should be evaluated together. The speed should be evaluated separately. I can't say what you will find in comparing the speed. You will need to prepare some benchmarks that you feel are representative of the designs your customers will use. Or you can just put together some simple designs that will evaluate the basic hardware performance. Then get the vendors to process them and show you how they did it so that you can repeat the results. The density should be measured using metrics that are important to your application. Since your application is very general, you may want to evaluate the density independant of the "special" features of the two families. Optimizing a design for the FPGA architecture will take a little extra time and effort or you will need to rely on the tools to optimize for the FPGA which is not always reliable. Ignoring the "special" features, I expect you will find that the Altera parts achieve somewhat higher densities for a given gate count. Between the XC2V and ApexII families, the XC2V parts claim a higher gate count for the same number of LUTs. I have found the ratio to be about 2:1. For example an XC2V1000 provides 10,240, 4 input LUTs. The EP20K1000E provides 38,400 or will over 3 times as many. However the XC2V1000 provides 720,000 bits of RAM and the EP20K1000E only 327,680, or about half. The XC2V parts have features that the 20K parts only dreams about. If you want to use them, they may well more than make up for the lower LUT count. So the comparison is not at all straight forward. You will need to decide what is important for your application and compare using that metric. -- 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: 38657
strut911@hotmail.com (strut911) wrote in message news:<4379d3e0.0201200127.1207e3d1@posting.google.com>...
> does anyone know how to do bottom up synthesis with synplicity? also,
> is there an easier way to apply the syn_hier attribute such as with a
> wildcard (doesn't seem to work). i have many modules in my design and
> when i am debugging post-synthesis, i like to have all my module
> interfaces intact. thanks.
> strut911
You can do the following:
* Define each subsystem as a separate project in Synplicity.
* Synthesize all levels except the top without I/O pads.
* When a module needs to instantiate a lower-level module, you have to
define the lower-level module as a black-box:
Insert a Component declaration for the Lower-level module in the
higher-level module.
Set syn_black_box attribute for this component.
At the end of this bucnh of synthesis projects, you will have a bunch of
netlist and/or HDL files, each with lower-level modules as black boxes.
You can simulate the project from the top with hierarchy and interfaces
intact; the P&R tools can merge all these netlist files to a single chip.
Note that any post-P&R gate-level HDL files will lose at least some of
the interfaces and instance names.
You should be aware that this is a lot of work and that the synthesis
results will be much less optimized (both space and speed) than when the
whole project is synthesized as a whole. This is caused by the fact that
the synthesis tool can't optimize across module boundaries when the module
is a black box, since it knows nothing about the black-box internals.
Regards
Assaf Sarfati
Article: 38658Has anyone ripped a single bit from a bus line and routed to a single pin? USING Quartus 2 block diagrams I know it is probably relatively easy?? Did the VHDL generate OK? Please as this is driving me spare :) Paul "Paul" <nospam@nospamplease.com> wrote in message news:2XW18.38760$Hg7.4213028@news11-gui.server.ntli.net... > Using Quartus 2 1.1SP2 on W2k > > In order to document some bits of my design I took the decision to start > with block diagrams and then generate the VHDL for Leonardo or the Altera > tools to work with. (the VHDL for top level simple blocks, not the core VHDL > code). > > I find the block diagrams easier to use as documentation and this way have > the virtue of staying in sync with the design. > > However I can't seem to rip a single bit from a bus to go to a single output > pin as well as to its other destination. > [In the old days I used to be able to instantiate a bus ripper symbol and > rip a single bit but can't find an equivalent method now.] > > > The instance I have is a megawizard-generated 24 bit counter. > > q[23..0] are fed to an AND gate instance with the other input connected to a > single wire signal 'pass_it_through'. > > I have named this bus countval[23..0]. The output of the AND is called > 'gated_count' and is generated OK. > > Now I want a single bit of q (say q[7]) to go to another output pin named > 'pulsing_signal'. > > In the BDF I can't seem to get this to generate the correct VHDL. The > 'pulsing_signal' output is named as an output port but has no logic > associated with it. > > I can easily go into the VHDL and add the necessary link and it works fine, > but I'd really like to be able to rip this single bit in the BDF to keep the > design files in step. > > Any help appreciated. > > Paul > >Article: 38659
Assaf Sarfati wrote: > strut911@hotmail.com (strut911) wrote in message news:<4379d3e0.0201200127.1207e3d1@posting.google.com>... > > does anyone know how to do bottom up synthesis with synplicity? also, > > is there an easier way to apply the syn_hier attribute such as with a > > wildcard (doesn't seem to work). i have many modules in my design and > > when i am debugging post-synthesis, i like to have all my module > > interfaces intact. thanks. > > strut911 > > You can do the following: > * Define each subsystem as a separate project in Synplicity. > * Synthesize all levels except the top without I/O pads. > * When a module needs to instantiate a lower-level module, you have to > define the lower-level module as a black-box: > Insert a Component declaration for the Lower-level module in the > higher-level module. > Set syn_black_box attribute for this component. > There's one thing you can do to simplify this process. Write a little perl script that takes a module definition and makes a black-box out of it i.e. strip out everthing except top definition and ports and add the ``syn_black_box'' attribute in the right place. Then `include this stub in any module that instantiates the one from which the stub was derived. > > At the end of this bucnh of synthesis projects, you will have a bunch of > netlist and/or HDL files, each with lower-level modules as black boxes. > You can simulate the project from the top with hierarchy and interfaces > intact; the P&R tools can merge all these netlist files to a single chip. > > Note that any post-P&R gate-level HDL files will lose at least some of > the interfaces and instance names. > > You should be aware that this is a lot of work and that the synthesis > results will be much less optimized (both space and speed) than when the > whole project is synthesized as a whole. This is caused by the fact that > the synthesis tool can't optimize across module boundaries when the module > is a black box, since it knows nothing about the black-box internals. > > But there is a win since you know any changes to a module's HDL code will stay localised after synthesis, avoiding the ``curse of synthesis'' - continually chasing name changes.Article: 38661
With respects to DSP vs FPGA, I'm curious to hear thoughts on floating point versus fixed point issues. There has been some discussion with respects to algorithm complexity, and also on types of algorithms which are better suited for DSP than FPGA implementations. Is it just assumed that anything requiring floating point falls into the DSP camp? Of course, I must confess a bit of a bias, working at a Sharc DSP board company, but we do have a PMC board with both a floating point DSP (ADI 21160) and a Virtex II, so I'm looking for more insights as to where we should be drawing the line between the FPGA and DSP in terms of system implementations. Our approach is always weighted by customer time and cost issues, but typically whatever's easier (and hence faster and less risky) comes ahead of which is the most efficient in terms of saving a few $$. ---------- Ron Huizen Bittware Ray Andraka wrote: > > Amit Thakar wrote: > > > Hi, > > > > I was hoping someone could answer questions I had regarding digital signal > > processors vs. FPGAs for implementing computationally intensive signal > > processing algorithms: > > > > 1. Can FPGAs (especially newer ones) achieve better performance than DSPs? > > Yes, We typically see just under 100:1 performance advantage in our designs > (mostly radar and imaging). That ratio hasn't change much over the last 10 > years. > > > > > 2. If so, then why do ppl use DSPs as opposed to FPGAs? > > Obtaining that performance from FPGAs requires a relatively rare skill set: The > FPGA DSP designer needs to be skilled in logic design, specifically FPGA design, > and also has to be familiar enough with Hardware based DSP to be able to > optimize the algorithm implementation for a hardware, make that FPGA, > implementation. Most DSP algorithms in use today are geared toward a software > solution. The efficient hardware solution often requires a quite different > approach. Most people doing DSP work these days are software types (which makes > sense seeing the DSP field has been dominated by the microprocessor for the past > quarter century), so it follows that DSP designs will continue to use > microprocessors as the preferred platform as long as the project requirements > are met. > > > > > 3. Which is more flexible in terms of reprogrammability (I would think they > > would be the same in this regard). > > The microprocessors still hold an edge on flexibility, mostly because of the > state of the tools. Microprocessor code typically takes seconds to compile > changes where the FPGA code can take hours. The tools, especially when it comes > to evaluation of algorithms, are also much better for the software side. > > > > > 3. What are other (dis)advantages of using FPGAs vs. DSPs. > > The biggest disadvantage to using FPGAs is the relative scarcity of expertise > needed for the performance gains I noted above. FPGAs also cost more per device > than typical DSP micros, but when you consider dollars for a specific > performance then the PFGAs get cheaper as soon as performance drives you over > one or two DSPs. > > I tell my customers that if it can be done in a (single or at most two) DSP > micro, then they should do it there rather than in an FPGA because it is a lot > easier (and somewhat cheaper) to find expertise on the processors. > > > > > > > In general, I understand that DSPs provide a low cost solution due to high > > volume of generic products, but performance tends to fall short for many > > applications. > > > > Any input would be greatly appreciated. > > Thanks! > > > > -Amit > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 38662
Does someone used the Atmel's FPGA configuration memories with Xilinx Spartan-2, I'd like one for XC2S200 or should I stay with the originals XC18Vxx from Xilinx? Thank you. Kinds regards, AndrejArticle: 38663
Can anybody help me understand how the DDR interfaces in these application notes work ? I can't figure out how read data can be clocked into the virtex using the same clock that feeds the ram. My understanding of DDR SDRAMS is that read data can arrive up to 0.75 ns after the clock, and may be valid for no more than half the clock period minus 0.75 ns. At 133 MHz, that gives you a 2.26 ns window to latch the data, and requires a delayed clock which is positioned to account for setup time, clock jitter and pcb trace delays. But the application notes don't use a delayed clock. And even if they did, at 133 MHz I can't see how you could meet the setup time requirement of the IOB input registers listed in the virtex datasheets. So, since there are succesfull DDR SDRAM designs out there, where am I going wrong ? -- Ed Austin Lesea <austin.lesea@xilinx.com> wrote > > We have many successful designs that I have seen from our customers using > HSTL, SSTL, and LVDCI at 133 MHz DDR in Virtex family devices. In Virtex > II, the IOB has the dedicated DDR FF which is optimized for inputs and > outputs. The DCM removes all clock skew, and provides duty cycle corrected > clocks (better timing margins). > > Signal integrity on your board, avoidance of cross talk induced delay > variations in your bus, are all issues that will break any design (Altera > or Xilinx). Oh, and bypassing must be excellent, or else you give up even > more in having ground bounce that not only ruins the noise margin, but adds > jitter. > > Look at the app notes: > > http://www.support.xilinx.com/xapp/xapp253.pdf > > http://www.support.xilinx.com/xapp/xapp214.pdf > > http://www.support.xilinx.com/xapp/xapp200.pdf > > .... and more. > > Austin >Article: 38664
Also, If you do not need, or care to remove the skew, then any resource may be used for connecting the CLK0 to the CLKFB. This is not how most people use the chip, but it does work. You will get warnings about not using the correct resource, but it will route. Also, other resources are not optimized for duty cycle distortion, so the use of BUFG's is highly recommended if duty cycle control is required (ie DDR applications). Austin sitaram wrote: > While using DLLs in FPGAs, is it necessary to use IBUFG and BUFG? > Are there any applications of DLL without using BUFG and IBUFG?Article: 38665
Paul wrote: > > Has anyone ripped a single bit from a bus line and routed to a single pin? > USING Quartus 2 block diagrams No. Top level fpga editors like bits much better than buses. > Did the VHDL generate OK? Ay, there's the rub. I haven't tried Quartus 2, but my other experiences with graphical editors is that the generated code is 95% ugly and 5% unexpected. > Please as this is driving me spare :) Consider keeping the block diagrams in the documentation using dia or Visio and use a good text editor (like emacs vhdl-mode) to do the dirty work of actually wiring up your blocks. --Mike TreselerArticle: 38667
First of all, the integer type should only be used in a stimulus
or testbench file. It is not synthesizable. You need a wire input
into this module to compare against.
The loading of k with the value of A could be controlled with an
additional signal - when this signal is asserted load A into k.
Control the signal with an external module, such as the
one that controls the value of A - in that module you will know
when k needs to be reloaded.
module kflop(Clock,Rst_N,n,A,load_k,k)
input Clock, Rst_N;
input (3:0) n;
input (31:0) A;
input load_k;
output (31:0) k;
reg (31:0) k;
always @(posedge Clock or negedge Rst_N)
begin
if(!Rst_N)
k<=0; // or could be k<=A; depending on your intention
else if(load_k)
k<=A;
else if(n == 4'b1000)
k<=k-1;
else
k<=k; // provided to avoid latch inference
end
Better yet is to have a single signal for decrementing k instead of
a comparison -
module kflop_2(Clock,Rst_N,dec_k,A,load_k,k)
input Clock, Rst_N;
input dec_k;
input (31:0) A;
input load_k;
output (31:0) k;
reg (31:0) k;
always @(posedge Clock or negedge Rst_N)
begin
if(!Rst_N)
k<=0; // or could be k<=A or k<= 32'b01010110...01 depending on your intention
else if(load_k)
k<=A;
else if(dec_k)
k<=k-1;
else
k<=k; // provided to avoid latch inference
end
Now you have a real hardware module at your
complete control - you assert the signals when
you need the hardware to do something.
Always try to think of the hardware...bits and switches and
control signals. It's easy to confuse software concepts
and hardware concepts when learning HDL.
Benny wrote:
> how do i implement my thinking?
> ***********************************
> K have an initial value,when one condition(n==8) meets ,k will subtract 1.otherwise keeps.k's initial value depends on a 32bit register .so it is variable. when k equal 0,the 32bit register only will change.i will procedd other according k value change.
> eg:k=24.when (n==8) meets,it subtract 1.it equals 23.othersize 24.next time,when (n==8) meets.it subtract 1.it equals 22.othersize 23.it will stops forever until it equals 0.if it equals 0,the 32bit register value will change.at this time, k will have a new initial value.so forever .
> my code is:
> reg [5:0] k;
> > integer n;
> >
> > always @(posedge Clock or negedge Rst_N )
> > begin
> > if (!Rst_N)
> > k<=0;
> > else
> > begin
> > k<=A;//(initial value (variable))
> > if(n==8) //meet one condition
> > k<=k-1;//subtract 1
> > else
> > k<=k; //keep
> > end
> > end
> > when i simulate with modelsim,it was wrong.
> verilog is unlike C.it can be given a difference value in two difference always clause.when synthesised,it will report more than one driver error.
> can you advise me?or how to implement ?
Article: 38668Amit Thakar [mailto:athakar@uwaterloo.ca] wrote: >I was hoping someone could answer questions I had regarding >digital signal processors vs. FPGAs for implementing >computationally intensive signal processing algorithms > > 1. Can FPGAs (especially newer ones) achieve better > performance than DSPs? > 2. If so, then why do ppl use DSPs as opposed to FPGAs? > 3. Which is more flexible in terms of reprogrammability (I > would think they would be the same in this regard). > 4. What are other (dis)advantages of using FPGAs vs. DSPs. > > In general, I understand that DSPs provide a low cost solution > due to high volume of generic products, but performance > tends to fall short for many applications. Some years ago, I knew met people working on a C compiler to compile C code to FPGA code. The idea seemed so wrong to me. A programmed FPGA is like a whole bunch of logic connected together, once programmed it is static. If you can use most of the logic on most clock cycles (assuming synchronous designs) FPGA's work well. Consider an average C program, which some initialization, maybe a few loops in the middle, some function calls, and write out some results at the end. When each of those parts is executing the other parts are not. If you tried to program an FPGA, some of the logic would go to initialization, and only be used once. The results writing at the end is also only done once. This is not the way that logic design is done, though. Only the loop part is normally executed enough to make good use of FPGA logic. If you can concentrate on those iterative parts of the algorithm, then you can make good use on an FPGA. In many cases you would want both an FPGA to implement the most used logic operations, and a DSP or other programmable processor to implement the control functions, things like I/O operations and such. Some logic operations work well in FPGA's while others don't. Something as common as floating point arithmetic is very hard to implement well in an FPGA, but is supported well by many DSP. Pretty much, you have to look at each algorithm individually to see what the best implementation would be. P.S., if this is homework please reference the newsgroup. You will still need to do enough thinking to get an answer out of this that you should get appropriate credit. -- glenArticle: 38669
We draw the dividing line in mostly terms of performance. The cost differences are
not great enough in most cases to be a deciding factor. As for floating point, a
majority of DSP applications can be done in fixed point rather than floating point.
The nice thing with FPGAs is that you are not tied to a specific bit width, rather you
can go with whatever width matches your needs. There are occasionally applications
that benefit from floating point, and we do still do those in FPGAs. Again, there are
architectural things that can be done to reduce the complexity of the hardware. If
you look at floating point, all it is is a fixed point value with a second fixed point
value attached to it indicating a power of 2 scale. Many operations require the
operands to be of the same scale, so that the operation is essentially a fixed point
operation (addition is an example of this). When we do something that requires
floating point, we typically do a string of operations in fixed point starting with
the normalized mantissa. Then, only after completing the operations, we renormalize
the result and adjust the exponent. For example, a CORDIC rotation is inherently a
fixed point operation because it is a series of shifts and adds. If we need to use it
with a floating point input and output, we do the actual rotation on the normalized
input pair, and pass the exponent around it. At the back end, we renormalize the
rotated mantissa and adjust the exponent accordingly. If you compare that to a series
of floating point adders, you've saved a tremendous amount of hardware terms of
normalizing/denormalizing shifters without giving up anything in dynamic range or
precision. Another example is the use of a block floating point algorithm for doing
large FFTs. For small FFT's we just accept the bit growth by increasing the width of
the data path. For large ones, we often use a block floating point scheme that has a
common exponent for the set.
Ron Huizen wrote:
> With respects to DSP vs FPGA, I'm curious to hear thoughts on floating
> point versus fixed point issues. There has been some discussion with
> respects to algorithm complexity, and also on types of algorithms which
> are better suited for DSP than FPGA implementations. Is it just assumed
> that anything requiring floating point falls into the DSP camp?
>
> Of course, I must confess a bit of a bias, working at a Sharc DSP board
> company, but we do have a PMC board with both a floating point DSP (ADI
> 21160) and a Virtex II, so I'm looking for more insights as to where we
> should be drawing the line between the FPGA and DSP in terms of system
> implementations.
> Our approach is always weighted by customer time and cost issues, but
> typically whatever's easier (and hence faster and less risky) comes
> ahead of which is the most efficient in terms of saving a few $$.
>
> ----------
> Ron Huizen
> Bittware
>
> Ray Andraka wrote:
> >
> > Amit Thakar wrote:
> >
> > > Hi,
> > >
> > > I was hoping someone could answer questions I had regarding digital signal
> > > processors vs. FPGAs for implementing computationally intensive signal
> > > processing algorithms:
> > >
> > > 1. Can FPGAs (especially newer ones) achieve better performance than DSPs?
> >
> > Yes, We typically see just under 100:1 performance advantage in our designs
> > (mostly radar and imaging). That ratio hasn't change much over the last 10
> > years.
> >
> > >
> > > 2. If so, then why do ppl use DSPs as opposed to FPGAs?
> >
> > Obtaining that performance from FPGAs requires a relatively rare skill set: The
> > FPGA DSP designer needs to be skilled in logic design, specifically FPGA design,
> > and also has to be familiar enough with Hardware based DSP to be able to
> > optimize the algorithm implementation for a hardware, make that FPGA,
> > implementation. Most DSP algorithms in use today are geared toward a software
> > solution. The efficient hardware solution often requires a quite different
> > approach. Most people doing DSP work these days are software types (which makes
> > sense seeing the DSP field has been dominated by the microprocessor for the past
> > quarter century), so it follows that DSP designs will continue to use
> > microprocessors as the preferred platform as long as the project requirements
> > are met.
> >
> > >
> > > 3. Which is more flexible in terms of reprogrammability (I would think they
> > > would be the same in this regard).
> >
> > The microprocessors still hold an edge on flexibility, mostly because of the
> > state of the tools. Microprocessor code typically takes seconds to compile
> > changes where the FPGA code can take hours. The tools, especially when it comes
> > to evaluation of algorithms, are also much better for the software side.
> >
> > >
> > > 3. What are other (dis)advantages of using FPGAs vs. DSPs.
> >
> > The biggest disadvantage to using FPGAs is the relative scarcity of expertise
> > needed for the performance gains I noted above. FPGAs also cost more per device
> > than typical DSP micros, but when you consider dollars for a specific
> > performance then the PFGAs get cheaper as soon as performance drives you over
> > one or two DSPs.
> >
> > I tell my customers that if it can be done in a (single or at most two) DSP
> > micro, then they should do it there rather than in an FPGA because it is a lot
> > easier (and somewhat cheaper) to find expertise on the processors.
> >
> > >
> > >
> > > In general, I understand that DSPs provide a low cost solution due to high
> > > volume of generic products, but performance tends to fall short for many
> > > applications.
> > >
> > > Any input would be greatly appreciated.
> > > Thanks!
> > >
> > > -Amit
> >
> > --
> > --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: 38670There was a time when Atmel had re-programmable SPROMs and Xilinx did not. Then it made sense to use the Atmel device and live with its quirks ( poorly documented Reset polarity, unknown power-on-reset delay) which caused people some grief. I have helped several designs out of trouble... Now that Xilinx also has re-writable SPROMs, why would you take a chance? Peter Alfke, Xilinx Applications ================================== Andrej Jancura wrote: > Does someone used the Atmel's FPGA configuration memories with Xilinx > Spartan-2, > I'd like one for XC2S200 or should I stay with the originals XC18Vxx from > Xilinx? Thank you. > > Kinds regards, > AndrejArticle: 38671
As a means of keepiing the VHDL outline in sync with the block diagrams for documentation, it appears the easiest (quickest solution) so I'm reluctant to redo a lot in visio (even though I like visio). I did find the simple (and I do mean simple) block diagrams gave reasonable VHDL albeit with some slightly unhelpful signal names. Any Quartus 2 users able to help? Paul "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message news:3C4C5F90.76E81FB0@flukenetworks.com... > Paul wrote: > > > > Has anyone ripped a single bit from a bus line and routed to a single pin? > > USING Quartus 2 block diagrams > > No. Top level fpga editors like bits much better than buses. > > > Did the VHDL generate OK? > > Ay, there's the rub. I haven't tried Quartus 2, > but my other experiences with > graphical editors is that the generated > code is 95% ugly and 5% unexpected. > > > Please as this is driving me spare :) > > Consider keeping the block diagrams > in the documentation using dia or Visio > and use a good text editor (like emacs vhdl-mode) to > do the dirty work of actually wiring up your blocks. > > --Mike TreselerArticle: 38672
"Davis Moore" <"dmoore"@(nospam)ieee.org> wrote in message news:a2hnf0$sgb1@cliff.xsj.xilinx.com... > First of all, the integer type should only be used in a stimulus > or testbench file. It is not synthesizable. You need a wire input > into this module to compare against. I am not sure about that statement. I seem to recall using integers as a signal in a VHDL system with no problem. Is Verilog different? Note that I would not use an integer as an input or output port as I might expect that the compiler would not handle that correctly. Thanks, Theron > > The loading of k with the value of A could be controlled with an > additional signal - when this signal is asserted load A into k. > > Control the signal with an external module, such as the > one that controls the value of A - in that module you will know > when k needs to be reloaded. > > module kflop(Clock,Rst_N,n,A,load_k,k) > > input Clock, Rst_N; > input (3:0) n; > input (31:0) A; > input load_k; > output (31:0) k; > > reg (31:0) k; > > always @(posedge Clock or negedge Rst_N) > begin > if(!Rst_N) > k<=0; // or could be k<=A; depending on your intention > else if(load_k) > k<=A; > else if(n == 4'b1000) > k<=k-1; > else > k<=k; // provided to avoid latch inference > end > > Better yet is to have a single signal for decrementing k instead of > a comparison - > > module kflop_2(Clock,Rst_N,dec_k,A,load_k,k) > > input Clock, Rst_N; > input dec_k; > input (31:0) A; > input load_k; > output (31:0) k; > > reg (31:0) k; > > always @(posedge Clock or negedge Rst_N) > begin > if(!Rst_N) > k<=0; // or could be k<=A or k<= 32'b01010110...01 depending on your intention > else if(load_k) > k<=A; > else if(dec_k) > k<=k-1; > else > k<=k; // provided to avoid latch inference > end > > Now you have a real hardware module at your > complete control - you assert the signals when > you need the hardware to do something. > Always try to think of the hardware...bits and switches and > control signals. It's easy to confuse software concepts > and hardware concepts when learning HDL. > > > > > > Benny wrote: > > > how do i implement my thinking? > > *********************************** > > K have an initial value,when one condition(n==8) meets ,k will subtract 1.otherwise keeps.k's initial value depends on a 32bit register .so it is variable. when k equal 0,the 32bit register only will change.i will procedd other according k value change. > > eg:k=24.when (n==8) meets,it subtract 1.it equals 23.othersize 24.next time,when (n==8) meets.it subtract 1.it equals 22.othersize 23.it will stops forever until it equals 0.if it equals 0,the 32bit register value will change.at this time, k will have a new initial value.so forever . > > my code is: > > reg [5:0] k; > > > integer n; > > > > > > always @(posedge Clock or negedge Rst_N ) > > > begin > > > if (!Rst_N) > > > k<=0; > > > else > > > begin > > > k<=A;//(initial value (variable)) > > > if(n==8) file://meet one condition > > > k<=k-1;//subtract 1 > > > else > > > k<=k; file://keep > > > end > > > end > > > when i simulate with modelsim,it was wrong. > > verilog is unlike C.it can be given a difference value in two difference always clause.when synthesised,it will report more than one driver error. > > can you advise me?or how to implement ? >Article: 38673
This is a multi-part message in MIME format. --------------C4DBA8C68F674DA30139F575 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hicks wrote: > "Davis Moore" <"dmoore"@(nospam)ieee.org> wrote in message > news:a2hnf0$sgb1@cliff.xsj.xilinx.com... > > First of all, the integer type should only be used in a stimulus > > or testbench file. It is not synthesizable. You need a wire input > > into this module to compare against. > > I am not sure about that statement. I seem to recall using integers as a > signal in a VHDL system with no problem. Is Verilog different? Note that I > would not use an integer as an input or output port as I might expect that > the compiler would not handle that correctly. > Thanks, > Theron Whether it is synthesizable or not I guess would depend on the synthesis tool however I still agree with that advice of limiting intergers to the testbench regardless of whether the construct is synthesizable or not. If memory serves, the biggest gotcha with intergers is that they default to 32-bits whether you use all the bits or not. This can obviously grow the size of the required hardware in certain situations (especially things like multipliers) and in my opinion, it is best to be explicit with the bus sizing for any function in the design so that you can ensure you get what you think you will get. I guess the opposite effect could happen (lost bits) as well if you were expecting your result to be greater than 32-bits however I am not positive on that. In a testbench, you just need a slight more memory allocation for the simulation (if you do not use all 32-bits) but for the design files, synthesis can have a far more drastic effect on the resulting hardware if it interprets the Verilog language to the letter. The only time I usually use intergers is for "for" loops in the testbench. Otherwise, I will reg or wire the value. -- Brian > > > > > The loading of k with the value of A could be controlled with an > > additional signal - when this signal is asserted load A into k. > > > > Control the signal with an external module, such as the > > one that controls the value of A - in that module you will know > > when k needs to be reloaded. > > > > module kflop(Clock,Rst_N,n,A,load_k,k) > > > > input Clock, Rst_N; > > input (3:0) n; > > input (31:0) A; > > input load_k; > > output (31:0) k; > > > > reg (31:0) k; > > > > always @(posedge Clock or negedge Rst_N) > > begin > > if(!Rst_N) > > k<=0; // or could be k<=A; depending on your intention > > else if(load_k) > > k<=A; > > else if(n == 4'b1000) > > k<=k-1; > > else > > k<=k; // provided to avoid latch inference > > end > > > > Better yet is to have a single signal for decrementing k instead of > > a comparison - > > > > module kflop_2(Clock,Rst_N,dec_k,A,load_k,k) > > > > input Clock, Rst_N; > > input dec_k; > > input (31:0) A; > > input load_k; > > output (31:0) k; > > > > reg (31:0) k; > > > > always @(posedge Clock or negedge Rst_N) > > begin > > if(!Rst_N) > > k<=0; // or could be k<=A or k<= 32'b01010110...01 depending on your > intention > > else if(load_k) > > k<=A; > > else if(dec_k) > > k<=k-1; > > else > > k<=k; // provided to avoid latch inference > > end > > > > Now you have a real hardware module at your > > complete control - you assert the signals when > > you need the hardware to do something. > > Always try to think of the hardware...bits and switches and > > control signals. It's easy to confuse software concepts > > and hardware concepts when learning HDL. > > > > > > > > > > > > Benny wrote: > > > > > how do i implement my thinking? > > > *********************************** > > > K have an initial value,when one condition(n==8) meets ,k will subtract > 1.otherwise keeps.k's initial value depends on a 32bit register .so it is > variable. when k equal 0,the 32bit register only will change.i will procedd > other according k value change. > > > eg:k=24.when (n==8) meets,it subtract 1.it equals 23.othersize 24.next > time,when (n==8) meets.it subtract 1.it equals 22.othersize 23.it will stops > forever until it equals 0.if it equals 0,the 32bit register value will > change.at this time, k will have a new initial value.so forever . > > > my code is: > > > reg [5:0] k; > > > > integer n; > > > > > > > > always @(posedge Clock or negedge Rst_N ) > > > > begin > > > > if (!Rst_N) > > > > k<=0; > > > > else > > > > begin > > > > k<=A;//(initial value (variable)) > > > > if(n==8) file://meet one condition > > > > k<=k-1;//subtract 1 > > > > else > > > > k<=k; file://keep > > > > end > > > > end > > > > when i simulate with modelsim,it was wrong. > > > verilog is unlike C.it can be given a difference value in two difference > always clause.when synthesised,it will report more than one driver error. > > > can you advise me?or how to implement ? > >Article: 38674
Brian Philofsky wrote: > Hicks wrote: > > > "Davis Moore" <"dmoore"@(nospam)ieee.org> wrote in message > > news:a2hnf0$sgb1@cliff.xsj.xilinx.com... > > > First of all, the integer type should only be used in a stimulus > > > or testbench file. It is not synthesizable. You need a wire input > > > into this module to compare against. > > > > I am not sure about that statement. I seem to recall using integers as a > > signal in a VHDL system with no problem. Is Verilog different? Note that I > > would not use an integer as an input or output port as I might expect that > > the compiler would not handle that correctly. > > Thanks, > > Theron > > Whether it is synthesizable or not I guess would depend on the synthesis tool > however I still agree with that advice of limiting intergers to the testbench > regardless of whether the construct is synthesizable or not. If memory serves, > the biggest gotcha with intergers is that they default to 32-bits whether you > use all the bits or not. This can obviously grow the size of the required > hardware in certain situations (especially things like multipliers) and in my > opinion, it is best to be explicit with the bus sizing for any function in the > design so that you can ensure you get what you think you will get. I guess the > opposite effect could happen (lost bits) as well if you were expecting your > result to be greater than 32-bits however I am not positive on that. In a > testbench, you just need a slight more memory allocation for the simulation (if > you do not use all 32-bits) but for the design files, synthesis can have a far > more drastic effect on the resulting hardware if it interprets the Verilog > language to the letter. > > The only time I usually use intergers is for "for" loops in the testbench. > Otherwise, I will reg or wire the value. > > -- Brian > > According to 'Verilog HDL' by Palnitkar (Sunsoft Press - Prentice Hall) an integer defaults to the width of the host machine word size and is at least 32 bits. Also an integer stores signed values while a reg stores unsigned - this could really affect synthesis results if used incorrectly. -Davis
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