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 37750

Article: 37750
Subject: Re: Kindergarten Stuff
From: "Carl Brannen" <carl.brannen@terabeam.com>
Date: Wed, 19 Dec 2001 23:18:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
Bryan, it's been a while since I've done this (about 18 months), but I ended up
doing it for pretty much the same reasons you did.  I ran out of clock inputs
for some logic that had to take clocks from outside and I wanted precisely
repeatable timing for a bunch of asynchronous busses that came on to the chip.
So I built the clock domain transfer circuitry into a hard macro and placed it
near each input bus.  Here's some notes:

(1) As soon as you say "hard macro", you're going to exceed Xilinx's ability to
support you.  You're on your own.

(2) The tools tend to blow up if you make too large a hard macro, or if you put
too much routing on one.  I only route the clocks.

(3) I don't try to get hard macros to specify clocks to IOBs.  Instead, I
choose to bring the external clocks into pins that are within about 5 CLBs of
the where I bring the data pins in.  It just turns out that the router handles
that particular clock combination with some grace.

(4) The FPGA editor has gotten more and more difficult to use as time has gone
on.  XACT was far better.  And yes, routing in hard macros is a pain in the
butt.  I'll write some notes as I walk through a hard macro routing problem:

(a) From the "File" menu I open the "Main Properties" menu.
(b) I turn off "Stub_Trimming", "AutomaticRouting", "EnhancedManual Routing",
and "DelayBased Routing", then press "Apply" and "Close".
(c) I turn off the "RatsNest" button because all the uncompleted Data paths
will drive me nuts.
(d) On the "List1" window, I get rid of "All Components" and replace it with
"All Nets"
(e) I select the clock I want to route and press the "hilite" button.
(f) When I want to see where I can route to and that kind of stuff, I turn off
the "Routes" button in the tool bar.  That makes all the routes invisible
(except the stuff I hilited), because the problem with the tool is that you
can't select a segment of an even partially routed net without selecting the
whole net.
(g) When I see the next segment that I want to route the net to, I select that
segment and hilite it too.  (By the way, you can add buttons that allow you to
hilite in different colors.  This is very useful, and is found in the Xilinx
documentation for FPGA Editor, but I'm assuming you haven't specialized your
FPGA Editor to do this stuff.)
(h) I can now route a single segment at a time by selecting the "from" segment
with the left mouse button, holding down the "shift" key, selecting the "to"
segment with the left mouse button, releasing the "shift" key, and then
pressing the "route" button on the right hand panel.

This actually works, believe it or not.  The secret is that in order to
properly manipulate routes, you have to turn off the visibility for routed
lines.

Where this gets stupid is when you try to route a bunch of stuff for something
that is critical for route usage.  You basically have to turn on visibility of
routed stuff, hilite your intended route, then turn off route visiblity in
order to make it happen.

Enjoy.

Carl


-- 
Posted from firewall.terabeam.com [216.137.15.2] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 37751
Subject: Re: How can I reduce Spartan-II routing delays to meet 33MHz PCI's Tsu <
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Wed, 19 Dec 2001 15:22:31 -0800
Links: << >>  << T >>  << A >>

Hi,

> What kind of tricks is Xilinx using in their
> LogiCORE PCI other than the special IRDY and
> TRDY pin?  Does anyone know?

No tricks are employed.  I would prefer to think
we use careful and deliberate logic design.  The
special logic resource to which you refer is only
required for 66 MHz designs in devices pre-dating
Virtex-II.

There you go,
Eric

Article: 37752
Subject: Re: Barrel shifter puts three 2->1 muxes / slice in Xilinx
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 19 Dec 2001 23:27:08 GMT
Links: << >>  << T >>  << A >>
"Carl Brannen" <carl.brannen@terabeam.com> writes:

>No question that messing around with the carries is going to slow 
>down a barrel shifter. It's been a very long time since I used one
> (okay, it was actually a "funnel shifter", but I hate that term, 
>so I call them all barrel shifters).  I just got the one that uses 
>the carries to effectively fit a 3 to 1 mux into a LUT to place and 
>route correctly.  It uses 38 LUTs to do a two stage 
>shift of 0 to 8 bits (i.e. a 9-bit barrel shift) on a 16-bit input.

>It's very efficient when you need a power of 3 shift size.  
>You get a 9-bit shift with only 2 stages of logic instead 
>of the usual 4.  I'll post it to the thread in a minute.

It would seem that you could use it for an 8 bit shift, as part
of a larger binary barrel shifter.  Two would do 64, for example.

Otherwise, one use for barrel shifters is floating point normalization.

