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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 12275

Article: 12275
Subject: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5
From: Nestor Caouras <nestor@ece.concordia.ca>
Date: Wed, 07 Oct 1998 16:18:17 -0400
Links: << >>  << T >>  << A >>
Hi.

I was wondering if anyone could help me out regarding an implementation
issue I have run into when using Xilinx Foundation F1.5.

I have implemented a design with the new F1.5 version and the results
were worse than with F1.4 (the opearting frequency dropped by a few
MHz).  I also noticed a difference in implementation statistics going
from M1.3 to F1.4 to F1.5 as well.

I have used Synplify 5.06 to synthesize my VHDL code and to instantiate
some core generator black boxes (do I need to regenerate my F1.4 cores
with the new core generator 1.5?).  The same XNF file was used for all
versions of the Foundation tools and targetted a xc4028EX-3HQ240 part. 
I have also written a user constraint file (UCF) with basic clock period
and pin locking attributes in order to meet a required performance
(thanks to everyone who explained some of the constraints to me). All
the constraints remained the same for all implementations.

Anyhow, here are the results I got when going from one version to the
next (please see the end to see my conclusions):
->M1.3 (UNIX) : 
  -before place and route :  
    Minimum period:   5.496ns (Maximum frequency: 181.951MHz)
    Maximum path delay from/to any node:  27.141ns
    Timing constraint: 
       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
         Minimum period is  5.496ns
       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
         Maximum delay is  27.141ns	
 -after place and route : 
    Minimum period:  23.752ns (Maximum frequency:  42.102MHz)
    Maximum path delay from/to any node:  37.324ns
    Timing constraint: 
       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
         Minimum period is  23.752ns
       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
         Maximum delay is  37.324ns


->F1.4 (PC) : 
  -before place and route :  
    Minimum period:   5.496ns (Maximum frequency: 181.951MHz)
    Maximum path delay from/to any node:  27.000ns
    Timing constraint: 
       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
         Minimum period is  5.496ns
       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
         Maximum delay is  27.000ns	
 -after place and route : 
    Minimum period:  29.991ns (Maximum frequency:  33.343MHz)
    Maximum path delay from/to any node:  54.635ns
    Timing constraint: 
       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
         Minimum period is  29.991ns
       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
         Maximum delay is  54.635ns


->F1.5 (PC) : 
  -before place and route :  
    Minimum period:   27.000ns (Maximum frequency: 37.037MHz)
    Maximum path delay from/to any node:  27.000ns
    Timing constraint: 
       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
         Minimum period is  5.496ns
       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
         Maximum delay is  27.000ns	
 -after place and route : 
    Minimum period:  35.423ns (Maximum frequency:  28.230MHz)
    Maximum path delay from/to any node:  35.423ns
    Timing constraint: 
       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
         Minimum period is  21.653ns
       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
         Maximum delay is  35.423ns

So based on these results, can I claim that design M1.3 will run at
42MHz, design F1.4 at 33MHz and design F1.5 at 28.230MHz? If so, why
does the older tool give a better result than the other two, and why
does the frequency degrade as the software gets better and better?  It's
a little frustrating to see such behaviour when moving to an updated
version of the software.


It seems to me that for F1.5, the maximum frequency is determined by the
maximum delay based on the "FROM FFS TO FFS" constraint.  In the
previous versions it was using the minimum period value (based on the
minimum clock net period, coming from the PERIOD constraint).  I am very
curious to know why each design has a different operating frequency when
the design and the constraint files have not changed at all.  The layout
of the placed design is also different between F1.4 and F1.5. Does
anyone know why this happens?



Also, for M1.5 I get this warning after running trace (trce) on the
routed design:
 
WARNING:bastw:544 - Clock nets using non-dedicated resources were found
in this design. Clock skew on these resources will not be automatically
addressed during path analysis. To create a timing report that analyzes
clock skew for these paths, run trce with the '-skew' option.

When I check in EPIC, the clock paths seem to be connected to the
dedicated net of the chip, and when I run the trce program with the
-skew option as they state I don't this warning, but the frequency is
still the same (28.230MHz).


Here's something I never thought could happen, but it did...
When I created the bitmap file using bitgen, I got a warning that an
antenna has been created and may be caused by an unrouted net or a stub.
All nets were routed so it seems like the second case applies. When I
view the placed and routed design in EPIC, indeed I see a route that is
just protruding out of the routed net.  Any suggestions on how to
correct this type of problem.


Thanks in advance to anyone who can help me out with anything from the
above.

-- 
Nestor Caouras
nestor@ece.concordia.ca
http://www.ece.concordia.ca/~nestor/addr.html 
|-------------------------------------------|
| Dept. of Electrical and Computer Eng.     |
| Concordia University                      |
| 1455 de Maisonneuve Blvd (West)           |
| Montreal, Quebec, Canada H3G 1M8.         |
| Tel: (514)848-8784    Fax: (514)848-2802  |
|-------------------------------------------|
Article: 12276
Subject: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5 (MORE INFO)
From: Nestor Caouras <nestor@ece.concordia.ca>
Date: Wed, 07 Oct 1998 16:22:46 -0400
Links: << >>  << T >>  << A >>
I forgot to mention that I manually instantiated a BUFG for the clock
net and placed a constraint on the net at the output of the BUFG:

fsa --> BUFG  --> clk_net

A constraint of 25ns was placed on clk_net, and one of 20ns FROM FFS TO
FFS.

Thanks for your help.


