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
2017JanFebMarApr2017

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 31475

Article: 31475
Subject: New Xilinx data book Frisbee
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 27 May 2001 06:10:03 GMT
Links: << >>  << T >>  << A >>
Good job! You guys must be proud, an I hope many readers will pat you on the
back.
Question: How does the search work? "metastability" or "LFSR" should get many
hits...

I have a self-burnt "early-bird" copy of the 2001 data book plus lots of stuff
(600 MB), and I think it is user-friendly, nothing to install etc.
I'll mail it to you if you e-mail me your address.

Greetings
Peter




Article: 31476
Subject: Fragen zu PCI und FPGA
From: T-Online <Mario.Heike.Niklas@t-online.de>
Date: Sun, 27 May 2001 08:32:41 +0200
Links: << >>  << T >>  << A >>
Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an
den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte
einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen.
Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses
bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten.

Danke

Mario Giffel


Article: 31477
Subject: dual channel NCO in Xilinx VirtexE
From: Markus Dobschall <dobschall@tu-harburg.de>
Date: Sun, 27 May 2001 11:35:51 +0200
Links: << >>  << T >>  << A >>
Hi,

I am using the Xilinx VirtexE and I would like to apply the dual channel
NCO of the CORE Generator.
But I can't reproduce the results in the Logic Simulator. I took the
following parameters to generate
this Core: Inc Width=16 ; Amp Width=10 ; Acc Width=16 ; Phase Width=10 ;
CLK=20 MHz

In Logic Simulator get this results (dec.): (every 50 ns; first nineteen
clocks)
sine:   3 ; 3 ; 6 ; 6 ; 9 ; 9 ; 13 ; 13 ; 16 ; 16 ; 19 ; 19 ; 22 ; 22 ;
25 ; 28 ; 28 ; 31 ; 31 ; ...

cosine: 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511 ; 511
; 511 ; 511 ; 511  ; 510 ; 510 ; 510 ; 510 ; 510 ; ...


If I use the parameters [Inc Width=10 ; Amp Width=10 ; Acc Width=10 ;
Phase Width=10 ; CLK=20 MHz]
I am able to reproduce the sine and cosine values in MATLAB with the
following equations:
sin_nco = 2^(AmpWidth-1) * sin(2*pi*phi_word*m*1/2^AccWidth);  
cos_nco = 2^(AmpWidth-1) * cos(2*pi*phi_word*m*1/2^AccWidth);  
(m=loop index)


Can anyone give me any suggestion on it? Thanks

Regards
Markus Dobschall

Article: 31478
Subject: Re: New Xilinx data book Frisbee
From: "Tim" <tim@rockylogic.com.spamtrap>
Date: Sun, 27 May 2001 13:15:36 +0100
Links: << >>  << T >>  << A >>
Peter

Will copies be available at DAC?

Peter Alfke wrote in message <3B109A36.1181949E@earthlink.net>...
>Good job! You guys must be proud, an I hope many readers will pat you on
the
>back.
>Question: How does the search work? "metastability" or "LFSR" should get
many
>hits...
>
>I have a self-burnt "early-bird" copy of the 2001 data book plus lots of
stuff
>(600 MB), and I think it is user-friendly, nothing to install etc.
>I'll mail it to you if you e-mail me your address.
>
>Greetings
>Peter




Article: 31479
Subject: Re: Internal tri states
From: "Tony Burch" <tony@BurchED.com.au>
Date: Mon, 28 May 2001 00:57:03 +1000
Links: << >>  << T >>  << A >>
Hi Jamil,

Definitely keep using MUXs for implementing on-chip buses !

There are three main issues (maybe more, if anyone can add?....)

(1)  Potential Bus Contention:
The obvious issue is that MUXs avoid the potential problem
with tristate buses - bus contention, with multiple drivers active
at the same time (increases power consumption, reduces reliablility
of the chip).

(2) Design Portability:
If your design is HDL based, MUX based buses are technology
independent, hence your design is more portable.  Tristate
resources are limited in FPGAs, and if you transfer your design
to ASIC, tristate buses must never be allowed to float
(FPGAs have weak-keepers on tristate resources, so floating
doesn't occur).  This is a "design for reuse" issue.

(3) System Reset:
This relates to point (1).  If you use tristate buses in your
design, you must use an asynchronous reset for your
design.  This is because with a synchronous reset, you
may have contention on start-up, because your system
will reset to the known start-up state only on the first system
clock.  It is almost always better to use a synchronous
system reset, or at least synchronise/register your incoming
system reset signal.  So, don't use tristate buses if you
have a synchronous reset.  It follows that if you have
tristate buses, you must use an asynchronous reset.

However, at the board level, tristate buses are OK, of course -
you can use tristate logic for the IOs of your top level design,
but not for the internals of your FPGA or ASIC.

Hope that helps :)

