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 32400

Article: 32400
Subject: Re: black box instantiation in Spartan II Design
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Jun 2001 00:17:01 GMT
Links: << >>  << T >>  << A >>
Personally, I prefer to instantiate the RAMs from primitives because the inference
can be quirky and sometimes changes with new releases.  RAM instantiation also lets
you construct exactly what you want (the structure is simple), lets you add
placement constraints (the xilinx autoplace does not do very well with RAMs, Tbufs
and I/O), and really doesn't take much more code than an inference does (and alot
less effort with trying to get the tools to produce what you want).

Rick Filipkiewicz wrote:

> Metin Yerlikaya wrote:
>
> > Hi !
> > I'm using the Foundation Series 3.1 of Xilinx  and installed it with a
> > Target Device Spartan II Family.
> > It seems that LogiBLOX tool does not support this family.
> > If i try to add a new source to a Project , there is no LogicBLOX option but
> > Coregenerator. Also when i start the logiBlox tool alone, i can not choose
> > any Device
> > Family and SpartanII was the only Target Family i set during installation.
> > I want to instantiate a RAM Block in my design without having to write to
> > behavioral Code for it as Xilinx also suggests. "Never describe RAM
> > behaviorally in the HDL code, because combinatorial feedback paths will be
> > inferred."
> >
> > How can i do this now ...i have edif file of the RAM Block i want to
> > instantiate.
> > Would it be enough to declare the Component and instantiate it , let the
> > tool create
> > a blackbox and everything will be fine during implementation phase ???
> >
> > Any Reply appreciated !
> >
> > Metin
>
> Firstly you can get SpartanII macros from Coregen by setting the the family to
> Virtex [SpartanII = cheap virtex].
>
> Secondly as to the Xilinx comment
>
> "Never describe RAM behaviorally in the HDL code, because combinatorial feedback
> paths will be
> inferred."
>
> This is true for FPGA Express [all RAMs] but Synplify and Leonardo can at infer
> the small select RAMs and at least some BlockRAM structures. I don't know what
> the story is for XST.

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



Article: 32401
Subject: Xilinx logic usage
From: "Andrew Bridger" <andrew.bridger@xtra.co.nz>
Date: Tue, 26 Jun 2001 13:46:01 +1200
Links: << >>  << T >>  << A >>
Hi,
We are using Xilinx ISE 3.1, XST compilier.  The xilinx tools appear to be
telling me my design is using approximately twice as much logic as I would
expect.  Consequently it does not fit the device I have targeted(XC2S50).

The design uses 1005 flip flops and 881 LUT's as shown below.  I expected
the xilinx tools to use both the flip flop and LUT within a logic cell.  2
Logic cells = 1 slice.  2 slices = 1 CLB.  So each slice has 2 flipflops and
2 LUT's.

So I expected the design to use approximately 1005 /2 = 500 slices.   But
no, xilinx tool tells me 909 slices have been used, which is too much for
the device.  Anyone got any ideas on what I am doing wrong?  I have tried
optimising for area or speed at synthesis.  Almost identical result.  (I
also tried putting the place and route effort up to max, but again very
little effect.)

Surely the LUT and flipflop can both be used within a logic cell??

Any ideas would be much appreciated.


Design Summary:
   Number of errors:      1
   Number of warnings:    2
   Number of Slices:                909 out of    768  118%
   Number of Slices containing
      unrelated logic:               35 out of    909    3%
   Number of Slice Flip Flops:    1,005 out of  1,536   65%
   Total Number 4 input LUTs:       881 out of  1,536   57%
      Number used as LUTs:                        865
      Number used as a route-thru:                 16
   Number of bonded IOBs:            86 out of    176   48%
   Number of Tbufs:                  16 out of    832    1%
   Number of GCLKs:                   2 out of      4   50%
   Number of GCLKIOBs:                2 out of      4   50%
Total equivalent gate count for design:  15,144
Additional JTAG gate count for IOBs:  4,224

Thanks Andrew



Article: 32402
Subject: Re: Xilinx logic usage
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Jun 2001 03:36:18 GMT
Links: << >>  << T >>  << A >>
My first thought was that it was just the automatic placement, which tends to
spread stuff out so that the slices are only half utilized, but it won't do that
at the expense of forcing a larger part as is the case for yours.  Something
else is going on that is preventing the two flip-flops being packed into a
slice.  Possibilities include different clock signal names, different reset
signals, or different clock enables.  If your fan-out limit in the synthesizer
is set low, it will duplicate some or all of these signals with different names
on each.  The mapper can't move instances to different nodes on an instantiated
distribution tree.  Try setting the fan-out limit to a higher value.