IBM used a base 16, instead of base 2, floating point in S/360,
S/370, through the beginning of ESA/390.  I believe one reason
for base 16 floating point is the reduced need for shift logic.

I think that for floating point in FPGA's, where barrel shifting
is relatively more expensive, base 16 should be considered.

-- glen


Article: 37753
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Bret Wade <bret.wade@xilinx.com>
Date: Wed, 19 Dec 2001 16:55:29 -0700
Links: << >>  << T >>  << A >>


Austin Franklin wrote:

> > > > ALWAYS
> > > >
> > > >>want my designs to use IOB flip flops if possible.  It seems to me
> that
> > >
> > > > That's what you get for using Design Mangler...er...Manager ;-)
> > >
> > > heh.  I find that make does a fair job of managing builds.  But then, I
> > > always did find CLIs more user friendly than GUIs.
> > >
> > > Even if you invoke map from the commandline or means other than through
> > > DM, packing flops into I/Os is not done unless the -pr flag is supplied.
> > >   So I suppose DM is following the defaults of map.
> > >
> > > M. Ramirez's question still holds good -- is there ever a reason not to
> > > pack flops into IOBs?
> > >
> >
> > I think that packing registers is not the default map option because the
> > expectation is that registers will have IOB=TRUE|FALSE attributes applied
> to
> > them by the front end tool. This attribute takes precedence over the -pr
> map
> > switch and allows for individual control of registers.
> >
> > Regards,
> > Bret Wade
> > Xilinx Product Applications
>
> Bret,
>
> I don't know that that is true.  Even if Synplicity has that checked, the
> Xilinx tools STILL need the "-pr b" to be added to the mapper from what I
> remember.
>
> Regards,
>
> Austin

Austin,

Using the IOB=TRUE attribute does take precedence and there is no need to also
use the "-pr b" switch. Likewise, using "-pr b" will not override an IOB=FALSE
attribute.

Regards,
Bret


Article: 37754
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Bret Wade <bret.wade@xilinx.com>
Date: Wed, 19 Dec 2001 17:00:16 -0700
Links: << >>  << T >>  << A >>


"S. Ramirez" wrote:

> "Bret Wade" <bret.wade@xilinx.com> wrote in message
> news:3C20D7F1.4AB91218@xilinx.com...
> > I think that packing registers is not the default map option because the
> > expectation is that registers will have IOB=TRUE|FALSE attributes applied
> to
> > them by the front end tool. This attribute takes precedence over the -pr
> map
> > switch and allows for individual control of registers.
> >
> > Regards,
> > Bret Wade
> > Xilinx Product Applications
>
> Bret,
>     Every company where I have worked, we've never used the above mentioned
> attribute.
> Simon Ramirez

Simon,

Okay, but you could use the IOB attribute and then there would be no worries
about whether you've set the Map options correctly.

Regards,
Bret


Article: 37755
Subject: Re: multi-cycle constraint
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Wed, 19 Dec 2001 17:09:39 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------53BA433C8C085CCD7947E925
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



David Miller wrote:

> > I apply a set of multi-cycle constraints to a module and it works
> > fine, both timing analyzer and timing simulation. Then I incorporate
> > this module and a larger design and apply the the same constraints
> > again. This time timing analyzer reports is OK but the timing sim is
> > wrong. Any idea to solve the problem?
>
> How is the timing simulation wrong?  Since you don't say, I will make a
> guess: is your timed simulation model is being generated without the
> "-xon false" flag to ngd2vhdl?
>
> Without that flag, ngd2vhdl propagates X's through flops whose inputs
> don't meet timing requirements.  ngd2vhdl doesn't know that that path
> has a multicycle constraint on it, and may be flagging problems that
> aren't real.

I would not suggest using the -xon false switch or disabling X-propgagtion
in this case.  If the said datapath is truely multi-cycle and the output
does have no effect on the circuit, then a timing violation and 'X' output
on the register should also have no effect on the simulation.  Disabling
X-propagation is generally only useful when you know you have asynchronous
data clocked by a synchronous element.

To answer the original question, if an input changes in the setup/hold
window of an enabled register, then a timing violation will fire.  This is
a physical property of the register whether you care about that data or not
and the simultor is alerting you to that.  If you are running the
simulation and a timing violation occurs (without disabling X-propagation)
and the simulation output still looks fine, then you can most likely ignore
the warning messages.  If you are starting to see X's pop up everywhere in
your simulation and the simulation output is failing, then I would question
whether or not that truely is a multi-cycle path.

--  Brian




>
>
> --
> David Miller, BCMS (Hons)  | When something disturbs you, it isn't the
> Endace Measurement Systems | thing that disturbs you; rather, it is
> Mobile: +64-21-704-djm     | your judgement of it, and you have the
> Fax:    +64-21-304-djm     | power to change that.  -- Marcus Aurelius