Original Message
Nestor Caouras wrote:
> 
> Hi.
> 
> I was wondering if anyone could help me out regarding an implementation
> issue I have run into when using Xilinx Foundation F1.5.
> 
> I have implemented a design with the new F1.5 version and the results
> were worse than with F1.4 (the opearting frequency dropped by a few
> MHz).  I also noticed a difference in implementation statistics going
> from M1.3 to F1.4 to F1.5 as well.
> 
> I have used Synplify 5.06 to synthesize my VHDL code and to instantiate
> some core generator black boxes (do I need to regenerate my F1.4 cores
> with the new core generator 1.5?).  The same XNF file was used for all
> versions of the Foundation tools and targetted a xc4028EX-3HQ240 part.
> I have also written a user constraint file (UCF) with basic clock period
> and pin locking attributes in order to meet a required performance
> (thanks to everyone who explained some of the constraints to me). All
> the constraints remained the same for all implementations.
> 
> Anyhow, here are the results I got when going from one version to the
> next (please see the end to see my conclusions):
> ->M1.3 (UNIX) :
>   -before place and route :
>     Minimum period:   5.496ns (Maximum frequency: 181.951MHz)
>     Maximum path delay from/to any node:  27.141ns
>     Timing constraint:
>        TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>          Minimum period is  5.496ns
>        TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>          Maximum delay is  27.141ns
>  -after place and route :
>     Minimum period:  23.752ns (Maximum frequency:  42.102MHz)
>     Maximum path delay from/to any node:  37.324ns
>     Timing constraint:
>        TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>          Minimum period is  23.752ns
>        TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>          Maximum delay is  37.324ns
> 
> ->F1.4 (PC) :
>   -before place and route :
>     Minimum period:   5.496ns (Maximum frequency: 181.951MHz)
>     Maximum path delay from/to any node:  27.000ns
>     Timing constraint:
>        TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>          Minimum period is  5.496ns
>        TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>          Maximum delay is  27.000ns
>  -after place and route :
>     Minimum period:  29.991ns (Maximum frequency:  33.343MHz)
>     Maximum path delay from/to any node:  54.635ns
>     Timing constraint:
>        TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>          Minimum period is  29.991ns
>        TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>          Maximum delay is  54.635ns
> 
> ->F1.5 (PC) :
>   -before place and route :
>     Minimum period:   27.000ns (Maximum frequency: 37.037MHz)
>     Maximum path delay from/to any node:  27.000ns
>     Timing constraint:
>        TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>          Minimum period is  5.496ns
>        TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>          Maximum delay is  27.000ns
>  -after place and route :
>     Minimum period:  35.423ns (Maximum frequency:  28.230MHz)
>     Maximum path delay from/to any node:  35.423ns
>     Timing constraint:
>        TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>          Minimum period is  21.653ns
>        TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>          Maximum delay is  35.423ns
> 
> So based on these results, can I claim that design M1.3 will run at
> 42MHz, design F1.4 at 33MHz and design F1.5 at 28.230MHz? If so, why
> does the older tool give a better result than the other two, and why
> does the frequency degrade as the software gets better and better?  It's
> a little frustrating to see such behaviour when moving to an updated
> version of the software.
> 
> It seems to me that for F1.5, the maximum frequency is determined by the
> maximum delay based on the "FROM FFS TO FFS" constraint.  In the
> previous versions it was using the minimum period value (based on the
> minimum clock net period, coming from the PERIOD constraint).  I am very
> curious to know why each design has a different operating frequency when
> the design and the constraint files have not changed at all.  The layout
> of the placed design is also different between F1.4 and F1.5. Does
> anyone know why this happens?
> 
> Also, for M1.5 I get this warning after running trace (trce) on the
> routed design:
> 
> WARNING:bastw:544 - Clock nets using non-dedicated resources were found
> in this design. Clock skew on these resources will not be automatically
> addressed during path analysis. To create a timing report that analyzes
> clock skew for these paths, run trce with the '-skew' option.
> 
> When I check in EPIC, the clock paths seem to be connected to the
> dedicated net of the chip, and when I run the trce program with the
> -skew option as they state I don't this warning, but the frequency is
> still the same (28.230MHz).
> 
> Here's something I never thought could happen, but it did...
> When I created the bitmap file using bitgen, I got a warning that an
> antenna has been created and may be caused by an unrouted net or a stub.
> All nets were routed so it seems like the second case applies. When I
> view the placed and routed design in EPIC, indeed I see a route that is
> just protruding out of the routed net.  Any suggestions on how to
> correct this type of problem.
> 
> Thanks in advance to anyone who can help me out with anything from the
> above.
> 
> --
> Nestor Caouras
> nestor@ece.concordia.ca
> http://www.ece.concordia.ca/~nestor/addr.html
> |-------------------------------------------|
> | Dept. of Electrical and Computer Eng.     |
> | Concordia University                      |
> | 1455 de Maisonneuve Blvd (West)           |
> | Montreal, Quebec, Canada H3G 1M8.         |
> | Tel: (514)848-8784    Fax: (514)848-2802  |
> |-------------------------------------------|

-- 
Nestor Caouras
nestor@ece.concordia.ca
http://www.ece.concordia.ca/~nestor/addr.html 
|-------------------------------------------|
| Dept. of Electrical and Computer Eng.     |
| Concordia University                      |
| 1455 de Maisonneuve Blvd (West)           |
| Montreal, Quebec, Canada H3G 1M8.         |
| Tel: (514)848-8784    Fax: (514)848-2802  |
|-------------------------------------------|
Article: 12277
Subject: Re: Synthesis: Exemplar or Synopsys
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 7 Oct 1998 20:42:58 GMT
Links: << >>  << T >>  << A >>
In article <361BB37B.9540843C@synopsys.com>,
Derek Palmer  <derekp@synopsys.com> wrote:
>Let's make rumor fact!
>FPGA Express 3.0 will have VHDL 93 support.
>Available on the Synopsys web site at the end of Oct.
Great!

Just like Metamor!!




>
>Derek Palmer
>FPGA Express Team
>Synopsys Corporation.
>
>Andy Peters wrote:
>
>>     Hans Lindkvist wrote in message <3614BD09.E32A0E14@ldecs.ericsson.se>...
>>     Rickman wrote:
>>         Jake Janovetz wrote:
>>         One possibly big difference, depending on whether you have existing
>>         code, is that Synopsys does not support VHDL-93. They seem to be
>> pretty
>>         stuck in VHDL-87.
>>         Otherwise, I can only stay that Synopsys is what comes with Xilinx
>>         Foundation, so a lot of Xilinx users have it!   ;)
>>
>> I've heard from a Synopsys representative that vhdl-93 support is close.
>> I just got the Xilinx Foundation 1.5 tools w/Synopsys FPGA Express, and
>> there's support for *some* VHDL'93 things, like rising_edge() and
>> falling_edge() and myprocess : process (yadda) IS.
>>
>> A start.
>>
>> -andy
>
>
>


Article: 12278
Subject: Re: Help Desperately Needed with Altera Microprocessor Design.
From: fliptron@netcom.com (Philip Freidin)
Date: Wed, 7 Oct 1998 20:57:34 GMT
Links: << >>  << T >>  << A >>
>michael_23@my-dejanews.com wrote:
>> 
>> Hi all,
>>         I desperately need some help. I am doing my final year engineering
>> project where I am designing a 16 bit Microprocessor. I am using the student
>> version of Altera for this project, which gives me the EPF10K20RC240-4 device.
>
>...snip...

In article <361BC6C9.333CF669@yahoo.com> Rickman <spamgoeshere4@yahoo.com> writes:
> snip
>Or you can call Xilinx support at 800-624-4782. They may want you to
>send them your design files to solve this.

While Xilinx Tech support is well known for being helpfull, This problem
is not likely to be something they can solve. :-)

