Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 38650

Article: 38650
Subject: CFP: 5th Annual MAPLD International Conference
From: "Richard B. Katz" <mapld2002@nospamplease.klabs.org.invalid>
Date: Sun, 20 Jan 2002 10:08:05 -0500
Links: << >>  << T >>  << A >>

                       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
Subject: Re: SPARTAN 2-DLL USAGE
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 20 Jan 2002 15:49:00 GMT
Links: << >>  << T >>  << A >>

--------------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
Subject: Re: Altera Nios v2
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Sun, 20 Jan 2002 21:15:31 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: help me!
From: newman5382@aol.com (newman)
Date: 20 Jan 2002 16:12:22 -0800
Links: << >>  << T >>  << A >>
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: 38654
Subject: Re: JBits: Partial Reconfiguration
From: "Alex Carreira" <aycarrei@shaw.ca>
Date: Sun, 20 Jan 2002 17:38:54 -0700
Links: << >>  << T >>  << A >>
You 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
Subject: Re: help me!
From: Benny <srtkuh@iur.oierg>
Date: Sun, 20 Jan 2002 19:38:38 -0800
Links: << >>  << T >>  << A >>
but A value is not get only on reset.On reset,A equals 0.it was read out from one 32bit register.

Article: 38656
Subject: Re: APEX-II vs VIRTEX-II
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 20 Jan 2002 23:41:43 -0500
Links: << >>  << T >>  << A >>
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 FAX

Article: 38657
Subject: Re: bottom up synthesis with synplicity?
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 20 Jan 2002 23:40:37 -0800
Links: << >>  << T >>  << A >>
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: 38658
Subject: Re: Quartus 2 and bus ripping
From: "Paul" <nospam@nospamplease.com>
Date: Mon, 21 Jan 2002 08:21:30 -0000
Links: << >>  << T >>  << A >>
Has 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
(removed)


Article: 38660
Subject: Re: bottom up synthesis with synplicity?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 21 Jan 2002 12:15:40 +0000
Links: << >>  << T >>  << A >>


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
Subject: Re: Signal processing using FPGAs
From: Ron Huizen <rhuizen@bittware.com>
Date: Mon, 21 Jan 2002 09:54:51 -0500
Links: << >>  << T >>  << A >>
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

Article: 38662
Subject: Atmel FPGA configuration memory?!
From: "Andrej Jancura" <andrej.jancura@tu-ilmenau.de>
Date: Mon, 21 Jan 2002 16:24:11 +0100
Links: << >>  << T >>  << A >>
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,
Andrej



Article: 38663
Subject: Re: DDR-Interface
From: ed.moore@snellwilcox.com (Edward Moore)
Date: 21 Jan 2002 08:22:20 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: SPARTAN 2-DLL USAGE
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 21 Jan 2002 09:01:00 -0800
Links: << >>  << T >>  << A >>
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
(removed)


Article: 38666
Subject: Re: Quartus 2 and bus ripping
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 21 Jan 2002 10:36:00 -0800
Links: << >>  << T >>  << A >>
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 Treseler

Article: 38667
Subject: Re: help me!
From: Davis Moore <"dmoore"@(nospam)ieee.org>
Date: Mon, 21 Jan 2002 11:42:39 -0700
Links: << >>  << T >>  << A >>
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: 38668
Subject: Re: Signal processing using FPGAs
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 21 Jan 2002 19:35:56 GMT
Links: << >>  << T >>  << A >>
Amit 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.

-- glen

Article: 38669
Subject: Re: Signal processing using FPGAs
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Jan 2002 19:41:17 GMT
Links: << >>  << T >>  << A >>
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: 38670
Subject: Re: Atmel FPGA configuration memory?!
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 21 Jan 2002 11:49:03 -0800
Links: << >>  << T >>  << A >>
There 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,
> Andrej


Article: 38671
Subject: Re: Quartus 2 and bus ripping
From: "Paul" <nospam@nospamplease.com>
Date: Mon, 21 Jan 2002 19:53:09 -0000
Links: << >>  << T >>  << A >>
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 Treseler



Article: 38672
Subject: Re: help me!
From: "Hicks" <hicksthe@egr.msu.edu>
Date: Mon, 21 Jan 2002 15:23:09 -0500
Links: << >>  << T >>  << A >>

"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
Subject: Re: help me!
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Mon, 21 Jan 2002 13:40:35 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: help me!
From: Davis Moore <"dmoore"@(nospam)ieee.org>
Date: Mon, 21 Jan 2002 13:56:40 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search