--------------53BA433C8C085CCD7947E925
Content-Type: text/x-vcard; charset=us-ascii;
 name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brian.philofsky.vcf"

begin:vcard 
n:Philofsky;Brian
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:brian.philofsky@xilinx.com
fn:Brian Philofsky
end:vcard

--------------53BA433C8C085CCD7947E925--


Article: 37756
Subject: Virtex configuration problem: GTS being deasserted before DONE?
From: arast@inficom.com (Alex Rast)
Date: Thu, 20 Dec 2001 00:48:31 GMT
Links: << >>  << T >>  << A >>
We are running into a bizarre problem with Virtex configuration. We're using 
an XCV300-BG352, Xilinx IMPACT software, version 4.1, SelectMAP configuration 
mode, MultiLINX cable. Our design has several control lines to set the 
direction of a bunch of *external* buffers (i.e. chips outside the Virtex 
itself). If I try to run a configuration with our design, the configuration 
fails with a "DONE pin did not go high" message.

However, if I go into FPGA Editor and explicitly tristate the output buffers 
in the IOB's for the control lines (the internal buffers, not the external 
ones), by setting TRIMUX to a hard-wired 1, the configuration succeeds. Of 
course this does no good for our design because then the control lines are 
always tristated, but it does indicate the nature of the problem.

From this behavior, it would seem that the most likely possibility is that in 
spite of the Xilinx documentation, GTS is being deasserted before DONE is 
asserted, because in theory, with GTS asserted, *all* IOB's are tristated. 
I've played around with different settings for DONE_cycle and GTS_cycle in 
bitgen, none of which has had any effect. Is the Xilinx software in fact in 
error, and GTS is deasserted before done? Any workarounds for this problem if 
this is the case?

The other possibility is that to either the Virtex chip or the Impact 
software, the DONE pin is not the indicator that the configuration has 
completed successfully, and some other step is required which itself requires 
that Virtex I/O lines remain quiescent. Is this the actual truth, and in so 
what sort of fixes could apply?

Am I missing any other possibilities? This is a frustrating issue that is 
blocking our development. Has anyone else run into this? 

Many thanks for your help.

Alex Rast
arast@qwest.net
arast@inficom.com

Article: 37757
Subject: Re: annoying problem and "simple and clever solution"
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 19 Dec 2001 16:49:04 -0800
Links: << >>  << T >>  << A >>

--------------ACDD2FC2ABB263783632B461
Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 8bit


Peter Alfke wrote:

> What if you have to drive 5-V that has a CMOS input threshold of up to 3.5 V.
> Then you need a pull-up resistor to the 5 V, and you should configure the
> XC4005 output as "open collector" ( really: open drian ). That costs you speed,
> since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which creates a
> 100 ns delay time constant.
> There is a simple and clever way around that, and I can send you the circuit
> description on Monday when I am back at work.

Here is the "simple and clever circuit" description and the whole, somewhat
long-winded explanation, first published 3 years ago.
Today the 3 ns rise-time is more like 1 ns...


XC4000XL Driving 5-V CMOS Inputs

 The XC4000XL devices use 3.3 V supply, but tolerate 5 V on their I/O
 pins.  They can drive 5-V TTL-level inputs directly.  For driving 5-V
 CMOS-level inputs, a pull-up resistor to 5 V is required, and the
 XC4000XL output must be 3-stated when High.

 (If the output were to remain active High, the pull-up resistor would
 fight the <50 Ohm output transistor, and the output voltage would be
 only 100 mV above the Vcc of 3.3 V.)

 The required output structure is commonly called ěopen collectorî or,
 more correctly, ěopen drain,î and this function is easily generated
 inside the chip by driving the Data and the active-Low Output Enable
 signal of the output block together.  The external Low-to-High
 transition is then driven only by the pull-up resistor.  A 470 Ohm pull-up
 resistor to 5 V and a 50 pF load capacitance create a 0.4-to-4.5 V rise
 time of >40 ns.

 For a faster rise time, drive the internal active-Low Output Enable
 signal not directly from the internal data signal, but from a 2-input
 AND gate driven by the internal data signal AND the input signal that
 comes back from the same device output pin.  On the rising edge, this
 assures that the output pull-up transistor is active for most of the rise
 time, resulting in a shorter output delay.  The important part of the rise
 time, from 0.4 to 3.0V, is reduced dramatically, from 20 ns to 3 ns.
 Watch out for ringing, it might pull the signal down again.

 In most cases, the fast active edge gets you through the CMOS
 threshold and the propagation delay is then <3 ns.  At worst, the
 additional pull-up from the resistor is still needed to reach the
 threshold voltage reliably, but you still saved at least 15 ns.

 This idea originated with our European FAEs (Ken Chapman and Nick
 Sawyer).   We recently performed experiments to verify the claim.  It
 works splendidly.