Philip

Article: 12279
Subject: Altera's reply to request for Max+Plus II under Linux
From: timo@novaengr.com (Tim O)
Date: Wed, 07 Oct 1998 21:14:30 GMT
Links: << >>  << T >>  << A >>
I'd emailed Altera to express my interest in someday having a version
of Max+Plus II that runs under Linux.  I figured I'd copy their reply
for the sake of any interested parties out there.  This is purely for
the interested, I don't mean to imply any opinions on the letter's
content (I'm feeling passive today).



here 'tis...


Hello Tim,

	I have documented your request for a Linux based Max+Plus II.
We have looked into that option a bit, and the concensus was that
there was not enough customer interest in Linux to make it a
worthwhile investment.  However, if more and more customers continue
to request support for that operating system, it will eventually be
looked at more seriously.  One of the major problems with supporting
Linux is the fact that there is no person or company who is
responsible for supporting it.  So if we made a version of
software which would run on Linux and then there was an operating
system problem----it would be our job to fix that, and we would have
no Linux experts or designers to talk too.  As far as I know, that
fact and the lack of customer interest are the only reasons why such a
version is not available right now.  

Thank you very much for the suggestion, it's always nice to know what
else is needed in the market..  And please tell others who would like
to see such support to e-mail us at sos@altera.com
<mailto:sos@altera.com>  so that their requests can be appropriately
documented.  Please feel free to contact me if you have more
questions, or ideas about Linux based Max+PlusII.  And
remember that Altera Applications is always there to help you solve
any problems you may experience with our products or software, don't
hesitate to call them at 1800-800-EPLD if you are in need of support. 

Jeff Wimett            
Applications Engineer          
Altera Corporation                
E-mail:  Jwimett@altera.com <mailto:Jwimett@altera.com>  
Phone: 1-800-800-EPLD ext. 4142  


Article: 12280
Subject: Re: Verilog Simulators
From: "Ken Coffman" <kcoffman@intermec.com>
Date: 7 Oct 1998 21:38:42 GMT
Links: << >>  << T >>  << A >>
At the company I worked at, we looked at Exemplar, Synplicity, and Synopsys
FPGA Express. I got the best and fastest design with Synplicity, Exemplar
was a close 2nd. We ended up buying Exemplar because we got a good price
when bundled with Model Tech's ModelSim. Both these products are very good
and both have a path to ASIC design (though Exemplar is about 6 months
ahead right now). FPGA Express was usable, but the results were not near as
good as the other two. I have not looked at FPGA Express recently, but have
heard its better now. You won't know until you try it on your own design.

Rick Filipkiewicz <rick@algor.co.uk> wrote in article
<361B7394.B3C009DF@algor.co.uk>...
> Thanks for the various replies, it seems to be coming down to a choice
> between Silos III and ModelSim with Fintronics on the outside [don't know
> enough about  it yet]. It seems that my $5K budget was a bit optimistic
and
> the sim. will probably come in about $7K. Still not bad in comparison
with
> a couple of  years ago.
> 
> Now there's the question of synthesis. Originally I was going to stick
with
> the Synopsis Express  (***)I have as part of the Foundation package but I
> do have the possible options of buying a synthesiser from Synplicity or
> Exemplar [Leonardo].  Anybody have any comments on their quality ?
> Particularly when Xilinx FPGAs are the target devices ?
> 
> (***) BTW Does anybody know if  a command line i/f has been added to
> Foundation Express for the 1.5 release ?
> 
> 
> 
> 
Article: 12281
Subject: Re: USAGE of XILINX "FROM:TO" for VHDL and IMPLEMENTATION
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Wed, 7 Oct 1998 14:55:00 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote in message <361B4477.C9F9BC62@algor.co.uk>...

>Note that  the PERIOD constraint  on CLKx implies a  From/To constraint of
>the type:
>
> TSxx: FROM FFS(Connected to CLKx):TO:FFS(Connected to CLKx): 25

The "gotcha" with PERIOD is that you have to place it on the clock net AFTER
the BUFGx, so you're outta luck if you're using VHDL (unless you want to
look at the .xnf file and find out what the buffered clock net is called).
It's noted in the timing constraints presentation that that little "feature"
is a known problem that will be fixed eventually.

-andy

--
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
520-318-8191
apeters@noao.edu



Article: 12282
Subject: Re: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Wed, 7 Oct 1998 15:09:03 -0700
Links: << >>  << T >>  << A >>
Nestor Caouras wrote in message <361BCC89.7FDD8B2D@ece.concordia.ca>...

>Anyhow, here are the results I got when going from one version to the
>next (please see the end to see my conclusions):
>->M1.3 (UNIX) :
>  -before place and route :
>    Minimum period:   5.496ns (Maximum frequency: 181.951MHz)
>    Maximum path delay from/to any node:  27.141ns
>    Timing constraint:
>       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>         Minimum period is  5.496ns
>       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>         Maximum delay is  27.141ns
> -after place and route :
>    Minimum period:  23.752ns (Maximum frequency:  42.102MHz)
>    Maximum path delay from/to any node:  37.324ns
>    Timing constraint:
>       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>         Minimum period is  23.752ns
>       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>         Maximum delay is  37.324ns

Whoops!  Look at the results for TS04 - you're constraining it to be 20 ns
but the max delay is 37 ns!  It didn't meet your timespec, so all bets are
off!

>->F1.4 (PC) :
>  -before place and route :
>    Minimum period:   5.496ns (Maximum frequency: 181.951MHz)
>    Maximum path delay from/to any node:  27.000ns
>    Timing constraint:
>       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>         Minimum period is  5.496ns
>       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>         Maximum delay is  27.000ns
> -after place and route :
>    Minimum period:  29.991ns (Maximum frequency:  33.343MHz)
>    Maximum path delay from/to any node:  54.635ns
>    Timing constraint:
>       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>         Minimum period is  29.991ns
>       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>         Maximum delay is  54.635ns

Still failing to meet your timespec here, too.

>
>->F1.5 (PC) :
>  -before place and route :
>    Minimum period:   27.000ns (Maximum frequency: 37.037MHz)
>    Maximum path delay from/to any node:  27.000ns
>    Timing constraint:
>       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>         Minimum period is  5.496ns
>       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>         Maximum delay is  27.000ns
> -after place and route :
>    Minimum period:  35.423ns (Maximum frequency:  28.230MHz)
>    Maximum path delay from/to any node:  35.423ns
>    Timing constraint:
>       TS01 = PERIOD TIMEGRP "fsa_grp"  25 nS   HIGH 50.000 % ;
>         Minimum period is  21.653ns
>       TS04 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS" 20 nS  ;
>         Maximum delay is  35.423ns

And here, too!

>So based on these results, can I claim that design M1.3 will run at
>42MHz, design F1.4 at 33MHz and design F1.5 at 28.230MHz? If so, why
>does the older tool give a better result than the other two, and why
>does the frequency degrade as the software gets better and better?  It's
>a little frustrating to see such behaviour when moving to an updated
>version of the software.

I don't think any of the frequencies given are valid, considering that your
design doesn't meet the timing specs.

>It seems to me that for F1.5, the maximum frequency is determined by the
>maximum delay based on the "FROM FFS TO FFS" constraint.  In the
>previous versions it was using the minimum period value (based on the
>minimum clock net period, coming from the PERIOD constraint).  I am very

According to that timing presentation (most recent version dated 7/28/98 and
applicable to 1.5 tools) is that the timing priorities, from highest down,
are: 1) FROM:THRU:TO (which you're not using) 2) FROM:TO (TS04) and then 3)
PERIOD.  I'm not sure what the previous order was.

>curious to know why each design has a different operating frequency when
>the design and the constraint files have not changed at all.  The layout

Again, the design fails to meet timing specs so who knows what's real?

>of the placed design is also different between F1.4 and F1.5. Does
>anyone know why this happens?

Depends on a lot of things.  Perhaps you've got it configured to do a more
vigorous p & r (or less vigorous); maybe you've locked your pins down after
the 1.3 implementation; maybe it's doing its best given that it's not
meeting the design constraints in the first place.

>Also, for M1.5 I get this warning after running trace (trce) on the
>routed design:
>
>WARNING:bastw:544 - Clock nets using non-dedicated resources were found
>in this design. Clock skew on these resources will not be automatically
>addressed during path analysis. To create a timing report that analyzes
>clock skew for these paths, run trce with the '-skew' option.

Maybe you missed something? Schematic design or VHDL?

>When I check in EPIC, the clock paths seem to be connected to the
>dedicated net of the chip, and when I run the trce program with the
>-skew option as they state I don't this warning, but the frequency is
>still the same (28.230MHz).

>Here's something I never thought could happen, but it did...
>When I created the bitmap file using bitgen, I got a warning that an
>antenna has been created and may be caused by an unrouted net or a stub.
>All nets were routed so it seems like the second case applies. When I
>view the placed and routed design in EPIC, indeed I see a route that is
>just protruding out of the routed net.  Any suggestions on how to
>correct this type of problem.

Check the design.

--
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
520-318-8191
apeters@noao.edu



Article: 12283
Subject: Re: Help Desperately Needed with Altera Microprocessor Design.
From: "Gareth Baron" <Gareth.Baron@eng.efi.com>
Date: Wed, 7 Oct 1998 15:48:35 -0700
Links: << >>  << T >>  << A >>
As was mentioned earlier Fatal Error usually implies an Internal software
error.  I have actually come across some Fatal Erros in MAXPLUS2 8.1 when I
was targetting a 10K20RC device.  It turned out that I had multiple Always
(verilog) blocks (more than 8) which used the same Clock signal.  The CLK
was not on a global CLK net and hence the partitioner bombed out on me for
some reason.  The way around this was to merge the Always (verilog) blocks.

I would advise you to talk to Altera directly about this as they are very
helpful.  They will also try your design for you and tell you what options
you will need to set.




michael_23@my-dejanews.com wrote in message
<6vftjf$52c$1@nnrp1.dejanews.com>...
>Hi all,
> I desperately need some help. I am doing my final year engineering
>project where I am designing a 16 bit Microprocessor. I am using the
student
>version of Altera for this project, which gives me the EPF10K20RC240-4
device.
>I have completed my design and I have been testing it as I go, so I know
all
>the components are working properly. Here is my problem, and it is a big
>problem as the deadline is coming up very close and I am starting to panic.
>I was going along fine until I hit this problem. Okay, so when I was at my
>last step (I'm so close) when I was trying to compile the whole thing I got
>the following error about half-way through compilation:
>"Internal Error: (CMP) Fatal application error in Partitioner at 10%"
>
>Does anyone know what this means and what has caused it?
>
>I have done a LOT of fiddling around testing things and trying to figure
>out the problem. I was thinking maybe I have run out of room on the device.
>I broke the top level design up into 2 parts and compiled each one
>seperately with no problems. When I looked at the report file, it says I
>have used the following space:
>
>Mem bits  Mem %   LCs  LCs %
>4608      37%     597  51%      First Half
>
>4096      33%     110  9%       Second Half
>
>8704      70%     707  60%      Total
>
>Looking at this, I have 30% of my memory bits free and 40% of my LCs free
so
>I shouldn't be out of room.
>I am now thinking that maybe I have enough memory bits and LCs but not
>enough connections between them free. Would this seem reasonable to you? I
>was of the impression that you could use the memory bits without affecting
>the use of the LCs and vice vera. That is by using some memory bits you
>don't take room off the LCs. Is this right.
>
>As you can see I am in a horrible mess here and am in desperate need of a
>solution. Does anyone know what I am doing wrong, and any ways of perhaps
>fixing my problem? I would be eternally greatful.
>
>Perhaps there may be some way of changing the Global Logic Synthesis
>settings that might use less space and allow me to fit it all on, or am I
>completely on the wrong track here?
>
>If you have any suggestions at all, then can you PLEASE PLEASE send them to
>me, even if you're not sure it'll work I'm willing to try everything. I've
>tried all I can think of.
>
>Thanks so much,
>Bruce.
>
>PS: I also checked the number of inputs and outputs, and they are all okay
>too.
>
>PPS: Another thought, I wonder if there is a limit of the number of memory
>elements I can use. It will let me use 3 RAM elements, but as soon as I use
>a 4th (even if it is only 4 bits), it comes up with that error again. I
have
>a very strong suspicion this could be what's causing the problem. Can
anyone
>confirm this?
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


Article: 12284
Subject: Re: Help Desperately Needed with Altera Microprocessor Design.
From: "Gareth Baron" <Gareth.Baron@eng.efi.com>
Date: Wed, 7 Oct 1998 16:05:26 -0700
Links: << >>  << T >>  << A >>
I wouldn't have thought so - It's an Altera problem ;-)


Philip Freidin wrote in message ...
>>michael_23@my-dejanews.com wrote:
>>>
>>> Hi all,
>>>         I desperately need some help. I am doing my final year
engineering
>>> project where I am designing a 16 bit Microprocessor. I am using the
student
>>> version of Altera for this project, which gives me the EPF10K20RC240-4
device.
>>
>>...snip...
>
>In article <361BC6C9.333CF669@yahoo.com> Rickman <spamgoeshere4@yahoo.com>
writes:
>> snip
>>Or you can call Xilinx support at 800-624-4782. They may want you to
>>send them your design files to solve this.
>
>While Xilinx Tech support is well known for being helpfull, This problem
>is not likely to be something they can solve. :-)
>
>Philip
>