Andrew Bridger wrote:

> Hi,
> We are using Xilinx ISE 3.1, XST compilier.  The xilinx tools appear to be
> telling me my design is using approximately twice as much logic as I would
> expect.  Consequently it does not fit the device I have targeted(XC2S50).
>
> The design uses 1005 flip flops and 881 LUT's as shown below.  I expected
> the xilinx tools to use both the flip flop and LUT within a logic cell.  2
> Logic cells = 1 slice.  2 slices = 1 CLB.  So each slice has 2 flipflops and
> 2 LUT's.
>
> So I expected the design to use approximately 1005 /2 = 500 slices.   But
> no, xilinx tool tells me 909 slices have been used, which is too much for
> the device.  Anyone got any ideas on what I am doing wrong?  I have tried
> optimising for area or speed at synthesis.  Almost identical result.  (I
> also tried putting the place and route effort up to max, but again very
> little effect.)
>
> Surely the LUT and flipflop can both be used within a logic cell??
>
> Any ideas would be much appreciated.
>
> Design Summary:
>    Number of errors:      1
>    Number of warnings:    2
>    Number of Slices:                909 out of    768  118%
>    Number of Slices containing
>       unrelated logic:               35 out of    909    3%
>    Number of Slice Flip Flops:    1,005 out of  1,536   65%
>    Total Number 4 input LUTs:       881 out of  1,536   57%
>       Number used as LUTs:                        865
>       Number used as a route-thru:                 16
>    Number of bonded IOBs:            86 out of    176   48%
>    Number of Tbufs:                  16 out of    832    1%
>    Number of GCLKs:                   2 out of      4   50%
>    Number of GCLKIOBs:                2 out of      4   50%
> Total equivalent gate count for design:  15,144
> Additional JTAG gate count for IOBs:  4,224
>
> Thanks Andrew

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



Article: 32403
Subject: Re: IOB FF in Synplicity
From: rotemg@mysticom.com (Rotem Gazit)
Date: 25 Jun 2001 22:23:04 -0700
Links: << >>  << T >>  << A >>
Rick,
Try putting the directive :
/* synthesis syn_useioff=1  syn_srlstyle = "registers" */ 
In your module declaration.
If you don't have internal feedbacks from your output signals that
should do the trick for you.
Note that Synplicity tends to merge duplicated registers (use syn_keep
on these signals to prevent this) and convert sequential register to
SRL16.

Cheers,

Rotem Gazit
MystiCom LTD
mailto:rotemg@mysticom.com
http://www.mysticom.com/




Rick Collins <spamgoeshere4@yahoo.com> wrote in message news:<3B3687A7.9E58CDF8@yahoo.com>...
> We are targeting a Xilinx XC4000 part and need to push some registers
> into the IOBs. We like to keep our designs vendor independant, so we
> prefer not to instantiate special features in the Verilog, such as IOB
> FFs. 
> 
> I checked on the Xilinx web site and found that there is a directive to
> designate a register to be implemented in the IOB. The directive is /*
> synthesis IOB=TRUE */, and is placed in the reg declaration. This is
> claimed to work with Synplify and Xilinx Alliance. When this was tried,
> the FFs were still in the CLBs. 
> 
> Does anyone have experience with what we are trying to do? Should we
> give up and instantiate the IOB FFs? 
> 
> -- 
> 
> 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: 32404
Subject: STARTUP block
From: yose@wam.umd.edu (Joe Wetstein)
Date: 26 Jun 2001 02:51:47 -0400
Links: << >>  << T >>  << A >>
I have a design on a virtex part that uses the CLKDLL to generate both the
clock for the design, and the reset (by using the LOCKED signal as a
reset). In my veilog, I have the following general construct:

always @ (posedge clk or negedge reset)
begin
   if (reset == 0)
      begin
       <all signals> <= 0;
      end
   else
      begin
       <all the rest of the logic>
      end

again, the clk and reset signals are the named signals that are from the
DLL:

CLKDLL dll1 (.CLK0(clk),
             .LOCKED(reset),
               etc)

Now, here is the problem: On virtex parts, the standard is for the routers
to use the routing busses for the GSR (global reset/set) and NOT use the
global GSR resource. Xilinx says tha this has somrething to do with the
poor skew problem on the global resource.