Peter Alfke, Xilinx Applications




--------------ACDD2FC2ABB263783632B461
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Peter Alfke wrote:
<blockquote TYPE=CITE>What if you have to drive 5-V that has a CMOS input
threshold of up to 3.5 V.
<br>Then you need a pull-up resistor to the 5 V, and you should configure
the
<br>XC4005 output as "open collector" ( really: open drian ). That costs
you speed,
<br>since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which
creates a
<br>100 ns delay time constant.
<br>There is a simple and clever way around that, and I can send you the
circuit
<br>description on Monday when I am back at work.</blockquote>
Here is the "simple and clever circuit" description and the whole, somewhat
long-winded explanation, first published 3 years ago.
<br>Today the 3 ns rise-time is more like 1 ns...
<br>&nbsp;
<h2>
XC4000XL Driving 5-V CMOS Inputs</h2>
&nbsp;The XC4000XL devices use 3.3 V supply, but tolerate 5 V on their
I/O
<br>&nbsp;pins.&nbsp; They can drive 5-V TTL-level inputs directly.&nbsp;
For driving 5-V
<br>&nbsp;CMOS-level inputs, a pull-up resistor to 5 V is required, and
the
<br>&nbsp;XC4000XL output must be 3-stated when High.
<br>&nbsp;
<br>&nbsp;(If the output were to remain active High, the pull-up resistor
would
<br>&nbsp;fight the &lt;50 Ohm output transistor, and the output voltage
would be
<br>&nbsp;only 100 mV above the Vcc of 3.3 V.)
<p>&nbsp;The required output structure is commonly called “open collector”
or,
<br>&nbsp;more correctly, “open drain,” and this function is easily generated
<br>&nbsp;inside the chip by driving the Data and the active-Low Output
Enable
<br>&nbsp;signal of the output block together.&nbsp; The external Low-to-High
<br>&nbsp;transition is then driven only by the pull-up resistor.&nbsp;
A 470 Ohm pull-up
<br>&nbsp;resistor to 5 V and a 50 pF load capacitance create a 0.4-to-4.5
V rise
<br>&nbsp;time of >40 ns.
<p>&nbsp;For a faster rise time, drive the internal active-Low Output Enable
<br>&nbsp;signal not directly from the internal data signal, but from a
2-input
<br>&nbsp;AND gate driven by the internal data signal AND the input signal
that
<br>&nbsp;comes back from the same device output pin.&nbsp; On the rising
edge, this
<br>&nbsp;assures that the output pull-up transistor is active for most
of the rise
<br>&nbsp;time, resulting in a shorter output delay.&nbsp; The important
part of the rise
<br>&nbsp;time, from 0.4 to 3.0V, is reduced dramatically, from 20 ns to
3 ns.
<br>&nbsp;Watch out for ringing, it might pull the signal down again.
<p>&nbsp;In most cases, the fast active edge gets you through the CMOS
<br>&nbsp;threshold and the propagation delay is then &lt;3 ns.&nbsp; At
worst, the
<br>&nbsp;additional pull-up from the resistor is still needed to reach
the
<br>&nbsp;threshold voltage reliably, but you still saved at least 15 ns.
<br>&nbsp;
<br>&nbsp;This idea originated with our European FAEs (Ken Chapman and
Nick
<br>&nbsp;Sawyer).&nbsp;&nbsp; We recently performed experiments to verify
the claim.&nbsp; It
<br>&nbsp;works splendidly.
<br>Peter Alfke, Xilinx Applications
<p>&nbsp;
<br>&nbsp;</html>

--------------ACDD2FC2ABB263783632B461--


Article: 37758
Subject: Re: Spartan-IIE schematic symbol?
From: "pete dudley" <padudle@spinn.net>
Date: Wed, 19 Dec 2001 18:32:29 -0700
Links: << >>  << T >>  << A >>
Download http://members.spinn.net/~padudle/vl_symgen.exe and execute it in a
dos command window. If you run it with no parameters it will return with
instructions or use this example.

vl_symgen compiled_design.pad sym/compiled_design.1

--
Pete Dudley

Arroyo Grande Systems

"Peter Fenn" <Peter.Fenn@avnet.com> wrote in message
news:ee73c6a.-1@WebX.sUN8CHnE...
> Spartan-IIE: I am urgently looking for a (board-level) schematic symbol
(preferably ORCAD or VIEWLOGIC) for an XC2S100E-6FT256C Xilinx FPGA. Is
anyone in a position to help on this?
> -Thanks in advance :-)