Best regards
Tony Burch
http://www.BurchED.com.au
Lowest cost, easiest-to-use
FPGA prototyping kits!


"Jamil Khatib" <khatib@ieee.org> wrote in message
news:3B101A38.588AC93@ieee.org...
> Is there any drawbacks for using internal tristate buffers to implement
> busses? or should I keep using muxs?
>
> Thanks
> Jamil
>



Article: 31480
Subject: Re: Xilinx XC4010E Problem
From: Henning Trispel <h.trispel@thomelektronik.thomson-csf.com>
Date: Sun, 27 May 2001 18:04:20 +0200
Links: << >>  << T >>  << A >>
Hello,

the problem was traced down and has been cured now. (Peter, thanks again
for your quick hints - however, the bone was buried somewere else).


The Motorola MVME IP-bus has bidirectional data ports. In the design I
used the OE-controlled BUFT8 tristate drivers. I always assumed the
enable to be high active, since I didn't find any clue on it being low
active. Curious enough did the problem not show up in the simulation
runs. Luckily, this morning I saw a scope measurement showing exactly
the data bus in tri-state while it should be active. The other time when
only one driver should have been active only one "won" (had the much
stronger driver), since the signals were definately really high or low -
no in between.

Thanks again,

Best regards,

Henning Trispel

Article: 31481
Subject: Re: Internal tri states
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 27 May 2001 16:57:41 GMT
Links: << >>  << T >>  << A >>
Here are some distributed comments by somebody who likes on-chip 3-state
busses for their efficiency.

Tony Burch wrote:

> Hi Jamil,
>
> (1)  Potential Bus Contention:
> The obvious issue is that MUXs avoid the potential problem
> with tristate buses - bus contention, with multiple drivers active
> at the same time (increases power consumption, reduces reliablility
> of the chip).

For reliability problems to exist, there would have to be massive
contention, lasting a long time, which can only happen in an faulty design.