But I dont want to use the local resources for this signal. After all, it
complicates my PAR (place and route) by complicating the routing. So,
Xilinx says that I can specifically instantiate the STARTUP block (which
is called STARTUP_VIRTEX for a virtex part) to dedicate the gloval and not
local resource to the reset signal. But... how do I connect it when I am
using a DLL to generate the signal??

Can I just include another instantiation:

STARTUP_VIRTEX sv1 (.GSR(reset))

to do the job?

or do I need something like:

STARTUP_VIRTEX sv1 (.GSR(~reset))

because of the polarity of the resource?

I dont find good examples of this on their website, and would appreciate
any help that anyone can offer!

Joe 

yose@wam.umd.edu


Article: 32405
Subject: Re: IOB FF in Synplicity
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 26 Jun 2001 07:55:06 +0100
Links: << >>  << T >>  << A >>


Rotem Gazit wrote:

> Rick,
> Try putting the directive :
> /* synthesis syn_useioff=1  syn_srlstyle = "registers" */
> In your module declaration.
> If you don't have internal feedbacks from your output signals that
> should do the trick for you.
> Note that Synplicity tends to merge duplicated registers (use syn_keep
> on these signals to prevent this) and convert sequential register to
> SRL16.
>
> Cheers,
>

Rotem & Ray A.

The problem I'm finding is not in the explicit, standalone, FFs that I want to get into IOBs or,
to put it another way, where I have to avoid feedback from an output reg. My "standard" Verlilog
state machine style is a single registered case statement with both state transitions and outputs
defined in it e.g.

always @(posedge clk)
   case (state_vec)
        ...
        some_state: begin
            if (some_condition_or_other) begin
                state_vec <= new_state;
               iobreg <= new_value;
            end
        end
        ...
  endcase

where ``iobreg'' is supposed to end up in an IOB. What the Synplify optimiser does, sometimes, is
to generate logic for ``iobreg''  that uses feedback from itself.  In the two cases I'm fighting
right now the state mach is 2 levels down in the hierarchy. What Syn support told me to do is to
separate out the IOB registers into a separate always block. I really dislike that design style
since its much more awkward to document and it fails what I call the ``visibility'' test of HDL
code i.e. can you see at a glance that its right.

The second place where Synplify can implicitly break the IOB packing rules relates to the common
init condition for bidirs which are registered in both directions. Even if you have not defined a
sync reset on a FF Synplify might generate one for you! If, after logic reduction, the input
equation for an output FF can be made to look something like

 !foo & bar

then Syn may put foo on the sync reset pin and bar on the D. This is the issue that I first
brought to Synplicity's attention 2 years ago. They didn't seem to understand what I was talking
about and I ended up kludging my way around it by putting fake async resets on the FFs.

In both these cases syn_useioff could easily be used to tell the optimiser/mapper not to:

(1) use feedback.

(2) generate implicit sync set/reset. Only allow ones that are explicitly defined at the HDL
source level.



Article: 32406
Subject: Re: IOB FF in Synplicity
From: yose@wam.umd.edu (Joe Wetstein)
Date: 26 Jun 2001 02:57:21 -0400
Links: << >>  << T >>  << A >>
In what document can I find a comprehensive list of all of the compiler
directives? There always seems to be a directive for any particular
problem
that I'm having, but I never seem to know about it until I talk to 
someone who has had the problem before and knew (also, through osmossis, I
suppose) what the right trick was...




In article <86b060d0.0106252123.7784b7fd@posting.google.com>,
Rotem Gazit <rotemg@mysticom.com> wrote:
>Rick,
>Try putting the directive :
>/* synthesis syn_useioff=1  syn_srlstyle = "registers" */ 
>In your module declaration.
>If you don't have internal feedbacks from your output signals that
>should do the trick for you.
>Note that Synplicity tends to merge duplicated registers (use syn_keep
>on these signals to prevent this) and convert sequential register to
>SRL16.
>
>Cheers,
>
>Rotem Gazit
>MystiCom LTD
>mailto:rotemg@mysticom.com
>http://www.mysticom.com/
>
>
>
>
>Rick Collins <spamgoeshere4@yahoo.com> wrote in message news:<3B3687A7.9E58CDF8@yahoo.com>...
>> We are targeting a Xilinx XC4000 part and need to push some registers
>> into the IOBs. We like to keep our designs vendor independant, so we
>> prefer not to instantiate special features in the Verilog, such as IOB
>> FFs. 
>> 
>> I checked on the Xilinx web site and found that there is a directive to
>> designate a register to be implemented in the IOB. The directive is /*
>> synthesis IOB=TRUE */, and is placed in the reg declaration. This is
>> claimed to work with Synplify and Xilinx Alliance. When this was tried,
>> the FFs were still in the CLBs. 
>> 
>> Does anyone have experience with what we are trying to do? Should we
>> give up and instantiate the IOB FFs? 
>> 





