Article: 37759
Subject: Re: Best-case timing?
From: Bob Perlman <no-spam@sonic.net>
Date: Thu, 20 Dec 2001 01:39:34 GMT
Links: << >>  << T >>  << A >>
On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters
<andy@exponentmedia.nospam.com> wrote:

>Stephen Byrne wrote:
>
>> I originally posted this yesterday on google groups, but I'm not seeing it
>> on my home news server.  In case it is not visible to all, I'm reposting.
>> 
>> Hello All,
>> 
>> My company is currently comparing 66MHz PCI core solutions from Xilinx
>> and Altera, as well as debating using a home-spun core.  One issue
>> I've come upon is the PCI requirement for a MAX clock-to-out time of 6
>> ns and MIN clock-to-out time of 2 ns.  Both the Xilinx ISE and Altera
>> Quartus II tools seem very helpful in supplying MAX (worst-case) Tco
>> times, but I don't see any info on best-case times.  Apparently the
>> SDF files for back-annotated timing sim have the same worst-case
>> numbers repeated 3 times, resulting in the same simulation regardless
>> of case selection.  My question is: how is anyone (FPGA vendors
>> included) guaranteeing a MIN Tco of 2 ns across all conditions and
>> parts if the design tools don't even yield that information?
>
>
>You like to live dangerously if you depend on best-case timing information.

What's the alternative?

Bob Perlman
Cambrian Design Works