Article: 12285
Subject: Re: Catching state machine errors (was: A Johnson counter)
From: daveb@iinet.net.au (David R Brooks)
Date: Wed, 07 Oct 1998 23:27:04 GMT
Links: << >>  << T >>  << A >>
Jonathan Bromley <jsebromley@brookes.ac.uk> wrote:
[snip]
:Other posters have pointed out that a screwed-up state machine
:(or anything) that subsequently recovers is, in a high-rel system,
:hardly any better than a screwed-up state machine that stays 
:screwed-up.  I beg to differ.  OK, so the original problem
:may have corrupted some data or transaction somewhere, but at
:least your system is still running and you have a sporting
:chance of detecting and correcting the error at some higher
:level (maybe even software, if that isn't heretical here!)
:where it is easier to implement redundancy.  And there are many
:situations (graphics systems, for example) where transient problems
:are unpleasant but far from catastrophic, whereas a locked-up
:state machine could mean effective total failure of the system.
:
:I wonder if there are any locked-up cycles in the state machines 
:in my car's engine management?  Probably not, it's implemented
:in software :-)

 Intel published an app note "Designing High Reliability Software for
Automotive Applications" some 20 years ago. Very 8048-centred, but the
techniques can be extrapolated.
 Some time ago, I did a system for automatically opening bottom-dump