Article: 32407
Subject: 2500AD 68HC05 assembler
From: Leon Willett <leonwillett@hotmail.com>
Date: Tue, 26 Jun 2001 09:16:40 +0200
Links: << >>  << T >>  << A >>
Hi,

Do you have an old copy of the 2500AD 68HC05 assembler and linker? It
has gone out of production and is impossible to find.

Thanks


Article: 32408
Subject: Re: Xilinx logic usage
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 26 Jun 2001 09:35:33 +0200
Links: << >>  << T >>  << A >>
"Andrew Bridger" <andrew.bridger@xtra.co.nz> writes:

> Hi,
> We are using Xilinx ISE 3.1, XST compilier.  The xilinx tools appear to be
> telling me my design is using approximately twice as much logic as I would
> expect.  Consequently it does not fit the device I have targeted(XC2S50).

Have you played with the various options to "map", e.g. -c n  -detail
-pr b -r?

Try map -c 1 -detail and look at the result even though I'm pretty
sure you will not be able to route your design after this...

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 32409
Subject: BUFGs in an XC4000EX
From: Guido Pohl <pohl@fokus.gmd.de>
Date: Tue, 26 Jun 2001 10:23:57 +0200
Links: << >>  << T >>  << A >>
Hello out there,
I have the following question regarding BUFGs in an XC4000EX:

Is it possible to feed a signal coming from a "normal" pin to the global nets?
Currently, P&R has problems routing a signal from outside to its destinations.
I do not make any floorplanning and worse, I would like to omit this.

So a colleague had the idea using the BUFGs ...
If it is possible to use them from a non-dedicated clock pin, would this have
any advantages?

Thanks for any comments on this matter, sincerely


Guido

Article: 32410
Subject: Re: Register balancing in FPGA Express
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 26 Jun 2001 10:56:04 +0200
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:

> Synplicity,  please read the above.  In future versions you should consider
> changing the inference of an SRL16 to infer an SRL16 plus an FD to avoid the
> clock to Q penalty.

I think they have. It works in 6.2.4 at least.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 32411
(removed)


Article: 32412
Subject: FPGA manufacturers
From: "Seb C" <lerebel@fr.st>
Date: Tue, 26 Jun 2001 10:24:45 GMT
Links: << >>  << T >>  << A >>
hi,

i just want to know the advantage and disadvantage between different
manufacturers of fpgas.

Thks

SEB

--
********************************
lerebel@fr.st
http://www.lerebel.fr.st
********************************
Je suis bien dans ma peau,
elle est juste  ma taille.
______________________



Article: 32413
Subject: Re: IOB FF in Synplicity
From: rotemg@mysticom.com (Rotem Gazit)
Date: 26 Jun 2001 03:48:24 -0700
Links: << >>  << T >>  << A >>
yose@wam.umd.edu (Joe Wetstein) wrote in message news:<9h9boh$7rj@rac1.wam.umd.edu>...
> In what document can I find a comprehensive list of all of the compiler
> directives? There always seems to be a directive for any particular
> problem
> that I'm having, but I never seem to know about it until I talk to 
> someone who has had the problem before and knew (also, through osmossis, I
> suppose) what the right trick was...

Check out:
Synplify help -> YOUR_VENDOR Attribute and Directive Table

Also:
http://www.synplicity.com/literature/index.html 
some APPLICATION NOTES and VENDOR-SPECIFIC APPLICATION NOTES
Rotem.