Article: 37760
Subject: Re: Download byteblast circuit with byteblasterMV mode(Maxplus II
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Thu, 20 Dec 2001 12:46:03 +1100
Links: << >>  << T >>  << A >>


shawn chen wrote:
> 
> Hi,
> 
>     I am debugging an Altera FPGA board with old "byteblaster"
> interface on board ( Just a 74HC244 ). Now I have only
> Maxplus II baseLine software which support only "byteblasterMV".
>     The circuit of "byteblasterMV" added some pull up resistors,
> and also other slight difference.
> 
> Problem : When program with JTAG chain through "byteblasterMV" mode,
>        MaxplusII can't detect the device on board (An EPC2L20 ).
> 
> Question:
>     1. Should I change the circuit on board to "byteblasterMV"?
> (I mean cut some wire, add some resistors).

It wouldn't hurt to try it...

Article: 37761
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: "Austin Franklin" <austin@darkroom87.com>
Date: Wed, 19 Dec 2001 20:53:47 -0500
Links: << >>  << T >>  << A >>

"Bret Wade" <bret.wade@xilinx.com> wrote in message
news:3C2128F1.68274384@xilinx.com...
>
>
> Austin Franklin wrote:
>
> > > > > ALWAYS
> > > > >
> > > > >>want my designs to use IOB flip flops if possible.  It seems to me
> > that
> > > >
> > > > > That's what you get for using Design Mangler...er...Manager ;-)
> > > >
> > > > heh.  I find that make does a fair job of managing builds.  But
then, I
> > > > always did find CLIs more user friendly than GUIs.
> > > >
> > > > Even if you invoke map from the commandline or means other than
through
> > > > DM, packing flops into I/Os is not done unless the -pr flag is
supplied.
> > > >   So I suppose DM is following the defaults of map.
> > > >
> > > > M. Ramirez's question still holds good -- is there ever a reason not
to
> > > > pack flops into IOBs?
> > > >
> > >
> > > I think that packing registers is not the default map option because
the
> > > expectation is that registers will have IOB=TRUE|FALSE attributes
applied
> > to
> > > them by the front end tool. This attribute takes precedence over
the -pr
> > map
> > > switch and allows for individual control of registers.
> > >
> > > Regards,
> > > Bret Wade
> > > Xilinx Product Applications
> >
> > Bret,
> >
> > I don't know that that is true.  Even if Synplicity has that checked,
the
> > Xilinx tools STILL need the "-pr b" to be added to the mapper from what
I
> > remember.
> >
> > Regards,
> >
> > Austin
>
> Austin,
>
> Using the IOB=TRUE attribute does take precedence and there is no need to
also
> use the "-pr b" switch. Likewise, using "-pr b" will not override an
IOB=FALSE
> attribute.
>
> Regards,
> Bret

Bret,

Where are you assigning these attributes?  You said in the "front end
tools", yet Synplcity has an "syn_useioff" that doesn't appear to
matter...you still need the "-pr b" in the mapper.  According to the
Synplicity docs, there is no "iob" attribute...  Are you talking about in a
constraint file?  That's really got nothing to do with the synthesis front
end tools...

Austin




Article: 37762
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: "Austin Franklin" <austin@darkroom87.com>
Date: Wed, 19 Dec 2001 20:54:56 -0500
Links: << >>  << T >>  << A >>
> > > I think that packing registers is not the default map option because
the
> > > expectation is that registers will have IOB=TRUE|FALSE attributes
applied
> > to
> > > them by the front end tool. This attribute takes precedence over
the -pr
> > map
> > > switch and allows for individual control of registers.
> > >
> > > Regards,
> > > Bret Wade
> > > Xilinx Product Applications
> >
> > Bret,
> >     Every company where I have worked, we've never used the above
mentioned
> > attribute.
> > Simon Ramirez
>
> Simon,
>
> Okay, but you could use the IOB attribute and then there would be no
worries
> about whether you've set the Map options correctly.
>
> Regards,
> Bret

Or...you could use the "-pr b" map option, and never worry if you set the
IOB attribute correctly!

Sorry, I couldn't resist ;-)




Article: 37763
Subject: Virtex 2 & Trace
From: Quiet Desperation <a@b.invalid>
Date: Wed, 19 Dec 2001 18:32:05 -0800
Links: << >>  << T >>  << A >>
Is there a better way than Xilinx's Trace to get an estimate of how
fast a design will run, especially when there are multiple clocks? It'd
be nice to have a trace program that gives a max speed for all clocks
in a design.

For example, I tested an 8:64 demux today that uses 1:2 DDRs in it's
initial stage. I successfully ran it without errors with 900 Mbps data
inputs (450 Mhz clock) which is above the official spec of the chip.
The Trace program estimated a top clock of 162 MHz. :-\

Would it help to TIG all the lower clock stuff? Maybe give them all a
common prefix or suffix and just have something like "NET *_slowclk
TIG;"

Nice chip, though, Xilinx. I could actually sneak it up to 1 Gbps (500
MHz clock) before it started to flake out. I hand placed all the high
speed FFs with LOC constraints. You can accomplish amazing things if
you don't leave too much up to the place and route tools. ;-)

-- 
- Quiet Desperation -
"The mass of men lead lives of quiet desperation." -- Henry David Thoreau

Article: 37764
Subject: Re: DCM stability in Virtex2 -ES
From: David Miller <spam@quartz.net.nz>
Date: Thu, 20 Dec 2001 17:27:04 +1300
Links: << >>  << T >>  << A >>
> The most important errata from the errata sheet for the DCM is to reset 
> it after the part is configured and the clocks are running after a delay.


I am waiting for my FAE to get me a copy of this errata sheet.


> The recommendation is to wait 500 ms at room temp (longer if cold), to 
> assert RST for a short period (say 100 us or less -- as it stops all of


You are bang on the money.  I wrote code to strobe the DCMs reset for 
1us after about 600ms after config, and it worked first time, every 
time.  Thank you very much!  Now that I understand the problem, I can 
write a DCM monitor that checks the status bits and applies reset in the 
appropriate way.

 

I'd like to ask one more thing: when I am doing clock mirroring/board 
level deskewing, should the feedback path from the IOB to the FB input 
on the DCM go through a BUFG or not?

My original design lacked such a BUFG, but the reference code from 
XAPP262 does have one.  With that BUFG present, a warning is issued 
concerning an "unknown feedback loop".

-- 
David Miller, BCMS (Hons)  | When something disturbs you, it isn't the
Endace Measurement Systems | thing that disturbs you; rather, it is
Mobile: +64-21-704-djm     | your judgement of it, and you have the
Fax:    +64-21-304-djm     | power to change that.  -- Marcus Aurelius


Article: 37765
Subject: Re: Virtex 2 & Trace
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 04:36:52 GMT
Links: << >>  << T >>  << A >>
Yup, and those glue on pentium heatsinks with the fans on them come in handy
for some of those high clock high density designs.

Quiet Desperation wrote:

> Is there a better way than Xilinx's Trace to get an estimate of how
> fast a design will run, especially when there are multiple clocks? It'd
> be nice to have a trace program that gives a max speed for all clocks
> in a design.
>
> For example, I tested an 8:64 demux today that uses 1:2 DDRs in it's
> initial stage. I successfully ran it without errors with 900 Mbps data
> inputs (450 Mhz clock) which is above the official spec of the chip.
> The Trace program estimated a top clock of 162 MHz. :-\
>
> Would it help to TIG all the lower clock stuff? Maybe give them all a
> common prefix or suffix and just have something like "NET *_slowclk
> TIG;"
>
> Nice chip, though, Xilinx. I could actually sneak it up to 1 Gbps (500
> MHz clock) before it started to flake out. I hand placed all the high
> speed FFs with LOC constraints. You can accomplish amazing things if
> you don't leave too much up to the place and route tools. ;-)
>
> --
> - Quiet Desperation -
> "The mass of men lead lives of quiet desperation." -- Henry David Thoreau

--
--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: 37766
Subject: Re: Hardware FPGA questions
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 04:55:03 GMT
Links: << >>  << T >>  << A >>
Those suffixes are the speed grade.  The parts are graded as they come
through test and "binned" according to their performance scores and the
relative demand for the various speed grades.  This way the vendor can
sell the faster parts at a higher premium.  For the virtex families, the
higher the number, the higher the performance.  In the 4K families, it
went the other way with the smaller numbers indicating faster parts.

Better is a relative term.  If you need the speed, then the faster parts
are 'better'.  If you need to keep your costs down, then the slower parts
are 'better' because they are significantly cheaper.

Antonio wrote:

> Some hardware question on FPGA :
>
> 1) What's the difference between a part with speed -3 and another with
> speed -4 , the number is the number of metal layers ??
>
> 2) I read data sheet of Virtex and Virtex E, I didn't found really
> much difference, can you explain me which is better and why ??
>
> Thanks