doors on 100-ton bulk rail wagons. The railroad were (very properly)
much concerned to ensure the thing wouldn't dump inadvertently, with
the train running at speed. The system was partly in firmware (with a
standard watchdog arrangement), partly in an ASIC. Besides the actual
output-circuit switches, there was a "safety catch" comprising a FET
switch in the output-power line, whose gate was driven by a resonant
L-C circuit feeding a diode. The L-C being AC coupled to a CPU output
port.
 The software had to generate a run of several pulses (at the correct
frequency) before the diode would pump up the FET gate. The
time-constant of the L-C/FET being longer than that of the watchdog.
Worked well.


--  Dave Brooks    <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
Article: 12286
Subject: Re: Verilog Simulators
From: mtlawson@best.com (Todd Lawson)
Date: Wed, 07 Oct 1998 23:50:21 GMT
Links: << >>  << T >>  << A >>
I have been using FPGA express and synplicity at both my job at Cisco
and now at the startup I'm at. I was really happy with Synplicity (I
used it at Cisco) and now use FPGA Express. I hate the lack of info I
receive from FPGA express and the bugs, but I did a few A/B
comparisons between Synplify and FPGA express and FPGA Express
synthesized better. My target is Xilinx FPGAs (4028 size) and I was
using about 60-80% of the CLBs. FPGA Express synthesized about 2-4 ns
better on synchronous sections than Synplify. Now, granted, in the
test I took code that was meeting timing in FPGA Express and just
dropped it into Synplify, so there was no optimization perfromed to
conform to Synplify. However, I'm one of these guys that writes purely
synchronous logic with little combo. I.E. 99% of the logic was "always
@(posedge clock)" and a few "assign" statements.

End result, I love Synplify, but it did not synthesize as well as FPGA
express.

We will look at them both again in the near future as we re-evaluate
our tools.