> 
> 
> 
> 
> In article <86b060d0.0106252123.7784b7fd@posting.google.com>,
> Rotem Gazit <rotemg@mysticom.com> wrote:
> >Rick,
> >Try putting the directive :
> >/* synthesis syn_useioff=1  syn_srlstyle = "registers" */ 
> >In your module declaration.
> >If you don't have internal feedbacks from your output signals that
> >should do the trick for you.
> >Note that Synplicity tends to merge duplicated registers (use syn_keep
> >on these signals to prevent this) and convert sequential register to
> >SRL16.
> >
> >Cheers,
> >
> >Rotem Gazit
> >MystiCom LTD
> >mailto:rotemg@mysticom.com
> >http://www.mysticom.com/
> >
> >
> >
> >
> >Rick Collins <spamgoeshere4@yahoo.com> wrote in message news:<3B3687A7.9E58CDF8@yahoo.com>...
> >> We are targeting a Xilinx XC4000 part and need to push some registers
> >> into the IOBs. We like to keep our designs vendor independant, so we
> >> prefer not to instantiate special features in the Verilog, such as IOB
> >> FFs. 
> >> 
> >> I checked on the Xilinx web site and found that there is a directive to
> >> designate a register to be implemented in the IOB. The directive is /*
> >> synthesis IOB=TRUE */, and is placed in the reg declaration. This is
> >> claimed to work with Synplify and Xilinx Alliance. When this was tried,
> >> the FFs were still in the CLBs. 
> >> 
> >> Does anyone have experience with what we are trying to do? Should we
> >> give up and instantiate the IOB FFs? 
> >>

Article: 32414
Subject: Alpha Particle
From: Michael Boehnel <boehnel@iti.tu-graz.ac.at>
Date: Tue, 26 Jun 2001 13:18:23 +0200
Links: << >>  << T >>  << A >>
Hi, all!

State machines (SM) are made more secure with additional logic which
detects an illegal state. If an illegal state occurs the SM is forced to
a special state (trap state; reset state) from where it can start
working correctly again. So far so good.

What happens, if the additional logic is placed in LUTs of an FPGA?
Aren't the LUTs vulnerable from radiation too?
Is there a better protection for the configuration than for the FPGA's
FFs?

Michael



Article: 32415
Subject: Re: Alpha Particle
From: "Anthony Ellis" <remove_anthony@ams.co.za>
Date: Tue, 26 Jun 2001 13:45:20 +0200
Links: << >>  << T >>  << A >>
I am just busy doing an FPGA design for a flight safety, certified product.
From what I have gathered LUT FPGA's are not recommended unless one can
guarantee, by continuous test, scrubbing etc, that the device is still
performing per original configuration. Not trivial do do this "on-line".



Michael Boehnel wrote in message <3B386F7F.C29974E0@iti.tu-graz.ac.at>...
>Hi, all!
>
>State machines (SM) are made more secure with additional logic which
>detects an illegal state. If an illegal state occurs the SM is forced to
>a special state (trap state; reset state) from where it can start
>working correctly again. So far so good.
>
>What happens, if the additional logic is placed in LUTs of an FPGA?
>Aren't the LUTs vulnerable from radiation too?
>Is there a better protection for the configuration than for the FPGA's
>FFs?
>
>Michael
>
>



Article: 32416
Subject: Re: Alpha Particle
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Jun 2001 12:46:18 GMT
Links: << >>  << T >>  << A >>
There are varying degrees of protection, depending on the level of risk.  The
simplest, of course, is to go with no protection.  In applications where the risk
of upset is small or the risk of damage due to an upset is small, this is the
route usually taken, as it is the cheapest.  Where the risk or cost of an upset
is increased there are a number of measures that can be used to detect and
recover from an upset, including voting circuits (aka triple mode redundancy),
periodic "scrubbing" of the configuration, periodic test vectors, monitoring
configuration, and monitoring results.  Some combination of these techiques as
well as some not mentioned should cover you for even the most demanding
environments.  I am aware of the results of radiation testing on the VIrtex
parts; they compare very favorably with both the SRAM elsewhere in the system, as
well as microcontrollers in the system.  Upsets in the design flip-flops are
considerably more frequent than upsets in the configuration latches because of
the design of the latches.  The configuration latches are designed for more
robustness at the cost of performance (you don't need high performance in the
configuration latches).

There are some gotchas in the Vitrex & VirtexE silicon if you intend to do
continuous readback of the configuration:  You cant read back any columns with
LUTs configured as SRL16s or CLB RAM while the clock is running because it upsets
the configuration of those cells.  This limits scrubbing to columns that do not
contain those cells.  I do have designs going into space using the Virtex QPro
parts.  In these cases, we opted for putting periodic test vectors through the
logic (these are signal processors) to check the health of the logic for
non-critical operations, and to use triple mode redundancy for the few critical
operations where a short term upset could not be tolerated.  The QPro parts have
an epitaxial layer that helps to reduce the radiation effects.  If you are going
to be working in an environment where single event upsets are a concern, you
should probably be using those parts.  It may be a little frustrating because in
that case your biggest fastest part is equivalent to an XCV1000-4.