--
--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: 37767
Subject: Re: Hardware FPGA questions
From: "Josh Pfrimmer" <yeah_spam_me@thisaddress.com>
Date: Wed, 19 Dec 2001 23:55:32 -0800
Links: << >>  << T >>  << A >>
The Virtex-E just has more BlockRAM available, IIRC...

JoshP

"Ray Andraka" <ray@andraka.com> wrote in message
news:3C216F7E.76102A77@andraka.com...
> Those suffixes are the speed grade.  The parts are graded as they come
> through test and "binned" according to their performance scores and the
> relative demand for the various speed grades.  This way the vendor can
> sell the faster parts at a higher premium.  For the virtex families, the
> higher the number, the higher the performance.  In the 4K families, it
> went the other way with the smaller numbers indicating faster parts.
>
> Better is a relative term.  If you need the speed, then the faster parts
> are 'better'.  If you need to keep your costs down, then the slower parts
> are 'better' because they are significantly cheaper.
>
> Antonio wrote:
>
> > Some hardware question on FPGA :
> >
> > 1) What's the difference between a part with speed -3 and another with
> > speed -4 , the number is the number of metal layers ??
> >
> > 2) I read data sheet of Virtex and Virtex E, I didn't found really
> > much difference, can you explain me which is better and why ??
> >
> > Thanks
>
> --
> --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: 37768
Subject: Re: annoying problem and "simple and clever solution"
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 20 Dec 2001 09:25:01 +0000
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

>
> Peter Alfke wrote:
>
>> What if you have to drive 5-V that has a CMOS input threshold of up
>> to 3.5 V.
>> Then you need a pull-up resistor to the 5 V, and you should
>> configure the
>> XC4005 output as "open collector" ( really: open drian ). That costs
>> you speed,
>> since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which
>> creates a
>> 100 ns delay time constant.
>> There is a simple and clever way around that, and I can send you the
>> circuit
>> description on Monday when I am back at work.
>
> Here is the "simple and clever circuit" description and the whole,
> somewhat long-winded explanation, first published 3 years ago.
> Today the 3 ns rise-time is more like 1 ns...

I've used this trick several times over the years and can confirm that
it works a treat.

In fact its so nice that I've often wondered why no one has defined it
as a standard output structure we might call FO/D = Fast-OpenDrain.



Article: 37769
Subject: Re: Kindergarten Stuff
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 20 Dec 2001 09:43:36 +0000
Links: << >>  << T >>  << A >>


Steve Underwood wrote:

> I think that depends on the type of degree. Wouldn't finding a way to
> get someone else to do the hard work for you be considered reasonable
> grounds for being awarded an MBA?
>

Only if you made sure you got paid & they didn't.



Article: 37770
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 20 Dec 2001 09:59:29 +0000
Links: << >>  << T >>  << A >>


Andy Peters wrote:

> S. Ramirez wrote:
>
> >      I don't know about you guys and gals and pals, but everytime I do a
> > design, without exception, I ALWAYS go into the Xilinx Design Manager
> > Design --> Optiions --> Implementation Edit Options and select and select
> > "Inputs and Outputs" for Pack I/O Registers/Latches into IOBs for.  I ALWAYS
> > want my designs to use IOB flip flops if possible.  It seems to me that the
> > default "Off" is a waste of these flip flops.  Does anyone here every turn
> > this off?
>
> Simon,
>
> Amen.
>
> ---a

I think I've figured out how these things happen & how the obvious default  of
``-pr b'' deosn't happen.