>
>
> (2) Design Portability:
> If your design is HDL based, MUX based buses are technology
> independent, hence your design is more portable.  Tristate
> resources are limited in FPGAs, and if you transfer your design
> to ASIC, tristate buses must never be allowed to float
> (FPGAs have weak-keepers on tristate resources, so floating
> doesn't occur).  This is a "design for reuse" issue.

True, but then: Only certain FPGA designs ever get ported to an ASIC.

>
>
> (3) System Reset:
> This relates to point (1).  If you use tristate buses in your
> design, you must use an asynchronous reset for your
> design.  This is because with a synchronous reset, you
> may have contention on start-up,

The global reset that is active during the whole configuration process is
asynchronous, and moreover, the user clock is actually coming in and is
being distributed during the configuration time. ( Speaking for Xilinx, I
don't know the Altera details enough).
So, unless the whole design is done in a weird way, there is no problem
during configuration and start-up.

> because your system
> will reset to the known start-up state only on the first system
> clock.  It is almost always better to use a synchronous
> system reset, or at least synchronise/register your incoming
> system reset signal.  So, don't use tristate buses if you
> have a synchronous reset.  It follows that if you have
> tristate buses, you must use an asynchronous reset.

Have a good Memorial Day weekend !

Peter Alfke, Xilinx Applications


Article: 31482
Subject: Re: Fragen zu PCI und FPGA
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 27 May 2001 17:06:28 GMT
Links: << >>  << T >>  << A >>
This is what Mario is asking
(in German, which is not the lingua franca on this newsgroup):

"Who knows something about connecting an FPGA on a PCI board to the PCI
bus. I am using the PLX component PCI 9052. I would like to read an SRAM,
connected to the FPGA, via the PCI bus.
Who has some tips or even example programs in VHDL that do this? What do I
have to be concerned about when programming the FPGA?"

Mario Giffel.

One-time translation services provided by Peter Alfke.
========================================================
T-Online wrote:

> Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an
> den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte
> einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen.
> Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses
> bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten.
>
> Danke
>
> Mario Giffel


Article: 31483
Subject: Help for PCI and FPGA
From: T-Online <Mario.Heike.Niklas@t-online.de>
Date: Sun, 27 May 2001 19:40:32 +0200
Links: << >>  << T >>  << A >>
Who have the experience with the FPGA on a PCI-board to connect a
PCI-bus, with using the PLX-device: PCI 9052. An SRAM is connect with
the FPGA and this device should be read from the PCI-bus (32 Bit access)

Who have tips or example-source/standard-source in VHDL, that this can
manage ? What things I must observe ?

Thanks !
Mario


Article: 31484
Subject: Re: RLocs on Inferred registers??
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sun, 27 May 2001 20:34:51 GMT
Links: << >>  << T >>  << A >>
On Mon, 21 May 2001 18:18:47 +0100, "n#" <n@n.com> wrote:

>Anyone know a tool that will do this? I have written scripts, used cores
>etc. but I still wish I could do this.

I was looking at this too and I think RLOC_RANGE is the solution. When
it works (it doesn't work for me with Virtex-II netlists, it seems to
expect old type RLOC specs as opposed to X,Y) you should be able to
put an RLOC_RANGE like X0Y*:X0Y* so that all inferred FDCs of a
register set should go to a stick.

I am hoping that this should work

reg	[17:0] a/* synthesis RLOC_RANGE="X0Y*:X0Y*" */;


Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 31485
Subject: ORCAD Capture Symbols
From: "Alfred M." <Alfred@apsfpga.com>
Date: Sun, 27 May 2001 14:44:17 -0700
Links: << >>  << T >>  << A >>
ANyone have any Orcad Capture symbols for Virtex II. Particulatly in the BF957 package?

Article: 31486
Subject: Help on LVDS
From: Kuan Zhou <zhouk@rpi.edu>
Date: Sun, 27 May 2001 18:20:02 -0400
Links: << >>  << T >>  << A >>
Hi,
   Does anyone here know where to find the LVDS circuit
description for Virtex II?

sincerely
-------------
Kuan Zhou




Article: 31487
Subject: APChDL-2001/SLDL-2001 call for papers
From: "Peter J. Ashenden" <peter@ashenden.com.au>
Date: Mon, 28 May 2001 10:52:48 +0930
Links: << >>  << T >>  << A >>
	 Eighth Asia Pacific Chip Design Languages Conference
		   APChDL-2001, 10-12 December 2001

		System Level Design Languages Workshop
		    SLDL-2001, 12-13 December 2001

		 Adelaide University, South Australia

		Call for Papers, Tutorials and Panels

Design languages play an important role in the development of
integrated circuits and systems.  Languages are used to express the
behavior and structure of designs, and language processing tools are
used for simulation, verification, synthesis and other forms of
analysis.  The abstractions provided by design languages make the
design process more manageable and amenable to automation.

The APChDL Conference organizers invite submission of papers and
proposals for tutorials and panels addressing topics in language-based
design of integrated circuits and systems, including (but not limited
to):

Systems on a Chip			Switch, logic and high-level
- Platform computing			simulation
- Embedded systems specification,	- HW/SW co-simulation 
  modeling, and validation		- Mixed-mode simulation
- FPGA design and reconfigurable	- Formal Verification techniques
  computing				- Logic and behavioral synthesis 
- Rapid prototyping			- Datapath and control synthesis
- Real-time systems			- Interface synthesis
- Intellectual property			- HW/SW co-synthesis
- Interoperability issues

Analog, RF, and mixed signal behavioral modeling
- Analog, RF, and mixed signal circuit synthesis, optimization,
  and layout
- Analog, RF, and mixed signal simulation
- Mixed technology design simulation
- Analog and mixed signal test
- Fault modeling and simulation
- BIST and DFT

For papers, a full-paper manuscript of at most eight single-spaced
pages should be submitted to the APChDL Program Chair by email in
Adobe PDF format.  Papers may be submitted in printed form by regular
mail only by arrangement with the Program Chair.  Tutorial proposals
should include an abstract of at least 500 words, a statement of
learning objectives, target audience and prerequisite knowledge.
Panel proposals should include an abstract of at least 500 words and a
list of proposed panellists.  Tutorial and panel proposals should be
submitted by email to the APChDL Program Chair.

The SLDL Workshop organizers also invite proposals for presentations
and embedded tutorials on topics in language-based system-level
design, including (but not limited to):

- Systems Level Design Semantics and Representations
- Systems Level Simulation and Analysis
- Heterogeneous Specification and Analysis
- Domain Modeling
- Meta-Modeling and Model Integration
- Requirements and Constraint Representation
- Case Studies and Applications

Proposals should include an abstract of at least 500 words, and should
be submitted by email to the SLDL Program Chair.

Important Dates:

- Submissions deadline: 13 July 2001
- Acceptance notices: 14 September 2001
- Final papers due: 19 October 2001


Steering Committee

General Chair:
  Dr. Peter Ashenden
  Ashenden Designs Pty Ltd
  PO Box 640
  Stirling, SA 5152, Australia
  Phone: +61 414 709 106
  Email: peter@ashenden.com.au

APChDL Program Chair:
  Dr. Greg Peterson
  The University of Tennessee
  Elec. and Computer Engineering
  411 Ferris Hall
  Knoxville, TN 37996-2100, USA
  Phone: +1 865 974 6352
  Email: gdp@utk.edu

SLDL Program Chair:
  Dr. Perry Alexander
  The University of Kansas, ITTC
  2291 Irving Hill Rd.
  Lawrence, KS 66044, USA
  Phone: +1 785 864 7741
  Email: alex@ittc.ukans.edu

2000 Chair Emeritus:
  Jean Mermet
  KeesDA, Parc Equation
  2 avenue de Vignate
  38610 Gieres, France
  Phone: +33 4 76 63 49 34
  Email: jean@mermet.org

Finance Chair:
  Dr. Robert Esser
  Dept. Computer Science,
  Adelaide University, SA 5005
  Australia
  Phone: +61 8 8303 5198
  Email: esser@cs.adelaide.edu.au

Publicity Chair:
  Dr. Sri Parameswaran
  University of Queensland
  Dept. Comp. Sci. & Elec. Eng.
  Brisbane, QLD 4072, Australia
  Phone: +61 7 3365 4190
  Email: sridevan@csee.uq.edu.au

Article: 31488
Subject: Re: xilinx webpack warning !!
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 28 May 2001 10:43:51 +0900
Links: << >>  << T >>  << A >>
Hi, Dave.

A gated clock is when you have something like the following: 


NewClk <= Clk and ClkEn;

This (in theory) gives you a clk signal derived from 'Clk', using 'ClkEn' 
as an enable.  It is called a 'gated' clock because it is derived from 
Clk via some sort of logic gate, in this case an and gate.

Using a gated clock is generally considered a Very Bad Thing.

The first problem is if your ClkEn signal changes at some point when Clk 
is not low.  The signal on NewClk will include a glitch or poorly formed 
pulse.

The second problem is that there is a delay through the and gate.  If you
are using Clk anywhere else in your circuit, perhaps without an enable, or 
with a different enable, you are going to get your clock edges at different
times, leading to race conditions and skew problems.

In short, using gated clocks causes a nice, reliable, synchronous design 
to have all sorts of nasty asynchronous & skew-related problems.

Unfortunately, none of these problems will show themselves in your regular 
functional simulation, since usually you simulate thihgs with zero-delay.  
If you do post-place & route simulation with delays, you will probably see 
problems.

when Xilinx's warning says to use the 'CE' pin, that is the enable pin on 
the Flip-flop that can be used instead of modifying the clock itself.

To use the CE pin, at least in VHDL, you need to do something like this:

process( Clk ) is
begin
  if Clk'event and Clk = '1' then -- Rising edge of Clk
    if ClkEn = '1' then           -- Synchronous enable.  This causes ClkEn
                                  -- to be connected to the FF's CE pin.
      outsig <= insig;
    end if; --enable
  end if; --clk
end process;

Hope this helps.
-Kent


"Speedy Zero Two" <david@manorsway.freeserve.co.uk> writes:
> I have a large design which when targeting a 300 series devices gives
> several warning, (like below).
> As this is an internal node how do I find out what to change to correct it.
> 
> Cheers
> Dave
> 
> 
> WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net MUX_OBUF is
> sourced
>    by a combinatorial pin. This is not good design practice. Use the CE pin
> to
>    control the loading of data into the flip-flop.

Article: 31489
Subject: Re: free simulator
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 28 May 2001 10:46:28 +0900
Links: << >>  << T >>  << A >>
"Dave Feustel" <dfeustel@mindspring.com> writes:
> I had tried this a couple of times but I can't seem to get there from 'here'.
> (I get dns/server error msg)
> 
> "Ray Andraka" <ray@andraka.com> wrote in message news:3B09A644.6F8725C6@andraka.com...
> > http://www.aldec.com
> >
> > Dave Feustel wrote:
> > >
> > > What is the URL for Aldec?
> > >

I just checked.  www.aldec.com works fine from here. (I'm in Japan)

But I *have* found the website to be a bit flaky . . kind of off again 
on again.  Any time it was off, it came back on in a matter of hours.

-kent

Article: 31490
Subject: Re: Internal tri states
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 28 May 2001 10:56:26 +0900
Links: << >>  << T >>  << A >>

Peter, a bit more followup, if you will.

Does that mean it is safe to do something like the following:

process(Clk) is 
being
  if rising_edge(Clk) then
   if enable = '0' then
     tri_bus <= value_a;
   else
     tri_bus <= (others => 'Z');
   end if;
  end if;
end process;

process(Clk) is 
being
  if rising_edge(Clk) then
   if enable = '1' then
     tri_bus <= value_b;
   else
     tri_bus <= (others => 'Z');
   end if;
  end if;
end process;

When enable changes, one set of drivers turn off at the clock edge, and 
another set turn on at the clock edge (+/- skew).  I've always avoided 
this, because it seemed that there was a tiny bit of time when both 
drivers were on.  Is the 'small idle time between the two drivers 
being active' greater than the skew on on a clock buffer?  If it is, then
it's safe to replace all of my big sychronous muxes with tri-states, 
without a heat/damage penalty?  (Note: I'm using Spartan-II)

Thanks!
-Kent

Peter Alfke <palfke@earthlink.net> writes:

> Internal 3-states are great, but:
> 
> If you use the longline with resistive pull-up, (DTL-fashion, wired AND)
> it is very safe, but slow.
> If you switch between active drivers, you are responsible for making sure
> that only one driver is on at any one time, otherwise you get contention.
> The drivers are deliberately designed to be faster in turn-off than in
> turn-on, so if you think you have a seemless change, there actually is a
> small idle time between the two drivers being active. Good! Short
> contentions are not destrucive, but generate a lot of noise, and
> unnecassary power consumption.
> On very large chips, the longlines represent a lot of capacitance, that's
> why Virtex implements 3-state buffering differently.
> 
> Peter Alfke
> ==================================
> Jamil Khatib wrote:
> 
> > Is there any drawbacks for using internal tristate buffers to implement
> > busses? or should I keep using muxs?
> >
> > Thanks
> > Jamil

Article: 31491
Subject: Re: Internal tri states
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 27 May 2001 20:24:39 -0700
Links: << >>  << T >>  << A >>
If you use a global clock, known to have very little skew, (it's something like
100 ps) then it is definitely ok to use the same clock edge to turn off one
3-state driver and to turn on another.
If you use local lines to distribute the clock, then this is very iffy and I
would argue against the 3-state solution unless you can investigate the timing
very carefully.

Peter Alfke
Xilinx is closed this week, but I may check my e-mail occasionally.
================================
Kent Orthner wrote:

> Peter, a bit more followup, if you will.
>
> Does that mean it is safe to do something like the following:
>
> process(Clk) is
> being
>   if rising_edge(Clk) then
>    if enable = '0' then
>      tri_bus <= value_a;
>    else
>      tri_bus <= (others => 'Z');
>    end if;
>   end if;
> end process;
>
> process(Clk) is
> being
>   if rising_edge(Clk) then
>    if enable = '1' then
>      tri_bus <= value_b;
>    else
>      tri_bus <= (others => 'Z');
>    end if;
>   end if;
> end process;
>
> When enable changes, one set of drivers turn off at the clock edge, and
> another set turn on at the clock edge (+/- skew).  I've always avoided
> this, because it seemed that there was a tiny bit of time when both
> drivers were on.  Is the 'small idle time between the two drivers
> being active' greater than the skew on on a clock buffer?  If it is, then
> it's safe to replace all of my big sychronous muxes with tri-states,
> without a heat/damage penalty?  (Note: I'm using Spartan-II)
>
> Thanks!
> -Kent
>
> Peter Alfke <palfke@earthlink.net> writes:
>
> > Internal 3-states are great, but:
> >
> > If you use the longline with resistive pull-up, (DTL-fashion, wired AND)
> > it is very safe, but slow.
> > If you switch between active drivers, you are responsible for making sure
> > that only one driver is on at any one time, otherwise you get contention.
> > The drivers are deliberately designed to be faster in turn-off than in
> > turn-on, so if you think you have a seemless change, there actually is a
> > small idle time between the two drivers being active. Good! Short
> > contentions are not destrucive, but generate a lot of noise, and
> > unnecassary power consumption.
> > On very large chips, the longlines represent a lot of capacitance, that's
> > why Virtex implements 3-state buffering differently.
> >
> > Peter Alfke
> > ==================================
> > Jamil Khatib wrote:
> >
> > > Is there any drawbacks for using internal tristate buffers to implement
> > > busses? or should I keep using muxs?
> > >
> > > Thanks
> > > Jamil


Article: 31492
Subject: RLOC_RANGE problem with Virtex-II ?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Mon, 28 May 2001 05:10:50 GMT
Links: << >>  << T >>  << A >>
hi,
I am trying to put this property on a set of registers in Verilog
using this code:
reg	[17:0] a/* synthesis RLOC_RANGE="X0Y*:X0Y*"
U_SET="SETabcdefgh" */;

It seems that Synplicity messes up passing that property to the EDF
file but that can be managed by editing the file. The main problem is
that virtex-2 mapper doesn't seem to be updated for XaYb type of RLOC
specification in RLOC_RANGE. Interestingly RLOC works. Here is the
error:

map -p xc2v1000-5-fg256 -o map.ncd addtree.ngd addtree.pcf
Release 3.3.08i - Map D.27
Copyright (c) 1995-2000 Xilinx, Inc.  All rights reserved.
Using target part "2v1000fg256-5".
ERROR:Map:3 - Illegal format for RLOC_RANGE attribute on "FDC symbol
"a[0]"    (output signal=a[0])".  The format is "Rn1Cm1:Rn2Cm2", where
n1, m1, n2 and  m2 are numbers.


It seem that mapper is still expecting old style RLOC_RANGE format for
virtex-ii even though the docs say that XaYb coordinate style format
is valid for RLOC_RANGE too.
Any suggestions are welcome.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 31493
Subject: Re: Internal tri states
From: "Tony Burch" <tony@BurchED.com.au>
Date: Mon, 28 May 2001 15:51:31 +1000
Links: << >>  << T >>  << A >>
Hi all,

Well, I have learned something:  Never tell someone who likes
on-chip 3-state buses that they "definitely should use muxed
buses" :)  And if you do, chose your words very carefully :) :)

What I really should have said, after pondering it again,
is: "Definitely use muxes for on-chip buses, if you want
your design to be portable and re-usable".

By "portable", I mean that your design can be targeted
to multiple technologies and vendors, without significant
redesign for the architectural features of the target.

By "re-usable", I mean that your design can be used
again as a black box, or grey box, by designers in
a future project.

As an example, if you are a company that produces IP cores
for FPGAs and ASICs, then you would definitely want to use
technology-independent coding style as much as possible
(which includes using on-chip muxed buses, not tri-state).

I have been around for long enough to know that when
someone widely known and well respected like Peter Alfke
speaks, you will do well to take note and listen carefully
(well, I do, anyway :) ).
His points relating to Xilinx FPGAs, in response to my
previous post, are perfectly valid.  In particular,
the responses relating to bus contention, reliablitlity, and
the Xilinx FPGA global reset, are right-on.  Peter, thankyou for
making those points.

> Have a good Memorial Day weekend !

Our Memorial Day (we have "Anzac Day") is on a different
day here in Australia, but I appreciate the sentiment.
Hope you have a good one.

I'm interested to hear others' views on muxed vs tristate
implementations of on-chip buses...

Best regards
Tony Burch
http://www.BurchED.com.au
Lowest cost, easiest-to-use
FPGA prototyping kits!



"Peter Alfke" <palfke@earthlink.net> wrote in message
news:3B1131FC.75E854DC@earthlink.net...
> Here are some distributed comments by somebody who likes on-chip 3-state
> busses for their efficiency.
>
> Tony Burch wrote:
>
> > Hi Jamil,
> >
> > (1)  Potential Bus Contention:
> > The obvious issue is that MUXs avoid the potential problem
> > with tristate buses - bus contention, with multiple drivers active
> > at the same time (increases power consumption, reduces reliablility
> > of the chip).
>
> For reliability problems to exist, there would have to be massive
> contention, lasting a long time, which can only happen in an faulty
design.
>
> >
> >
> > (2) Design Portability:
> > If your design is HDL based, MUX based buses are technology
> > independent, hence your design is more portable.  Tristate
> > resources are limited in FPGAs, and if you transfer your design
> > to ASIC, tristate buses must never be allowed to float
> > (FPGAs have weak-keepers on tristate resources, so floating
> > doesn't occur).  This is a "design for reuse" issue.
>
> True, but then: Only certain FPGA designs ever get ported to an ASIC.
>
> >
> >
> > (3) System Reset:
> > This relates to point (1).  If you use tristate buses in your
> > design, you must use an asynchronous reset for your
> > design.  This is because with a synchronous reset, you
> > may have contention on start-up,
>
> The global reset that is active during the whole configuration process is
> asynchronous, and moreover, the user clock is actually coming in and is
> being distributed during the configuration time. ( Speaking for Xilinx, I
> don't know the Altera details enough).
> So, unless the whole design is done in a weird way, there is no problem
> during configuration and start-up.
>
> > because your system
> > will reset to the known start-up state only on the first system
> > clock.  It is almost always better to use a synchronous
> > system reset, or at least synchronise/register your incoming
> > system reset signal.  So, don't use tristate buses if you
> > have a synchronous reset.  It follows that if you have
> > tristate buses, you must use an asynchronous reset.
>
> Have a good Memorial Day weekend !
>
> Peter Alfke, Xilinx Applications
>



Article: 31494
Subject: Fun with DLLs.
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 28 May 2001 20:54:24 +0900
Links: << >>  << T >>  << A >>
I'm perhaps doing something really dumb, and trying to use an FPGA 
for something it's not meant to do.  But to a guy with a hammer, 
everything looks like a nail, right?

I'm implementing a redundant system.  On each card, (There's about 6 
cards in a chassis) there will be two nominally 52MHz clock inputs.  
The system controller will select which of the two clocks to use.

I'm thinking of using an FPGA on each card to perform the clock 
switching.  If I feed the switched clock into a DLL, then I imagine 
that the transition from one clock to the other has to be pretty smooth.

I imagine the setup as follows (Using Spartan-II):

Clk0 an Clk1 and Select are input pins, all going to a LUT3, which drives 
ClkSelected.  I can not connect this to a DLL, so I drive it off-chip, and 
then back on-chip, to *then* connect it to a DLL.  The output of the DLL 
then goes outside to the real world where it drives a 'zero delay clock 
buffer', which drives all of the devices on that card.

I have a couple of questions that hopefully someone can help me with:

1. Is this a really stupid way of doing it?  Should I simply forget 
about using a FPGA for this?

2. How well do the simulation models of the DLLs in the unisim library
model the real DLLs?

3. If I use the same device in the same package with the same place & 
route for the FPGA on all line cards, what can I expect my worst case 
device-to-device clock skew to be?

4. Any other comments or suggestions would be greatly appreciated.

Thanks in advance.

-Kent


Article: 31495
Subject: Re: xilinx webpack warning !!
From: Gonzalo Arana <gonzaloa@sinectis.com.ar>
Date: Mon, 28 May 2001 11:22:13 -0300
Links: << >>  << T >>  << A >>
Hi,

I get a simmilar message:
WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net N106 is
sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin
to
   control the loading of data into the flip-flop.

How may I find out wich net is N106?
Looking into the PAR detailed report?  I'm affraid it doesn't say
anything.
Thank you very much in advance,

Gonzalo Arana

Kent Orthner wrote:
> 
> Hi, Dave.
> 
> A gated clock is when you have something like the following:
> 
> NewClk <= Clk and ClkEn;
> 
> This (in theory) gives you a clk signal derived from 'Clk', using 'ClkEn'
> as an enable.  It is called a 'gated' clock because it is derived from
> Clk via some sort of logic gate, in this case an and gate.
> 
> Using a gated clock is generally considered a Very Bad Thing.
> 
> The first problem is if your ClkEn signal changes at some point when Clk
> is not low.  The signal on NewClk will include a glitch or poorly formed
> pulse.
> 
> The second problem is that there is a delay through the and gate.  If you
> are using Clk anywhere else in your circuit, perhaps without an enable, or
> with a different enable, you are going to get your clock edges at different
> times, leading to race conditions and skew problems.
> 
> In short, using gated clocks causes a nice, reliable, synchronous design
> to have all sorts of nasty asynchronous & skew-related problems.
> 
> Unfortunately, none of these problems will show themselves in your regular
> functional simulation, since usually you simulate thihgs with zero-delay.
> If you do post-place & route simulation with delays, you will probably see
> problems.
> 
> when Xilinx's warning says to use the 'CE' pin, that is the enable pin on
> the Flip-flop that can be used instead of modifying the clock itself.
> 
> To use the CE pin, at least in VHDL, you need to do something like this:
> 
> process( Clk ) is
> begin
>   if Clk'event and Clk = '1' then -- Rising edge of Clk
>     if ClkEn = '1' then           -- Synchronous enable.  This causes ClkEn
>                                   -- to be connected to the FF's CE pin.
>       outsig <= insig;
>     end if; --enable
>   end if; --clk
> end process;
> 
> Hope this helps.
> -Kent
> 
> "Speedy Zero Two" <david@manorsway.freeserve.co.uk> writes:
> > I have a large design which when targeting a 300 series devices gives
> > several warning, (like below).
> > As this is an internal node how do I find out what to change to correct it.
> >
> > Cheers
> > Dave
> >
> >
> > WARNING:DesignRules:372 - Netcheck: Gated clock. Clock net MUX_OBUF is
> > sourced
> >    by a combinatorial pin. This is not good design practice. Use the CE pin
> > to
> >    control the loading of data into the flip-flop.

Article: 31496
Subject: silly question (xilinx - webpack - mask file)
From: Gonzalo Arana <gonzaloa@sinectis.com.ar>
Date: Mon, 28 May 2001 11:32:37 -0300
Links: << >>  << T >>  << A >>
Hi,

I'm using Xilinx WebPack, and I can't create the .msk file.
Xilinx JTAG Programmer seems to fail programming the device if it
doesn't have a .msk file.
I had already done right-click on the 'Create Programming File' and
checked the box 'Create Mask File',
but the .msk file is not created.
What else should I do?
Thank you very much in advance,

Gonzalo Arana

Article: 31497
Subject: Want to buy: Old copy of ABEL, Synario or ViewPLD
From: "Aaron Nabil" <surplus@spiritone.com>
Date: Mon, 28 May 2001 07:57:38 -0700
Links: << >>  << T >>  << A >>
Got an old copy of ABEL around?  I need one for a project,
the complete kit (ie, legal) with a key.  Prefer version 6
but 5 might work.

I might be able to use Minc Synario, but I'm not sure.

Viewlogic viewpld/propld might work.

Please drop me a line if you have one you would like to
sell.

Thanks,

Aaron
nabil@spiritone.com




Article: 31498
Subject: Re: Xilinx Coolrunner 100% routable - but the tools aren't
From: "Paul Taylor" <p.taylor@ukonline.co.uk>
Date: Mon, 28 May 2001 16:20:07 +0100
Links: << >>  << T >>  << A >>
Hello Peter.
I noticed last year that Coolrunner parts aren't selectable in the
Foundation
base software. Do you think they might be in the future?

Thanks, Paul.  (p.s. you posted HTML!   I changed the Format to plain
text.)


> If you need CPLDs, CoolRunner is the way to go!



Article: 31499
Subject: Re: Want to buy: Old copy of ABEL, Synario or ViewPLD
From: Win Hill <whill@mediaone.net>
Date: Mon, 28 May 2001 15:22:12 GMT
Links: << >>  << T >>  << A >>
Aaron Nabil wrote:
> 
> Got an old copy of ABEL around?  I need one for a project,
> the complete kit (ie, legal) with a key.  Prefer version 6
> but 5 might work.
> 
> I might be able to use Minc Synario, but I'm not sure.

 Minc disappeared a few years back!  Xilinx purchased the assets
 and incorporated ABEL into their WebPACK program (inside they
 call it ABEL version 7.5, IIRC), which is a free download from
 their website.  WebPACK will compile and fit all simple PLDs,
 plus most of the complex Xilinx line, but I suspect it won't
 accept the various ABEL fitter plugins for complex PLDs offered
 years ago first by DataIO, then Minc and other PLD vendors.  At
 any rate, not seeing any mention of this in the HELP files, I
 haven't tried to use the ones I have.  It seems an old out-of-date
 path to follow now anyway, the modern pathway seems to be to use
 each manufacture's own proprietary tools.  Most of these tools do
 recognize ABEL program statements.

 The Xilinx Foundation series seems more powerful than WebPACK,
 with schematic capture, timing analysis, etc., but one rumor is
 that they are moving to a free WebPACK as their standard package.

 Thanks,
          - Win

 Winfield Hill
 Rowland Institute for Science
 100 Edwin Land Blvd
 Cambridge, MA 02142-1297



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
2017JanFebMarApr2017

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