On the simulation tools question, we use the Veribest line of Verilog
simulation and waveform viewer. It is cheap, has some bugs, some of
the coding and features are hobby quality ("Why the *hell* did they do
that?!?!? Why didn't they ask someone who *uses* this how they would
like it done? etc.") and the waveform viewer is feature-empty, bare
bones. However, the customer support has been top notch and we have
been able to get the work done, so that says a lot.  I would recommend
anyone wanting to buy a tool set to give them a look, but make sure
you look at the alternatives as well.

Feel free to call me if you want more info.

Todd


On Wed, 07 Oct 1998 14:58:45 +0100, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>Thanks for the various replies, it seems to be coming down to a choice
>between Silos III and ModelSim with Fintronics on the outside [don't know
>enough about  it yet]. It seems that my $5K budget was a bit optimistic and
>the sim. will probably come in about $7K. Still not bad in comparison with
>a couple of  years ago.
>
>Now there's the question of synthesis. Originally I was going to stick with
>the Synopsis Express  (***)I have as part of the Foundation package but I
>do have the possible options of buying a synthesiser from Synplicity or
>Exemplar [Leonardo].  Anybody have any comments on their quality ?
>Particularly when Xilinx FPGAs are the target devices ?
>
>(***) BTW Does anybody know if  a command line i/f has been added to
>Foundation Express for the 1.5 release ?
>
>
>

--
M. Todd Lawson			InterProphet Corp
Member of Technical Staff	1999 S. Bascom Ave Ste 1020
408-371-8245 x102		Campbell, CA 95008
Article: 12287
Subject: Re: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5 (MORE INFO)
From: Edward Moore <edmoore@edmoore.demon.co.uk>
Date: Thu, 8 Oct 1998 00:54:38 +0100
Links: << >>  << T >>  << A >>
I have also seen a degradation using v1.5. The algorithmns must be
different. And then of course there are the new bugs...
-- 
Edward Moore
Article: 12288
Subject: Re: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5
From: Nestor Caouras <nestor@ece.concordia.ca>
Date: Wed, 07 Oct 1998 20:36:01 -0400
Links: << >>  << T >>  << A >>
Thanks for replying once again Andy.

I thought that if the timespec is not met, then the placer would do its
best to obtain an "otpimal" solution and then that would be the maximum
operating frequency.  I did not realize that a timing constraint not met
could cause a possible invalid frequency.  It makes sense though that
since the timespec was not met then the design could not be used anyway.

I believe for the previous versions, FROM:THRU:TO and FROM:TO had the
same priority (it was something like a "bug" that xilinx corrected in
F1.5. PERIOD was the last one.  Maybe this affects placement and
routing.


> 
> >Also, for M1.5 I get this warning after running trace (trce) on the
> >routed design:
> >
> >WARNING:bastw:544 - Clock nets using non-dedicated resources were found
> >in this design. Clock skew on these resources will not be automatically
> >addressed during path analysis. To create a timing report that analyzes
> >clock skew for these paths, run trce with the '-skew' option.
> 
> Maybe you missed something? Schematic design or VHDL?

What I did is use the xc4000 library from Synplify (I don't know what
tool you are using) to instantiate the BUFG and connect it as:

fsa -> BUFG -> clk_net

and use the following constraints to cover all the nets renamed to
clk_net_c or something similar (luckily Synplify only appends characters
to the VHDL net names):

NET fsa* TNM = fsa_grp;
NET clk* TNM = fsa_grp;
TIMESPEC TS01 = PERIOD fsa_grp 25ns;

I think I may need to use the new timing name net constraint as:

NET fsa* TNM_NET = fsa_grp;
NET clk* TNM_NET = fsa_grp;
TIMESPEC TS01 = PERIOD fsa_grp 25ns;

It used to work in the old versions of Foundation and Alliance, but I
get this warning now.  I emailed the Xilinx hotline and I am waiting for
their response regarding this problem.

I will post their answer to this newsgroup.

Thanks for your help.


-- 
Nestor Caouras
nestor@ece.concordia.ca
http://www.ece.concordia.ca/~nestor/addr.html
|-------------------------------------------|
| Dept. of Electrical and Computer Eng.     |
| Concordia University                      |
| 1455 de Maisonneuve Blvd (West)           |
| Montreal, Quebec, Canada H3G 1M8.         |
| Tel: (514)848-8784    Fax: (514)848-2802  |
|-------------------------------------------|
Article: 12289
Subject: Re: Degradation of results from Xilinx F1.3 -> F1.4 -> F1.5
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Wed, 7 Oct 1998 17:50:18 -0700
Links: << >>  << T >>  << A >>
>Thanks for replying once again Andy.


No probs...

>I thought that if the timespec is not met, then the placer would do its
>best to obtain an "otpimal" solution and then that would be the maximum
>operating frequency.  I did not realize that a timing constraint not met
>could cause a possible invalid frequency.  It makes sense though that
>since the timespec was not met then the design could not be used anyway.


I hope that if that's wrong, someone will correct me, but it makes sense.

>I believe for the previous versions, FROM:THRU:TO and FROM:TO had the
>same priority (it was something like a "bug" that xilinx corrected in
>F1.5. PERIOD was the last one.  Maybe this affects placement and
>routing.


Right! PERIOD was fixed in 1.5...but I checked the timing priorities and
what I mentioned before (FROM:THRU:TO having highest priority) seems to be
the way it is now.


>> >WARNING:bastw:544 - Clock nets using non-dedicated resources were found
>> >in this design. Clock skew on these resources will not be automatically
>> >addressed during path analysis. To create a timing report that analyzes
>> >clock skew for these paths, run trce with the '-skew' option.
>>
>> Maybe you missed something? Schematic design or VHDL?
>
>What I did is use the xc4000 library from Synplify (I don't know what
>tool you are using) to instantiate the BUFG and connect it as:
>
>fsa -> BUFG -> clk_net


Is Synplify smart enough to automatically insert clock buffers? FPGA Express
(which I use) does; so does Metamor.

>and use the following constraints to cover all the nets renamed to
>clk_net_c or something similar (luckily Synplify only appends characters
>to the VHDL net names):
>
>NET fsa* TNM = fsa_grp;
>NET clk* TNM = fsa_grp;
>TIMESPEC TS01 = PERIOD fsa_grp 25ns;
>
>I think I may need to use the new timing name net constraint as:
>
>NET fsa* TNM_NET = fsa_grp;
>NET clk* TNM_NET = fsa_grp;
>TIMESPEC TS01 = PERIOD fsa_grp 25ns;


Try it and let us know what happens.

>It used to work in the old versions of Foundation and Alliance, but I
>get this warning now.  I emailed the Xilinx hotline and I am waiting for
>their response regarding this problem.
>
>I will post their answer to this newsgroup.

Thanks - it's always good to know what the Big "X" says!

-andy


Article: 12290
Subject: Re: Altera's reply to request for Max+Plus II under Linux
From: Zoltan Kocsi <root@127.0.0.1>
Date: 08 Oct 1998 11:43:43 +1000
Links: << >>  << T >>  << A >>
timo@novaengr.com (Tim O) writes (HE QUOTES, NOT WRITES):
Good flame bait, anyway.

> 	I have documented your request for a Linux based Max+Plus II.
> We have looked into that option a bit, and the concensus was that
> there was not enough customer interest in Linux to make it a
> worthwhile investment.  However, if more and more customers continue

That's No. 1. standard answer from all of them.

> to request support for that operating system, it will eventually be
> looked at more seriously.  One of the major problems with supporting

That's No. 1. standard closing clause, with high BSV :-)

> Linux is the fact that there is no person or company who is
> responsible for supporting it.  So if we made a version of
> software which would run on Linux and then there was an operating
> system problem----it would be our job to fix that, and we would have

C'mon, man, you could do better than that !

- Linux is known to have bug fixes quicker than any commercial OS,
  even though Linux is quite bug-free compared to some commercial ones.

- Still, AFAIK, you can buy commercial support, if you like.

- You can talk to thousands of programmers, if you care to look. For free.

- Every piece of Linux has a 'send bugreports to bugs@this.teams.address'
  with a usual response time being between a day and a month.
  Note, that response means 'fix' not 'we will look into it in the next 
  revision; please assure that you will recieve the upgrade pack when it
  becomes available by filling the attached form and faxing it, with your 
  credit card details to ...' 
  You see, Linux is more about professional pride than making more money.
  
- How many times have say M$ fixed problems regarding EDA tools crashing 
  and taking the system with them ?

By the way, I seem to remember posts in this newsgroup regarding to bugs
in EDA tools that don't get fixed from one revision to another. I have
also reported bugs, sending the example which made the tool crash and got
a reply 'Yes, that indeed makes it crash.'. Very supportive.
Strange that supposed OS bugs are suddenly a major concern ...
Actually, I have also sent bug reports regarding to EDA tools running 
under Linux and they fixed the bug quickly and without BS. Interesting.

> no Linux experts or designers to talk too.  As far as I know, that

Now this is, pardon me, utter rubbish.

By the way, you have the source, documetation and assumedly some capable 
programmers around, so what is your problem ?

> fact and the lack of customer interest are the only reasons why such a
> version is not available right now.  

Yeah, right.

Actually, with a little knowledge about Linux much more plausible sounding
arguments could have been cranked out. Still, the attempt to create 
arguments at all, even very weak ones is a nice try, quite respectable :-)
In contrast, this is what for example Symplicity wrote to me:

    "We do not have current plans to port our software to Linux. 
     Feel free to check again with us next year."

Compared to this, the Altera one talks to you as if they almost 
considered a Linux user being human :-)

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 12291
Subject: Re: Help Desperately Needed with Altera Microprocessor Design.
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 07 Oct 1998 22:13:57 -0400
Links: << >>  << T >>  << A >>
Gareth Baron wrote:
> 
> I wouldn't have thought so - It's an Altera problem ;-)