It goes like this

1. New feature (pack IOB FFs) gets designed into prototype s/w.

2. s/w engineer, not confident that its not going to crash something in some
obscure & difficult to find way, defaults it to off.

3. Fully intending. once testing is complete, to change the default to the
sensible one.

4. Manger comes along & asks ``Is new feature complete and working''.

5. Engineer, naively, says ``yes''.

6. Manager releases new s/w + associated docs.

... Some time later ...

7. User complains of stupid default value.

8. engineer agrees, changes it, and then gets told ``You can't do that, its now in
the manual''.

Swap h/w for s/w and all the  above is based on personal experience.


Article: 37771
Subject: Re: Kindergarten Stuff
From: David Hawke <dhawke@xilinx.com>
Date: Thu, 20 Dec 2001 10:06:40 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------2C82A415C276A9315F20A65E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

4.1i and above.

Dave

Tim wrote:

> "David Hawke" <dhawke@...inx.com> wrote
>
> > Also for everyone here, you might also want to try the Directed Routing
> > constraint (which appends it to the ucf or ncf file) Tools > Directed Routing
> > cst....
>
> I guess "Tools > Directed Routing cst" is not to be
> confused with "Tools > DRC" :)
>
> Which revision of FPGA Editor for DirectedRoutingCst ?

--------------2C82A415C276A9315F20A65E
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:;David Hawke
tel;cell:(44) 778 875 5002
tel;fax:(44) 1291 621 541
tel;home:(44) 1291 621 655
tel;work:(44) 870 7350 517
x-mozilla-html:FALSE
org:Xilinx UK;Northern European Sales
version:2.1
email;internet:dhawke@xilinx.com
title:Xilinx Field Applications Engineer
adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom
fn:David Hawke
end:vcard

--------------2C82A415C276A9315F20A65E--


Article: 37772
Subject: Re: annoying problem and "simple and clever solution"
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Thu, 20 Dec 2001 10:08:24 +0000
Links: << >>  << T >>  << A >>
In article <3C21AE6D.97C9691C@algor.co.uk>, Rick Filipkiewicz
<rick@algor.co.uk> writes
>> Here is the "simple and clever circuit" description
[snip]
>
>I've used this trick several times over the years and can confirm that
>it works a treat.
>
>In fact its so nice that I've often wondered why no one has defined it
>as a standard output structure we might call FO/D = Fast-OpenDrain.

Traditional 8051 microcontrollers have a related trick, with the 
active pull-up enabled for just one clock cycle when the output
transitions from low to high.  Not as nice as the Xilinx idea,
but it works on unidirectional outputs too.
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 37773
Subject: Re: Spartan-IIE schematic symbol?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 20 Dec 2001 10:12:05 +0000
Links: << >>  << T >>  << A >>


pete dudley wrote:

> Download http://members.spinn.net/~padudle/vl_symgen.exe and execute it in a
> dos command window. If you run it with no parameters it will return with
> instructions or use this example.
>
> vl_symgen compiled_design.pad sym/compiled_design.1
>
> --
> Pete Dudley
>
> Arroyo Grande Systems
>
> "Peter Fenn" <Peter.Fenn@avnet.com> wrote in message
> news:ee73c6a.-1@WebX.sUN8CHnE...
> > Spartan-IIE: I am urgently looking for a (board-level) schematic symbol
> (preferably ORCAD or VIEWLOGIC) for an XC2S100E-6FT256C Xilinx FPGA. Is
> anyone in a position to help on this?
> > -Thanks in advance :-)

We have a very similar thing for VeriBest (now owned by Mentor) schems. In some
form or another we have been auto-generating schems. from pinout files since we
moved to CPLDs from PALs.

For the original versions we did use a ``canned'' part placed on a primitive
schem with wires connected to all the part pins and the wires had temp names
related to the parts pin names.
Then used a tool that came with the schem editor to rename the wires that were
"live" and delete the rest. This auto-schem was hidden in a hierarchy block.

We can now contruct the whole thing from the ground up using schem editor's list
of symbols which includes, for a ViretxE part, 8 ``bank'' symbols, a power
block, and a configuration block.


Article: 37774
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Thu, 20 Dec 2001 10:37:25 GMT
Links: << >>  << T >>  << A >>

"Bret Wade" <bret.wade@xilinx.com> wrote in message
news:3C212A10.D5E82114@xilinx.com...
> Simon,
>
> Okay, but you could use the IOB attribute and then there would be no
worries
> about whether you've set the Map options correctly.
>
> Regards,
> Bret

Bret,
     This is just a suggestion from a user point of view -- change the
default.  Then we wouldn't be having this discussion.
Simon





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