In any event, SRAM based FPGAs are suitable for environments with elevated risk
of single event upsets.  As with microprocessors or memory placed in that
environment, there are extra precautions that can be taken to minimize the risks.

Kolja Sulimma wrote:

> Continuous reconfiguration should help reduce this problem.
>
> Also,  modern FPGAs are likely to be implemented in SOI (how about Virtex-II
> ?) which is less sensible to charge insertion by alpha particles.
>
> At an extra nanosecond per LUT and a factor of two increase in area you can
> implement every LUT twice and use the carry XOR to compare the result of the
> two LUTs. You can then combine the XOR outputs with the SOP  OR gates.
>
> A more complicated aproach takes each block of combinational logic, derives
> the equation of the parity of the outputs as a function of the inputs,
> performes logic optimizations and implements this carry bit in seperate LUTs.
> The parity of the output is then compared to this bit.
> LEON reports something 30% area overhead for this technique.
>
> Kolja Sulimma
>
> Anthony Ellis wrote:
>
> > I am just busy doing an FPGA design for a flight safety, certified product.
> > From what I have gathered LUT FPGA's are not recommended unless one can
> > guarantee, by continuous test, scrubbing etc, that the device is still
> > performing per original configuration. Not trivial do do this "on-line".
> >
> > Michael Boehnel wrote in message <3B386F7F.C29974E0@iti.tu-graz.ac.at>...
> > >Hi, all!
> > >
> > >State machines (SM) are made more secure with additional logic which
> > >detects an illegal state. If an illegal state occurs the SM is forced to
> > >a special state (trap state; reset state) from where it can start
> > >working correctly again. So far so good.
> > >
> > >What happens, if the additional logic is placed in LUTs of an FPGA?
> > >Aren't the LUTs vulnerable from radiation too?
> > >Is there a better protection for the configuration than for the FPGA's
> > >FFs?
> > >
> > >Michael
> > >
> > >

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



Article: 32417
Subject: Re: Xilinx Configuration Bitstream
From: Michael Stevens <michael.stevens@alcatel.com>
Date: Tue, 26 Jun 2001 09:20:29 -0400
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------6DB7B79BFAFEB37229124B80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Do you know if they have published anything regarding the ancient xc2000 series?

I recently picked up a bunch of recycled xc2018's figuring I'd learn some VHDL
and
get some home projects on the go.  Finding S/W to do P&A and to generate the
configuration
bitstream seems to be difficult as the current batch of free tools do not
support these
discontinued devices.


Cheers,
Michael



--------------6DB7B79BFAFEB37229124B80
Content-Type: text/x-vcard; charset=us-ascii;
 name="michael.stevens.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Michael Stevens
Content-Disposition: attachment;
 filename="michael.stevens.vcf"

begin:vcard 
n:Stevens;Michael
tel;work:(613) 784-6145
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:michael.stevens@alcatel.com
x-mozilla-cpt:;10896
fn:Michael Stevens
end:vcard

--------------6DB7B79BFAFEB37229124B80--


Article: 32418
Subject: Re: Xilinx Configuration Bitstream
From: hamish@cloud.net.au
Date: Tue, 26 Jun 2001 14:00:39 GMT
Links: << >>  << T >>  << A >>
Steve Casselman <sc@vcc.com> wrote:
> constant just the data content of the ram is changed). We just showed this
> at live at DAC where we were the only company doing partial reconfiguration.

Is that partial reconfiguration using the actual features in the tools/chips
though? Or did you just change the block RAM contents the regular way?


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 32419
Subject: Re: Register balancing in FPGA Express
From: hamish@cloud.net.au
Date: Tue, 26 Jun 2001 14:11:13 GMT
Links: << >>  << T >>  << A >>
Alan Nishioka <alann@accom.com> wrote:
> My designs up to now are all pipelined by hand.  I was hoping to save some time
> in the future, or squeeze a little more performance out of existing designs.

> Are the tools able to do this?  Am I misunderstanding their capabilities?