Opps. Maybe I should try actually READING the messages next time...  8-O

 
> Philip Freidin wrote in message ...
> >>michael_23@my-dejanews.com wrote:
> >>>
> >>> Hi all,
> >>>         I desperately need some help. I am doing my final year
> engineering
> >>> project where I am designing a 16 bit Microprocessor. I am using the
> student
> >>> version of Altera for this project, which gives me the EPF10K20RC240-4
> device.
> >>
> >>...snip...
> >
> >In article <361BC6C9.333CF669@yahoo.com> Rickman <spamgoeshere4@yahoo.com>
> writes:
> >> snip
> >>Or you can call Xilinx support at 800-624-4782. They may want you to
> >>send them your design files to solve this.
> >
> >While Xilinx Tech support is well known for being helpfull, This problem
> >is not likely to be something they can solve. :-)
> >
> >Philip
> >

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 12292
Subject: Re: Help Desperately Needed with Altera Microprocessor Design.
From: c9316048@cs.newcastle.edu.au (HALL Daniel)
Date: 8 Oct 1998 03:10:01 GMT
Links: << >>  << T >>  << A >>
Rickman (spamgoeshere4@yahoo.com) wrote:
: michael_23@my-dejanews.com wrote:
: > 
: > Hi all,
: >         I desperately need some help. I am doing my final year engineering
: > project where I am designing a 16 bit Microprocessor. I am using the student
: > version of Altera for this project, which gives me the EPF10K20RC240-4 device.
: > I have completed my design and I have been testing it as I go, so I know all
: > the components are working properly. Here is my problem, and it is a big
: > problem as the deadline is coming up very close and I am starting to panic.
: > I was going along fine until I hit this problem. Okay, so when I was at my
: > last step (I'm so close) when I was trying to compile the whole thing I got
: > the following error about half-way through compilation:
: > "Internal Error: (CMP) Fatal application error in Partitioner at 10%"
: > 
: > Does anyone know what this means and what has caused it?
: 
: ...snip...
:  
: > PPS: Another thought, I wonder if there is a limit of the number of memory
: > elements I can use. It will let me use 3 RAM elements, but as soon as I use
: > a 4th (even if it is only 4 bits), it comes up with that error again. I have
: > a very strong suspicion this could be what's causing the problem. Can anyone
: > confirm this?
: > 
: > -----------== Posted via Deja News, The Discussion Network ==----------
: > http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
: 
: My suspicion is that you have found an internal error in the tools. Any
: time you get a "Fatal Error" that is a good sign that you have not done
: anything wrong. You have likely just done something that the tools don't
: like. 
: 
: You sound like you have a good indicator in the number of RAM blocks.
: There should be no limitation on that. I suggest that you try making
: changes to your design just to find what will and won't crash the tool.
: Or you can call Xilinx support at 800-624-4782. They may want you to
: send them your design files to solve this.
: 
: 
: -- 
: 
: Rick Collins
: 
: redsp@XYusa.net
: 
: remove the XY to email me.

	From my understanding of the student edition of MAX-PLUS, when
you try and partition a design over multiple devices,
either intentionally or because the device
chosen is too small, the paritioner crashes, I guess so that you don't
just buy a heap of smaller parts and use the free student edition. Why it
doesn't give you a warning message, I don't know. Occasionally, MAX-PLUS also
crashes for strange reasons, like when IO packing is turned on, so try 
altering your comile options.

Dan.

Article: 12293
Subject: Re: Design security again - the Actel solution
From: Tom Kean <tom@algotronix.com>
Date: Thu, 08 Oct 1998 04:53:47 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------5A75399BC3BDBDA82E7635E7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Daniel K Elftmann wrote:

> Some actual number of antifuses for the Actel devices are as follows:
> Arch     Fuses    Cost@$500
> A1010 -> 112,000  $56,000,000
> A1020 -> 186,000  $93,000,000
> A1225 -> 250,000 $125,000,000
> A1240 -> 400,000 $200,000,000
> A1280 -> 750,000 $375,000,000
>
> Still not prices that the typical hacker can afford in my opinion.
>

> >
>
> Perhaps a study of the antifuse programming algorithms (which I won't go into here) would help you
> to understand this, but in short the state of each individual antifuse cannot be determined even
> from the programming circuitry once the entire device has been programmed, so take out your camera
> again.   As it has been explained to me, each fuse is verified after it is programmed, but
> programming of subsequent fuses removes the capability to access inner device fuses, which is the
> reason the checksum is programmed into the device for later identification versus just reading out
> the state of each fuse and re-calculating the checksum.
>

OK!  So its a bit harder than I thought :-)  But there is still no way its a $375,000,000 problem.

Firstly,  I have more tools in my toolbox than FIB machines and TEM's, I could use a voltage contrast
microscope to see which top metal wires had signal changes on them while running the circuit for
example.

Secondly, as a smart hacker I'd write some software to help my search.  Most of the possible
permutations
of antifuses will be illegal so once I know the state of a few antifuses connected to a particular
signal the
chances are I can infer the state of many more.

Thirdly I would not give up so quickly on using the programming circuitry to help me.  I'd want to
drive
it in various ways and look at IDD.  I'd want to try driving it while the circuit was running to see
if I could
induce faults and so on.  I'd need to look in some detail at how the circuitry 'removes the
capability', to see
if it was really 'removed' or just made more difficult.


> Tom,
>
> I don't see how antifuse devices have any application in reconfigurable computing?  Is there still
> a bit of Xilinx left in you that just can't have an antifuse advantage being posted in this group?
>
> Don't mean to be smug.   I'm just trying to understand your biases.
>

I hope I'm not biased, I just hate having crazy numbers being thrown about.  I agree that when used in
the'normal' mode i.e. being loaded from a serial eprom SRAM FPGA's are less secure than antifuse.
This
is an antifuse advantage, no question.

However: there is no way that it takes $375,000,000 to figure out the design in an antifuse part and
$500
to figure out the design in an SRAM part.  My guesstimate would be about $50,000 to $500,000 to figure

out how to break the security on the antifuse chips and then about $1 to $5000 per design.


> Good luck to Algotronix, I wish you well.

Thanks.


--------------5A75399BC3BDBDA82E7635E7
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom Kean
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Tom Kean
n:              Kean;Tom
org:            Algotronix Ltd.
adr:            P.O. Box 23116;;;Edinburgh;;EH8 8YB;Scotland
email;internet: tom@algotronix.com
title:          Director
tel;work:       UK +44 131 556 9242
tel;fax:        UK +44 131 556 9247
note:           Web Site: www.algotronix.com
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------5A75399BC3BDBDA82E7635E7--

Article: 12294
Subject: Re: Synthesis: Exemplar or Synopsys
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Thu, 08 Oct 1998 04:50:37 GMT
Links: << >>  << T >>  << A >>
On Wed, 07 Oct 1998 11:31:23 -0700, Derek Palmer <derekp@synopsys.com>
wrote:
>Let's make rumor fact!
>FPGA Express 3.0 will have VHDL 93 support.
>Available on the Synopsys web site at the end of Oct.

What does "support" mean?  How big (or small) will the subset be?
Will it be 1076.6 compliant?

I got a rude suprise once when trying to port some code from Galileo
to FPGA Express.  Couldn't convince the Synopsys tools to believe that
a two dimensional array of std_logic was a valid type for a generic
parameter.

Sigh,
Allan.

>Derek Palmer
>FPGA Express Team
>Synopsys Corporation.
Article: 12295
Subject: Re: FIR Filter Design
From: "Kartheepan, Madasamy" <kartheepan@t-three.com>
Date: Wed, 07 Oct 1998 23:25:45 -0700
Links: << >>  << T >>  << A >>
> At audio and telephony rates, you can take advantage of bit serial
> algorithms for you processing.  This greatly compresses the amount of logic
> required to perform a particular function.  There is no need to construct a
> fully parallel filter (for example) that is capable of 50MHz sample rates
> if you are passing 50KHz data.  By using bit serial forms, you don't waste
> gates on excess processing power you don't need.  If you are unfamiliar
> with bit serial arithmetic, there are two papers on my website that deal
> with it:  The first is an FIR filter implemented in '91 in an ATmel 6K
> part.  This filter does not use distributed arithmetic (the atmel part does
> not implement tables easily), but does show how bit serial arithmetic is
> used to pack a large number of multipliers in a single part.  The second
> paper is one that discusses bit serial design techniques for FPGAs.  It
> uses a bit serial CORDIC vector magnitude computer as an example.
>

Thank you for the last two informative emails. I definitely understand the need
to have a different design philosophy when tackling hardware implementations of
signal processing functions.A little off topic, I want to bounce this off you.
I have been thinking of  putting  Viterbi algorithm for finding MLS onto an
FPGA. Have you come across similar implementations and what is your take on the
feasibility of putting the algorithm handling 32 states (5 memory elements) on
a 100K FPGA?. I would appreciate any input from you,

Thank you,
Kartheepan, M

Article: 12296
Subject: Re: FIR Filter Design
From: "Kartheepan, Madasamy" <kartheepan@t-three.com>
Date: Wed, 07 Oct 1998 23:27:03 -0700
Links: << >>  << T >>  << A >>
> At audio and telephony rates, you can take advantage of bit serial
> algorithms for you processing.  This greatly compresses the amount of logic
> required to perform a particular function.  There is no need to construct a
> fully parallel filter (for example) that is capable of 50MHz sample rates
> if you are passing 50KHz data.  By using bit serial forms, you don't waste
> gates on excess processing power you don't need.  If you are unfamiliar
> with bit serial arithmetic, there are two papers on my website that deal
> with it:  The first is an FIR filter implemented in '91 in an ATmel 6K
> part.  This filter does not use distributed arithmetic (the atmel part does
> not implement tables easily), but does show how bit serial arithmetic is
> used to pack a large number of multipliers in a single part.  The second
> paper is one that discusses bit serial design techniques for FPGAs.  It
> uses a bit serial CORDIC vector magnitude computer as an example.
>

Thank you for the last two informative emails. I definitely understand the need
to have a different design philosophy when tackling hardware implementations of
signal processing functions.A little off topic, I want to bounce this off you.
I have been thinking of  putting  Viterbi algorithm for finding MLS onto an
FPGA. Have you come across similar implementations and what is your take on the
feasibility of putting the algorithm handling 32 states (5 memory elements) on
a 100K FPGA?. I would appreciate any input from you,

Thank you,
Kartheepan, M

Article: 12297
Subject: Re: Help Desperately Needed with Altera Microprocessor Design.
From: James Kellar <james.kellar@nospamplease.quantel.com>
Date: Thu, 08 Oct 1998 11:44:39 +0100
Links: << >>  << T >>  << A >>
sometimes Maxplus does throw funnies like this

the best thing is usually to delete everything in your working
directory, other than the files that you actually need. So you should
hang onto any TDFs, GDFs, SCFs and the ACF. This is assuming that you're
using AHDL.

That will often do the trick.

Make sure you've got the partitioner turned off, if that seems to be
what's crashing.

good luck

James
Article: 12298
Subject: Re: Catching state machine errors (was: A Johnson counter)
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Thu, 08 Oct 1998 11:45:12 +0100
Links: << >>  << T >>  << A >>
David R Brooks wrote:
[snip]
>  Some time ago, I did a system for automatically opening bottom-dump
> doors on 100-ton bulk rail wagons. The railroad were (very properly)
> much concerned to ensure the thing wouldn't dump inadvertently, with
> the train running at speed. The system was partly in firmware (with a
> standard watchdog arrangement), partly in an ASIC. Besides the actual
> output-circuit switches, there was a "safety catch" comprising a FET
> switch in the output-power line, whose gate was driven by a resonant
> L-C circuit feeding a diode. The L-C being AC coupled to a CPU output
> port.
>  The software had to generate a run of several pulses (at the correct
> frequency) before the diode would pump up the FET gate. The
> time-constant of the L-C/FET being longer than that of the watchdog.
> Worked well.

Interesting - I had to do something very similar to guarantee that
a micro-based gadget would completely disconnect itself from a 
bunch of serial ports if it failed for any reason.  Again, a 
simple and successful solution.

Jonathan Bromley 
--
Article: 12299
Subject: Re: Synthesis: Exemplar or Synopsys
From: ems@nospam.riverside-machines.com
Date: Thu, 08 Oct 1998 11:38:03 GMT
Links: << >>  << T >>  << A >>
On Wed, 07 Oct 1998 11:31:23 -0700, Derek Palmer <derekp@synopsys.com>
wrote:

>Let's make rumor fact!
>FPGA Express 3.0 will have VHDL 93 support.
>Available on the Synopsys web site at the end of Oct.

great news, and nice to see synopsys here. however, the last
i heard from xilinx was that it would support "some" '93
features; they weren't specific. can you tell us more? does
this mean (a) a normal synthesisable subset of '93, or
(b) limited support of '93? and what about VSS/DC?

will the new version be shipped with foundation, or will
it be an (expensive) upgrade?

evan



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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search