Synplify has this. I tried it a couple of times and found that the estimated
clock frequency in the synthesis log file was always LOWER when retiming
was enabled. I didn't experiment further.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 32420
Subject: Xilinx System Generator Simulation Problem
From: "JianYong Niu" <cop00jn@shef.ac.uk>
Date: Tue, 26 Jun 2001 15:15:01 +0100
Links: << >>  << T >>  << A >>
Hi, All:

I am using Xilinx System Generator to design an application in Matlab
simulink evironment. I use ModelSim starter version to simulate the design.

Problems occured while the vcom.do file was excecuted:

I have changed the %XILINX% token in the vcom.do file into the xilinx path
in my computer. errors occured as follows:

# ERROR: C:/XILINX/vhdl/src/unisims is not a valid library: no info file.
# ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(14):
Library unisim not found.
# ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(15):
Unknown identifier: unisim
# ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(17):
VHDL Compiler exiting

what is the info file?

I find a info file from my matlab work directory, and copied it into the
xilinx unisims path. then the following errors occured when I run modelsim:

ERROR: Could not find C:/XILINX/vhdl/src/unisims.vcomponents
# ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(15):
cannot find expanded name: unisim.vcomponents
# ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(15):
Unknown field: vcomponents.
# ERROR: C:/MATLABR11/toolbox/xilinx/sysgen/vhdl/synth_reg_w_init.vhd(17):
VHDL Compiler exiting
# ERROR: C:/Modeltech_xe/win32xoem/vcom failed.

However, I do find a file 'unisims.vcomp' in the directory. what is the
problem?

thanks.

Jianyong



Article: 32421
(removed)


Article: 32422
Subject: Re: Alpha Particle
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Tue, 26 Jun 2001 16:27:21 +0200
Links: << >>  << T >>  << A >>
Continuous reconfiguration should help reduce this problem.

Also,  modern FPGAs are likely to be implemented in SOI (how about Virtex-II
?) which is less sensible to charge insertion by alpha particles.

At an extra nanosecond per LUT and a factor of two increase in area you can
implement every LUT twice and use the carry XOR to compare the result of the
two LUTs. You can then combine the XOR outputs with the SOP  OR gates.

A more complicated aproach takes each block of combinational logic, derives
the equation of the parity of the outputs as a function of the inputs,
performes logic optimizations and implements this carry bit in seperate LUTs.
The parity of the output is then compared to this bit.
LEON reports something 30% area overhead for this technique.

Kolja Sulimma


Anthony Ellis wrote:

> I am just busy doing an FPGA design for a flight safety, certified product.
> From what I have gathered LUT FPGA's are not recommended unless one can
> guarantee, by continuous test, scrubbing etc, that the device is still
> performing per original configuration. Not trivial do do this "on-line".
>
> Michael Boehnel wrote in message <3B386F7F.C29974E0@iti.tu-graz.ac.at>...
> >Hi, all!
> >
> >State machines (SM) are made more secure with additional logic which
> >detects an illegal state. If an illegal state occurs the SM is forced to
> >a special state (trap state; reset state) from where it can start
> >working correctly again. So far so good.
> >
> >What happens, if the additional logic is placed in LUTs of an FPGA?
> >Aren't the LUTs vulnerable from radiation too?
> >Is there a better protection for the configuration than for the FPGA's
> >FFs?
> >
> >Michael
> >
> >


Article: 32423
Subject: Re: XPower
From: John Hubbard <John.Hubbard@xilinx.com>
Date: Tue, 26 Jun 2001 08:36:59 -0600
Links: << >>  << T >>  << A >>
Phil,

Here is a response from the FPGA folks regarding accuracy:

"The supported FPGA families (Virtex, Virtex-E, Virtex-II, Spartan-II) have been
verified against suites of characterisation designs for bels and routing resources.
The accuracy, depending on the family, ranges from 80% to over 90% of the designs
achieving 10%. Some customer designs for Virtex have shown the same accuracy levels.
Spartan2e could not be verified because we don't have any silicon yet."

Thanks!
John Hubbard, CPLD Applications Engineer


John Hubbard wrote:

> Phil,
>
> I personally have performed correlation testing for the Xilinx CoolRunner XPLA3
> CPLDs.  I have a test suite containing simple designs, more complex designs, and
> very complex designs.  In all cases of the production released devices, >90% have
> been within +/-10% accuracy with the remaining 10% within +/-20% accuracy.  I speak
> only for the production released Xilinx CoolRunner XPLA3 CPLDs and will forward your
> question to those devoted to the Xilinx FPGAs.
>
> Thanks!
> John
>
> Phil Hays wrote:
>
> > I've just today tried Xilinx's new power estimation tool, XPower.  XPower is
> > "early access" software, which I think is a new code name for beta software.
> > I'm working on a design with a tight power and cooling budget, and power
> > estimation is difficult.  The measured difference between the spreadsheet
> > estimates and the real hardware in my past designs has been 2:1, 4:1 or worse,
> > which might lead to wildly over designed power supplies or worse.  With large
> > power budgets in past designs, this hasn't been a problem for me, however this
> > project is different.  While the answer I get from this tool is a lot closer to
> > what I expect (and rather less than the spreadsheet estimate), and less than my
> > power budget, I'm wondering how accurate this tool's results are.  Any XPower
> > users that have verified results against real hardware care to speak out?
> >
> > This tool uses a simulation pattern out of ModelSim and the placed and routed
> > design, so with a realistic simulation pattern I would expect a fairly realistic
> > answer.
> >
> > If you haven't seen this tool yet, answer 10667 has a pointer to the download
> > page, or search answers for for XPower.  Skip the GUI, it's gakky buggy, run in
> > command line mode.
> >
> > --
> > Phil Hays


Article: 32424
Subject: Re: Xilinx logic usage
From: John_H <johnhandwork@mail.com>
Date: Tue, 26 Jun 2001 15:41:03 GMT
Links: << >>  << T >>  << A >>
Though I'm not familiar with the XST compiler, I've dealt with this issue in the
Spartan-II architecture.  Familiarization with the slice structure can help -
there's a more detailed view of the slice in the Virtex data sheet than there is
in the Spartan-II though they are the same architecture.

Any one slice can have only one clock and one clock enable.  Multiple clock
domains start to "sectionalize" the design.

Set/reset signals have to be the same for both flops in a slice - either both
unused or both use the same signal(s).  I went to great lengths to get my
Synplify synthesizer to avoid FDR and FDS style primitives to avoid "losing"
registers to special S/R signals.

SRL and CLB selectRAM blocks use the same signal for write enable that feeds the
Init (S/R) on the flops which can complicate the layout.

MUXF5 and MUXF6 elements require the BX (both) and BY (F6) inputs allowing the
registers only to be used for the MUX signals since lone registers need the BX
or BY inputs for the "direct input" arrangement.

These are some of the issues.  I wouldn't be surprised, however, if the Xilinx
mapper just falls short;  it does in many other aspects.  Your numbers *should*
produce a decent design but my faith in the mapper is limited.

- John



Andrew Bridger wrote:

> Hi,
> We are using Xilinx ISE 3.1, XST compilier.  The xilinx tools appear to be
> telling me my design is using approximately twice as much logic as I would
> expect.  Consequently it does not fit the device I have targeted(XC2S50).
>
> The design uses 1005 flip flops and 881 LUT's as shown below.  I expected
> the xilinx tools to use both the flip flop and LUT within a logic cell.  2
> Logic cells = 1 slice.  2 slices = 1 CLB.  So each slice has 2 flipflops and
> 2 LUT's.
>
> So I expected the design to use approximately 1005 /2 = 500 slices.   But
> no, xilinx tool tells me 909 slices have been used, which is too much for
> the device.  Anyone got any ideas on what I am doing wrong?  I have tried
> optimising for area or speed at synthesis.  Almost identical result.  (I
> also tried putting the place and route effort up to max, but again very
> little effect.)
>
> Surely the LUT and flipflop can both be used within a logic cell??
>
> Any ideas would be much appreciated.
>
> Design Summary:
>    Number of errors:      1
>    Number of warnings:    2
>    Number of Slices:                909 out of    768  118%
>    Number of Slices containing
>       unrelated logic:               35 out of    909    3%
>    Number of Slice Flip Flops:    1,005 out of  1,536   65%
>    Total Number 4 input LUTs:       881 out of  1,536   57%
>       Number used as LUTs:                        865
>       Number used as a route-thru:                 16
>    Number of bonded IOBs:            86 out of    176   48%
>    Number of Tbufs:                  16 out of    832    1%
>    Number of GCLKs:                   2 out of      4   50%
>    Number of GCLKIOBs:                2 out of      4   50%
> Total equivalent gate count for design:  15,144
> Additional JTAG gate count for IOBs:  4,224
>
> Thanks Andrew




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