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 33600

Article: 33600
Subject: Virtex2: Xilinx PCI core mapping error
From: "Doug Wilson" <doug_wilson@3mts.com>
Date: Tue, 31 Jul 2001 11:33:01 -0700
Links: << >>  << T >>  << A >>
Hi, 

I'm migrating a Virtex-E design with the Xilinx PCI core into a Virtex2 device. I'm using the newest Virtex2 PCI core (V.3.0.069) and am running into a mapper problem. The mapper errors out with the following message: 

Release 3.3.08i - Map D.27 Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. Using target part "2v1000bg575-4". Reading NGD file "sib_top.ngd"...
Processing FMAPs... 
Removing unused or disabled logic... 
Running cover... 
ERROR:MapLib:270 - Virtex PCILOGIC macro PCILOGIC symbol "PCI_CORE/PCI_LC/OUT_CE/MAGICBOX" (output signal=PCI_CORE/PCI_LC/OUT_CE/HARD_CE) is an invalid component in Virtex2 architecture. 
Errors found during the mapping phase. Output files will not be written. 

The HARD_CE signal lives in the pci_lc_i.v and .ngo files. 

What is the solution for this? 

Thanks, Doug Wilson

Article: 33601
Subject: Re: finite defect statistics
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 31 Jul 2001 11:33:58 -0700
Links: << >>  << T >>  << A >>
Ouch, Joshua.
You just insulted one of the ikons of this newsgroup.
That's a double no-no:
First, we try to be polite here
Secondly, we all have a tremendous respect for Ray Andraka and don't tolerate
him being insulted.
Go and wash your mouth. With soap...

Peter Alfke


"B. Joshua Rosen" wrote:

> Ray I shouldn't dignify this with a response since you are clearly
> talking about a subject that you know nothing about. However for everyone
> elses benefit I'll give more detail about the nature of the failures that
> we see. We run these tests on approximately 30,000 FPGAs a year. Prior to
> prescreening we were seeing a fall out rate of about 1 in 50. The reports
> that we get back form Xilinx on the screened parts are consistant with
> that number. The nature of the failure is that a bad part will fail 2 or 3
> patterns out of a total of about 150. We can't identify a particular node
> because the tests are designed to give a go/no go answer. However we can
> generally determine which half of the FPGA failed because all of the
> tests are part of a pair, each member testing approximately 50% of the
> CLBs. It's clear that the defects are very small, maybe as small as a
> single gate. Bad parts mostly work, i.e. out of 150 patterns they will
> pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are
> completely syncronous and there are no gated clocks. Parts that fail
> will generally fail at all clock speeds so you can see it's not a timing
> problem. It should be obvious that a design that can't run at 12Mhz on
> one part is unlikely to run at 30Mhz on the remaining 400 parts in the
> system, but of course they do run on the remaining parts because there
> are no timing problems in the designs. The reason that you haven't seen
> these problems is because you aren't looking. We only knew that there was
> a problem because we were getting reports from the field about failures.
> The nature of ASIC emulators makes it's possible to identify the source
> of a problem by shuffling the patterns between different FPGAs. The field
> guys were then able to identify the bad FPGAs. After we realized that
> there was a problem we developed these test patterns. Now field failures
> are much much less frequent, although they aren't zero because our
> coverage isn't 100%.
>
> n article <3B66ABD1.D878B8B7@andraka.com>, "Ray Andraka"
> <ray@andraka.com> wrote:
>
> > Can you give us any more detail as to the exact nature of the failures,
> > and any back up you might have to substantiate it?  Have you pinpointed
> > the failures to specific nodes in a part, and then verified that that
> > node still fails with a different test circuit designed specifically to
> > exercise the 'bad' node?   No trying to be a pain, but I've seen some
> > pretty bad design in very expensive equipment over the years.  Seems
> > that the poorer the design, the more likely the designer is to blame the
> > chip.  There are an awful lot of mediocre designers out there, and they
> > don't just inhabit garages (in fact, on average I'd venture to say that
> > the small shops tend to crank out better designs...they tend to hire the
> > cream of the crop).  The fact that it fails on a chip tester as well as
> > on the board just tells me that there is a problem with design you are
> > putting in the FPGA to test it.  Again, if the failure rates were even a
> > 10th of what you are claiming, I would have expected to see a couple
> > over my career, and would have expected a huge outcry here and in the
> > press.
> >
> > "B. Joshua Rosen" wrote:
> >
> >


Article: 33602
Subject: Re: Schematic user info
From: Kamal Patel <kamal.patel@xilinx.com>
Date: Tue, 31 Jul 2001 12:45:26 -0600
Links: << >>  << T >>  << A >>
Hello Noddy,

That option can be found under "File --> Table Setup".

Best regards,
Kamal Patel

Noddy wrote:

> Sorry, just an administrative question. Could someone please tell me how to
> manually adjust the user info that appears at the bottom right-hand corner
> of a schematic diagram in the Xilinx Foundation software?
>
> Adrian


Article: 33603
Subject: Re: Schematic user info
From: Kamal Patel <kamal.patel@xilinx.com>
Date: Tue, 31 Jul 2001 12:47:11 -0600
Links: << >>  << T >>  << A >>
Whoops,

I guess that should have been addressed to you
Adrian not "Noddy".  My apologies.

-Kamal

Noddy wrote:

> Sorry, just an administrative question. Could someone please tell me how to
> manually adjust the user info that appears at the bottom right-hand corner
> of a schematic diagram in the Xilinx Foundation software?
>
> Adrian


Article: 33604
Subject: Xilinx Spartan XL length count question.
From: kathy_n_brian@hotmail.com (Kathy & Brian)
Date: 31 Jul 2001 11:54:54 -0700
Links: << >>  << T >>  << A >>
I simply want to use the Length Count value within the bitstream to
determine exactly how many bits need to be clocked in to fully program
the device.  I've thoroughly searched this group and Xilinx support
for a clear explanation of the Length Count field, but I have yet to
find a satisfactory explanation on the true meaning of Length Count.

    For an XCS30XL running in Slave Serial mode, BitGen calculates a
Length Count value of 249161.  This value places the "end" of the
bitstream 2 bits beyond the Postamble.  I would expect Length Count to
be either 249159 (number of bits from start to end of Postamble) or
249163 (add 4 bits for Start-Up phase).  What is the purpose of this 2
bit difference?

    There is a support question (Answer Record #7912) that explains
how the Length Count is calculated by BitGen, but it raises even more
questions.  It states that the Length Count value = (PROM size - 7). 
Why subtract 7?  Why derive Length Count from the PROM size at all
(the PROM size includes an unknown quantity of fill bits!)?  The
calculation presented does indeed match my bitstream file contents. 
However, since the Length Count value does not have any useful
relationship to the actual number of configuration bits (due to the
unknown number of fill bits), it cannot be used by a microprocessor to
clock in the correct number of bits!  The only solution that I see is
to add some arbitrary number (7 would probably make the most sense) to
Length Count to ensure that "enough" bits are clocked in.  This seems
like such a hack.

    Does anybody know why Xilinx doesn't simply set Length Count equal
to the exact number of bits necessary to completely program the
device?  Or 4 more (for the Start-Up phase)?  This would seem to make
so much more sense!

Article: 33605
Subject: Re: Virtex2: Xilinx PCI core mapping error
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Tue, 31 Jul 2001 12:02:34 -0700
Links: << >>  << T >>  << A >>

Hi Doug,

You need to make a change to your cfg.v or cfg.vhd file.
Specifically, you need to set bit 251 (towards the end of
the file) to logic one instead of logic zero.

The implementation guide shipped with the product discusses
the implementation of the output datapath clock enables in
the core.  This is in the "Family Specific Considerations"
chapter.

There are two options for the output clock enable, one is
generated by LUTs and the other by the PCILOGIC.  Which one
is used is selected by bit 251 of the configuration file.

In Virtex and Virtex-E, either option is appropriate.  For
high speed operation you will find that the PCILOGIC
is a better choice.  However, there are only two PCILOGICs
per device, one on the left side and one on the right.

For example, if you wanted four cores in a V2000E device,
only two of them could use the PCILOGICs and the other
two would have to use the LUT option...

In Virtex-II, only the LUT option is appropriate because the
same PCILOGIC resource does not exist in this architecture.

Hope this helps,
Eric

Doug Wilson wrote:
> 
> Hi,
> 
> I'm migrating a Virtex-E design with the Xilinx PCI core into
> a Virtex2 device. I'm using the newest Virtex2 PCI core (V.3.0.069)
> and am running into a mapper problem. The mapper errors out with
> the following message:
> 
> Release 3.3.08i - Map D.27 Copyright (c) 1995-2000 Xilinx, Inc.
> Using target part "2v1000bg575-4". Reading NGD file "sib_top.ngd"...
> Processing FMAPs...
> Removing unused or disabled logic...
> Running cover...
> ERROR:MapLib:270 - Virtex PCILOGIC macro PCILOGIC symbol
> "PCI_CORE/PCI_LC/OUT_CE/MAGICBOX" (output signal=PCI_CORE/PCI_LC/OUT_CE/HARD_CE)
> is an invalid component in Virtex2 architecture.
> Errors found during the mapping phase. Output files will not be written.

Article: 33606
Subject: Programming Altera EPC16
From: Michael Mellone <m-mellone@raytheon.com>
Date: Tue, 31 Jul 2001 14:25:14 -0500
Links: << >>  << T >>  << A >>
Hello,
I am having trouble programming an Altera EPC16 via JTAG.  Has anyone
successfully
programmed this part yet?  

Details:
Using Quartus II version 1.0 Service Pack 2
Trying the program the EPC16 using Quartus via a ByteBlasterMV (JTAG
mode)
Using a .pof file generated by Quartus (converted .sof file to .pof)
Part is wired per Figure 11 of the EPC16 datasheet.

Symptoms:  In the programmer, I can Examine and Blank Check the part
correctly,
but when I select Program, the message "Programming failed" is generated
and the
status bar does not move from 0%.

Any help / info would be appreciated.

Thanks,
Mike Mellone
m-mellone@raytheon.com

Article: 33607
Subject: Altera MPLD
From: "Axel Sautter" <AxelSautter@bigfoot.com>
Date: Tue, 31 Jul 2001 21:45:21 +0200
Links: << >>  << T >>  << A >>
Hi all,

does anyone have more detailed information than those available on As
website about their MPLD service? Rumours are welcome as well...

I would like to know something more about this, such as:

- Time schedule for this service
- Price informations
- Minimum ordering quantity
- Will there be conversions from Apex devices or is A waiting for their new
Apex II....?
- Did anyone try this service?
- Is there really no need to provide test vectors (the website says)
- What strategy could be behind this service? What target market A want to
cover with MPLD?
--

Thanks!
cu
Axel





Article: 33608
Subject: Re: RAM - VHDL - Altera,...
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 31 Jul 2001 13:35:34 -0700
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
> 
> A never ending problem! Trying to get RAMs in my design so that there is
> not to much vendor specific code.
> For Altera I'm using Leonardo and Max+plus, for Xilinx WebPack.
> 
> I need a RAM with rgistered rd and wr address and unregistered data (in/out)
> ports.
> One version works:
> Generate a .tdf file with Altera wizard and declare the component in the
> VHDL
> code. But now I have .tdf files. I want only VHDL.
> 

Something like code below should work for leo.
--Mike Treseler

-------------------------------------------------------------------------------
-- Exemplar Infers lpm_ram_dq synchronous ram from this code
-- No exemplar libraries required, generic size
-- M. Treseler 6-13-2001
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity sync_ram is
   generic (width       : natural := 16;
            add_length  : natural := 3
           );

   port ( clk     : in  std_logic;
          data    : in  std_logic_vector(width-1 downto 0);
          address : in  std_logic_vector(add_length-1 downto 0);
          we      : in  std_logic;
          q       : out std_logic_vector(width-1 downto 0)
         );
end sync_ram;

architecture synth of sync_ram is
   constant   mem_size  : natural := 2**add_length;
   type   mem_type is array (mem_size-1 downto 0) of
                          std_logic_vector (width-1 downto 0);
   signal mem           : mem_type;
   signal address_q     : std_logic_vector (add_length-1 downto 0);
begin

   ram_write : process (clk)
      begin
         if clk'event and clk = '1' then
            always_adr_sync : address_q <= address;
            
            maybe_write : if we = '1' then
               mem(to_integer(unsigned(address))) <= data; 
            end if;
      end if;
   end process ram_write;

   always_ram_read:
       q <= mem(to_integer(unsigned(address_q)));         
end architecture synth;

Article: 33609
Subject: Re: finite defect statistics
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Tue, 31 Jul 2001 20:49:35 GMT
Links: << >>  << T >>  << A >>
"B. Joshua Rosen" wrote:
> 
> Ray I shouldn't dignify this with a response since you are clearly
> talking about a subject that you know nothing about. However for everyone
> elses benefit I'll give more detail about the nature of the failures that
> we see. We run these tests on approximately 30,000 FPGAs a year. Prior to
> prescreening we were seeing a fall out rate of about 1 in 50. The reports
> that we get back form Xilinx on the screened parts are consistant with
> that number. The nature of the failure is that a bad part will fail 2 or 3
> patterns out of a total of about 150. We can't identify a particular node
> because the tests are designed to give a go/no go answer. However we can
> generally determine which half of the FPGA failed because all of the
> tests are part of a pair, each member testing approximately 50% of the
> CLBs. It's clear that the defects are very small, maybe as small as a
> single gate. Bad parts mostly work, i.e. out of 150 patterns they will
> pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are
> completely syncronous and there are no gated clocks. Parts that fail
> will generally fail at all clock speeds so you can see it's not a timing
> problem. It should be obvious that a design that can't run at 12Mhz on
> one part is unlikely to run at 30Mhz on the remaining 400 parts in the
> system, but of course they do run on the remaining parts because there
> are no timing problems in the designs. The reason that you haven't seen
> these problems is because you aren't looking. We only knew that there was
> a problem because we were getting reports from the field about failures.
> The nature of ASIC emulators makes it's possible to identify the source
> of a problem by shuffling the patterns between different FPGAs. The field
> guys were then able to identify the bad FPGAs. After we realized that
> there was a problem we developed these test patterns. Now field failures
> are much much less frequent, although they aren't zero because our
> coverage isn't 100%.

Josh,

First, I still think if we saw error counts as high as you describe,
there'd be an uproar.

Second, JUST BECAUSE THE SYSTEM IS DESIGNED TO RUN AT "ONLY" 30 MHZ DOES
NOT MEAN YOU DO NOT HAVE A SIGNAL-INTEGRITY PROBLEM.  Read the Johnson
book.  It's the edge rates that get you, not the clock speed.

Third, to repeat, perhaps you do have a PCB design problem.  If you've
got "lots" of FPGAs talking to each other, I hope you've thought about
chip-to-chip routing, clock-tree distribution (skew between FPGA clocks
will eat your setup time for lunch), all that good stuff.  If you've got
a large board (and sounds like you do), and your clock is distributed
from one corner, you could have problems if you haven't made sure all
clock line lengths are equal.

-andy

Article: 33610
Subject: Re: computer science Vs Computer Enginnering
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 31 Jul 2001 14:03:45 -0700
Links: << >>  << T >>  << A >>
pound_euro@altavista.com (edgar) writes:
> This year, I got my Bachelor in computer science. i wanted to
> undertake a PhD in the fielld of FPGA, but i have been refused even
> that i have my degree with a mark of 65%.
> 
> when i asked the boss there, he told me this is a computer engineering
> department and not computer science, i can't accepet you even if you
> got 90%!!!!
> 
> i have decided to join a software company, but still wondering on what
> he means,

He means that you have to put up with typical bullshit rules that
educational institutions like to use to hassle you.  In this case it
probably means that you have to at least have a minor in EE.  But I'm
just guessing.

If they can't be flexible enough to allow you some alternate way to
qualify, it's not clear that you would want to attend that institution
anyhow.

> what is the differences between computer science and computer
> engineering ?

I'm not sure in terms of formal definitions, but typically CE involves
more EE work.

Article: 33611
Subject: Re: finite defect statistics
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Jul 2001 21:10:54 GMT
Links: << >>  << T >>  << A >>
Not to worry,  I've taken much worse.

I'm trying to be open here, as Joshua has clearly seen some sort of problem (be
it a silicon problem or a design problem).  I'm interested in his input, and
specifically the conditions under which he sees these failures.  I haven't seen
failures to date, and based on his claimed failure levels, the density of my
typical designs, and the number of designs in the field,  I would expect to have
seen at least a few.  I am sure some defects do get out the door, but based on my
experience, I suspect the frequency of occurence is nowhere near as high as he
asserts.

Perhaps he is using a  feature in the FPGA I don't use much (like tbufs for
example), or perhaps he is causing the errors with his method...for example a
column containing an SRL16 and CLB RAM cannot be read back while the chip is
being clocked even if the WE for that element is low because of a silicon bug
that can cause a the configuration to be locally corrupted (this isn't well
documented, but it is a problem we've encountered during radiation testing and
that has been confirmed by xilinx).  Maybe he is using the DLL for both 1x and 2x
clocks and transferring the data between the domains on the same aligned edge
(data book says that's OK, but we've seen problems where unequal loading of the
clock trees has introduced enough skew to make a direct transfer between the
clock0 and clk2x domains unreliable--and that does not change with clock
frequency but will work in some parts and not in others and will work at some
locations but not others on the chip).  Since he is unwilling to share his test
method and does not know the details of the failure mode, we can't evaluate the
basis of his claim and we can't learn from his experience.

It would be nice if he could be more specific as to the exact nature of the
problem so that others can benefit from his experience.  Unfortunately, it
appears that he does not have enough curiousity, know-how and/or expertise to
narrow down the specific failure(s) once they were discovered.  It may be tedious
work, but the end result is usually very beneficial for a) providing constructive
feedback to the manufacturer and b) learning what to avoid in your designs to
avoid the failure even if the parts are defective.   Yelling to the world "these
parts really bite" without some back up or at least some specifics serves no
purpose whatsoever, and in fact can have a very poisoning effect.

Peter Alfke wrote:

> Ouch, Joshua.
> You just insulted one of the ikons of this newsgroup.
> That's a double no-no:
> First, we try to be polite here
> Secondly, we all have a tremendous respect for Ray Andraka and don't tolerate
> him being insulted.
> Go and wash your mouth. With soap...
>
> Peter Alfke
>
> "B. Joshua Rosen" wrote:
>
> > Ray I shouldn't dignify this with a response since you are clearly
> > talking about a subject that you know nothing about. However for everyone
> > elses benefit I'll give more detail about the nature of the failures that
> > we see. We run these tests on approximately 30,000 FPGAs a year. Prior to
> > prescreening we were seeing a fall out rate of about 1 in 50. The reports
> > that we get back form Xilinx on the screened parts are consistant with
> > that number. The nature of the failure is that a bad part will fail 2 or 3
> > patterns out of a total of about 150. We can't identify a particular node
> > because the tests are designed to give a go/no go answer. However we can
> > generally determine which half of the FPGA failed because all of the
> > tests are part of a pair, each member testing approximately 50% of the
> > CLBs. It's clear that the defects are very small, maybe as small as a
> > single gate. Bad parts mostly work, i.e. out of 150 patterns they will
> > pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are
> > completely syncronous and there are no gated clocks. Parts that fail
> > will generally fail at all clock speeds so you can see it's not a timing
> > problem. It should be obvious that a design that can't run at 12Mhz on
> > one part is unlikely to run at 30Mhz on the remaining 400 parts in the
> > system, but of course they do run on the remaining parts because there
> > are no timing problems in the designs. The reason that you haven't seen
> > these problems is because you aren't looking. We only knew that there was
> > a problem because we were getting reports from the field about failures.
> > The nature of ASIC emulators makes it's possible to identify the source
> > of a problem by shuffling the patterns between different FPGAs. The field
> > guys were then able to identify the bad FPGAs. After we realized that
> > there was a problem we developed these test patterns. Now field failures
> > are much much less frequent, although they aren't zero because our
> > coverage isn't 100%.
> >
> > n article <3B66ABD1.D878B8B7@andraka.com>, "Ray Andraka"
> > <ray@andraka.com> wrote:
> >
> > > Can you give us any more detail as to the exact nature of the failures,
> > > and any back up you might have to substantiate it?  Have you pinpointed
> > > the failures to specific nodes in a part, and then verified that that
> > > node still fails with a different test circuit designed specifically to
> > > exercise the 'bad' node?   No trying to be a pain, but I've seen some
> > > pretty bad design in very expensive equipment over the years.  Seems
> > > that the poorer the design, the more likely the designer is to blame the
> > > chip.  There are an awful lot of mediocre designers out there, and they
> > > don't just inhabit garages (in fact, on average I'd venture to say that
> > > the small shops tend to crank out better designs...they tend to hire the
> > > cream of the crop).  The fact that it fails on a chip tester as well as
> > > on the board just tells me that there is a problem with design you are
> > > putting in the FPGA to test it.  Again, if the failure rates were even a
> > > 10th of what you are claiming, I would have expected to see a couple
> > > over my career, and would have expected a huge outcry here and in the
> > > press.
> > >
> > > "B. Joshua Rosen" wrote:
> > >
> > >

--
-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: 33612
Subject: Re: computer science Vs Computer Enginnering
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 31 Jul 2001 22:17:13 +0100
Links: << >>  << T >>  << A >>


edgar wrote:

> heya,
>
> This year, I got my Bachelor in computer science. i wanted to
> undertake a PhD in the fielld of FPGA, but i have been refused even
> that i have my degree with a mark of 65%.
>
> when i asked the boss there, he told me this is a computer engineering
> department and not computer science, i can't accepet you even if you
> got 90%!!!!
>
> i have decided to join a software company, but still wondering on what
> he means,
> what is the differences between computer science and computer
> engineering ?
>
> Edgar S

Computer science = a discipline invented in the 1970s to provide work for
otherwise unemployable academics (and they came up with Lisp ?).

Computer engineering = making real, physical,computers work well enough
that people will pay good money for them.




Article: 33613
Subject: Re: computer science Vs Computer Enginnering
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Jul 2001 21:19:11 GMT
Links: << >>  << T >>  << A >>
Computer engineering, is usually a digital hardware degree, where computer
science is software.  FPGAs require digital hardware design skills, which
is not what is taught under a computer science degree.  You've probably
got alot of ground to cover in undergrad level courses before you are
ready to pursue a doctorate in what is essentially a specific field of
digital design.  A grade of 65% is a 'D' here in the states, which is to
say a rather poor showing.  Even if you had the right background, your
grades may not be high enough to be accepted.

edgar wrote:

> heya,
>
> This year, I got my Bachelor in computer science. i wanted to
> undertake a PhD in the fielld of FPGA, but i have been refused even
> that i have my degree with a mark of 65%.
>
> when i asked the boss there, he told me this is a computer engineering
> department and not computer science, i can't accepet you even if you
> got 90%!!!!
>
> i have decided to join a software company, but still wondering on what
> he means,
> what is the differences between computer science and computer
> engineering ?
>
> Edgar S

--
-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: 33614
Subject: Re: finite defect statistics
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 01 Aug 2001 10:13:05 +1200
Links: << >>  << T >>  << A >>
<ray@andraka.com> wrote:
> >  No trying to be a pain, but I've seen some
> > pretty bad design in very expensive equipment over the years.
B. Joshua Rosen wrote:
> 
> Ray I shouldn't dignify this with a response since you are clearly
> talking about a subject that you know nothing about.
 
 Whoa guys, settle down..!

 The subject is very interesting, don't fall into the 'shoot the
messenger' 
trap.

 This type of problem will be often missed, or taken as something else.

 IIRC, Josh did say he fed the info back to Xilinx, and it seems 
they have changed/improved their testing coverage as a result.
 That's both significant, and a step forward.

 Test coverage is a time/cost tradeoff, but there are interesting points
that come from using a finite defect device.
 eg it means a field upgrade needs care, and may not work 100.0% of the
time.
( if the thing is in orbit, that's something of a problem :)
 
 It also suggests that a single Eval/development PCB is not a good idea, 
unless that FPGA has had the extra cost screening, or perhaps the
designer
is experienced enough to 'know' when it's a HW problem, not a SW one :-)

 Reminds me of a story I heard about Russian Microcontrollers - they
were
pushing the yield/fab envelope and every chip came with it's own 
'functional opcode' list. Code written for that device, had to avoid the
broken opcodes :-)
 This was many years before the 'errata' became more common practice. 
 
-jg

B. Joshua Rosen wrote:
> I'll give more detail about the nature of the failures that
> we see. We run these tests on approximately 30,000 FPGAs a year. Prior to
> prescreening we were seeing a fall out rate of about 1 in 50. The reports
> that we get back form Xilinx on the screened parts are consistant with
> that number. The nature of the failure is that a bad part will fail 2 or 3
> patterns out of a total of about 150. We can't identify a particular node
> because the tests are designed to give a go/no go answer. However we can
> generally determine which half of the FPGA failed because all of the
> tests are part of a pair, each member testing approximately 50% of the
> CLBs. It's clear that the defects are very small, maybe as small as a
> single gate. Bad parts mostly work, i.e. out of 150 patterns they will
> pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are
> completely syncronous and there are no gated clocks. Parts that fail
> will generally fail at all clock speeds so you can see it's not a timing
> problem. It should be obvious that a design that can't run at 12Mhz on
> one part is unlikely to run at 30Mhz on the remaining 400 parts in the
> system, but of course they do run on the remaining parts because there
> are no timing problems in the designs. The reason that you haven't seen
> these problems is because you aren't looking. We only knew that there was
> a problem because we were getting reports from the field about failures.
> The nature of ASIC emulators makes it's possible to identify the source
> of a problem by shuffling the patterns between different FPGAs. The field
> guys were then able to identify the bad FPGAs. After we realized that
> there was a problem we developed these test patterns. Now field failures
> are much much less frequent, although they aren't zero because our
> coverage isn't 100%.

Article: 33615
Subject: Re: Xilinx/Altera "behavioral" verilog
From: Paul Smart <pablo*@*maine.rr.com>
Date: Tue, 31 Jul 2001 22:46:55 GMT
Links: << >>  << T >>  << A >>
Hi Ray,

In principle, I agree with much of what you have said.


On Tue, 31 Jul 2001 01:47:49 GMT, Ray Andraka <ray@andraka.com> wrote:

>
>It is behavioral in the sense that you can't go back and run that vhdl
>through the tools to regenerate the design (wrong library).  It doesn't
>map directly back into the unisim primitives.
>
>
Is there any way to take a modified verilog simulation file and put it
back through to create a modified design?

>
>If you have timing errors in the placed and routed design, the static
>timing analyzer will find them, provided you have sufficiently constrained
>the design.  Places to look out for: multiple or gated clocks, crossing
>clock domains, clock skew introduced by not using clock nets, set-up and
>hold (offsets) to I/o pins.  If the analyzer shows timing errors, it may
>work in the lab, but I'll guarantee that if you make enough of them you'll
>see some of them back from the customer (unless it is a path that you've
>determined is not a problem, of course)
>
I agree that much of the problem is with the designers at my customer.
I cannot say for sure if all of the tools at their disposal are being
correctly used.

>
>Sounds like you have a design problem you haven't properly diagnosed.  I'd
>check very carefully that a) your static timing analysis has full coverage
>of the design, b) you don't have any timing failures, c) you aren't having
>a problem with crossing clock domain boundaries improperly, d) your input
>clocks are clean, e) you've distributed clocks on the clock networks, not
>on general routing (your aren't gateing clocks, right?), f) your power
>supplies are solid and properly bypassed, etc.   Also, make sure you are
>using the latest timing files for your timing analysis.  Refinements in
>the characterization have required adjustments to the timing parameters(in
>both directions).
>
>Again, across literally hundreds of designs, I have yet to see a failure
>caused by a device defect that was not a result of abusing the part
>(overstressing temp or voltage)  or a silicon bug (in which case the error
>is the same on every device).

Some defects  (such as gate oxide defects) are almost never the same
on any given device. There are statistically some amount of random
material defects in all processed semiconductor devices. As the die
size increases, the chance of having a defect on a given die
increases.

>
>Could you tell us which devices you have experienced these problems with?
>Have you isolated the problems to particular structures in the FPGA?  I
>suspect not, rather I am guessing you fail a board, then run a homespun
>test that also fails so you assume the chip is bad.  Is there any way you
>can post the details of your testing so that others can substantiate or
>refute your claims?  Have the manufacturers of the chips involved had a
>chance to review your test setup and results?  If so what are their
>comments?
>

They have FAE from each manufacturer on site more days than not, and
they have a weekly meeting with both manufacturers. They are a fairly
large company, using easily over 200k units per month of FPGAs (EP10K,
EP20K, XC4000XLA,  Virtex, and VirtexE)

The manufacturers have correlated some of the failures. Others have
been traced to software problems, others not correlated. They are
using plenty of good tools for board analysis (such as ASSET).

Again I agree with what you are saying,  and that this company is
probably causing a high level of their own pain.

Article: 33616
Subject: Re: multi-context FPGA
From: sknapp@triscend.com (Steven K. Knapp)
Date: 31 Jul 2001 16:38:30 -0700
Links: << >>  << T >>  << A >>
Though it is _not_ your typical FPGA, Chameleon Systems
(www.chameleonsystems.com) offers a re-programmable device called a
Reconfigurable Communications Processor (RCP) with two configuration
planes.  It looks like it's targeted at compute-heavy applications.

I'm going by memory on this but there is a fairly detialed product
brief at http://www.chameleonsystems.com/what/RCP_Product_Brief.pdf.

Swapping contexts happens in a single clock, though they don't say how
much instantaneous power this consumes.

One additional feature that the Chameleon devices offer is dynamic
interconnect.  The routing to a specific logic function can be changed
on a clock-by-clock basis.



hartenst@rhrk.uni-kl.de (Reiner Hartenstein) wrote in message news:<a5a7222d.0107300945.151ab8d2@posting.google.com>...
> Hi, colleague,
> 
> are there multi context FPGAs on the market
> having 2 or 4 banks of configuration memory ?
> 
> Reiner

Article: 33617
Subject: Re: finite defect statistics
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 31 Jul 2001 19:56:19 -0400
Links: << >>  << T >>  << A >>
Thanks Jim. 

To try and clarify things a little more. Most of the test patterns don't
use any IO at all aside from a serial scan chain. These patterns are run
both on boards and on chip testers. Also the boards involved have changed
over the years. I have been doing these same style tests on five
different generations of these products which have involved three
completely different board designs and five different FPGAs. I'm also not
accusing Xilinx of producing a "bad" product. The defects are very tiny,
that's why it takes 150 different test patterns to find them. Generally a
"bad" part will fail only one or two patterns out of the 150. Also these
patterns use significantly more resources then the average design. The
design goal is to use as much of the chip as possible in each test
pattern. In case you are wondering how much of a Xilinx chip it is
possible to use in one design, my worst case patterns use about 6% of the
PIPs which is the highest number that the Xilinx test people have seen.
For a regular design, i.e. something that was not designed to use the maximum
number of PIPs, the number is probably closer to 1 or 2%. The utilization
number that is reported by the Xilinx place and route tools is for things
like CLBs and flip flops, not for interconnect. As you are all probably
aware an FPGA is almost entirely interconnect, very little of it is
actually usable logic. Thus a "90%" utilized part may be using only 2% of
the resources. That's why it's possible for a part to have a bad
pass gate on it and for most users to never see it. One more thing is
that Xilinx does test these parts, and they do a pretty good job of
covering the most commonly used resources, so the chance that a particular
design will actually use the bad gate may be less than the 1%-2% that the
PIP utilization would suggest. 

With that said the issue of field upgrades should be addressed. For most
FPGA systems field upgrades are either impossible or are very infrequent.
The application that I wrote these tests for was ASIC emulation where new
patterns are being downloaded several times a day. For emulators a bad
FPGA will make itself know in a fairly short time. For a board with one
or two FPGAs that gets upgraded once in it's lifetime the chance that any
particular board will fail after the upgrade may be as low as one in
10,000. For applications where upgrades are frequent the cost of doing
the extra testing is well worth it, for applications where upgrades
are rare the extra cost would outweigh the advantages.
 

In article <3B672D71.78D0@designtools.co.nz>, "Jim Granville"
<jim.granville@designtools.co.nz> wrote:

> <ray@andraka.com> wrote:
>> >  No trying to be a pain, but I've seen some
>> > pretty bad design in very expensive equipment over the years.
> B. Joshua Rosen wrote:
>> 
>> Ray I shouldn't dignify this with a response since you are clearly
>> talking about a subject that you know nothing about.
>  
>  Whoa guys, settle down..!
> 
>  The subject is very interesting, don't fall into the 'shoot the
> messenger'
> trap.
> 
>  This type of problem will be often missed, or taken as something else.
> 
>  IIRC, Josh did say he fed the info back to Xilinx, and it seems
> they have changed/improved their testing coverage as a result.
>  That's both significant, and a step forward.
> 
>  Test coverage is a time/cost tradeoff, but there are interesting points
> that come from using a finite defect device.
>  eg it means a field upgrade needs care, and may not work 100.0% of the
> time.
> ( if the thing is in orbit, that's something of a problem :)
>  
>  It also suggests that a single Eval/development PCB is not a good idea,
> unless that FPGA has had the extra cost screening, or perhaps the
> designer
> is experienced enough to 'know' when it's a HW problem, not a SW one :-)
> 
>  Reminds me of a story I heard about Russian Microcontrollers - they
> were
> pushing the yield/fab envelope and every chip came with it's own
> 'functional opcode' list. Code written for that device, had to avoid the
> broken opcodes :-)
>  This was many years before the 'errata' became more common practice.
>  
> -jg
> 
> B. Joshua Rosen wrote:
>> I'll give more detail about the nature of the failures that we see. We
>> run these tests on approximately 30,000 FPGAs a year. Prior to
>> prescreening we were seeing a fall out rate of about 1 in 50. The
>> reports that we get back form Xilinx on the screened parts are
>> consistant with that number. The nature of the failure is that a bad
>> part will fail 2 or 3 patterns out of a total of about 150. We can't
>> identify a particular node because the tests are designed to give a
>> go/no go answer. However we can generally determine which half of the
>> FPGA failed because all of the tests are part of a pair, each member
>> testing approximately 50% of the CLBs. It's clear that the defects are
>> very small, maybe as small as a single gate. Bad parts mostly work,
>> i.e. out of 150 patterns they will pass 147 or 148. The clock speed
>> range is 12Mhz to 30Mhz. The designs are completely syncronous and
>> there are no gated clocks. Parts that fail will generally fail at all
>> clock speeds so you can see it's not a timing problem. It should be
>> obvious that a design that can't run at 12Mhz on one part is unlikely
>> to run at 30Mhz on the remaining 400 parts in the system, but of course
>> they do run on the remaining parts because there are no timing problems
>> in the designs. The reason that you haven't seen these problems is
>> because you aren't looking. We only knew that there was a problem
>> because we were getting reports from the field about failures. The
>> nature of ASIC emulators makes it's possible to identify the source of
>> a problem by shuffling the patterns between different FPGAs. The field
>> guys were then able to identify the bad FPGAs. After we realized that
>> there was a problem we developed these test patterns. Now field
>> failures are much much less frequent, although they aren't zero because
>> our coverage isn't 100%.

Article: 33618
Subject: Re: Spanning the heirarchy
From: Paul Campbell <paul@verifarm.com>
Date: Wed, 01 Aug 2001 00:00:57 +0000
Links: << >>  << T >>  << A >>
Rick Collins wrote:

> I am adding some code to a verilog design for debug and I need to access
> signals in a remote portion of the design. I have been told that there
> is a way to do this in the form of
> "top_level.mid_level.low_level.signal_name" where the level names are
> module instance names. This works ok in simulation, but I can't get it
> to work in synthesis. We are using Synplify. Is this not supported by
> this tool? Is this not supported by any synthesis tool?

hierarchical references are seldom, if ever used for synthesiss - you need 
to bring those wires up and out the hard way I'm afraid.

Verilog hierarchical references are actually relative (even though most 
people use them as absolute references which IMHO is the only close to safe 
way to use them). Because synthesis is often done incrementally from the 
bottom up hierarchical names that are anything other than relatively 
downwards from where they are used are pretty much impossible to synthesize.

The searching rules use by the language to resolve them are not generally 
well understood - and capable of dangerous, silent, changes when other 
somewhat unrelated parts of the hierarchy change.
 
Consider the following example prints "1"

        module a;
                initial #1 $displayb(x.y);
        endmodule

        module x;
                wire y = 1;
                a x();
        endmodule

But the following example prints "0" because the absolute is contextually
converted to a relative one:

        module a;
                wire y = 0;
                initial #1 $displayb(x.y);
        endmodule

        module x;
                wire y = 1;
                a x();
        endmodule

A simple set of rules to avoid evile relative hierarchical names:

        - only use absolute references
        - don't use the name of the top level model (say 'top')
                anywhere else in the design



Article: 33619
Subject: Re: finite defect statistics
From: Ray Andraka <ray@andraka.com>
Date: Wed, 01 Aug 2001 00:39:20 GMT
Links: << >>  << T >>  << A >>
I an see where my comment might have been inflammatory.  It was not intended to
be so.  I was merely making the observation that cost and size of company do not
determine the quality of a design. Knowing nothing about this particular test
suite I can't say whether or not there is a design fault.  My experience causes
me to be very skeptical when someone declares there is a chip problem,
especially when there are claims of very high failure rates. Most of the time it
turns out to be a problem with the design rather than the chip.  If you look at
your posts from an outsider's point of view, I am sure you'd reach the same
conclusion.

If the defects are of the order of magnitude Joshua indicates, there is need to
worry, especially in designs like many of mine where we are taking some
advantage of reconfiguration and depending on having a good device.  I do
realize the that large designs do not necessarily use many pips. In fact, for
high performance designs, I try to minimize the number of pips crossed.  Much of
the routing is purposely to adjacent CLBs, which for the most part misses the
majority of the pips in the chip.  I'm probably using significantly LESS than
the average number of used pips,  so, I'll concede that my designs may not have
hit a bad pip yet. Perhaps I have a lower probability of hitting a defect as a
result.

One thing that puzzles me is Joshua's comment that the error rates have remained
pretty consistent over several generations of product.  I would expect that as
the device density increases and the feature size is decreased that the number
of defects per chip would increase, not stay at some constant level.  The
constant error rate was part of what pointed me in the direction of a clock skew
or signals integrity problem in the first place.



Jim Granville wrote:

> <ray@andraka.com> wrote:
> > >  No trying to be a pain, but I've seen some
> > > pretty bad design in very expensive equipment over the years.
> B. Joshua Rosen wrote:
> >
> > Ray I shouldn't dignify this with a response since you are clearly
> > talking about a subject that you know nothing about.
>
>  Whoa guys, settle down..!
>
>  The subject is very interesting, don't fall into the 'shoot the
> messenger'
> trap.
>
>  This type of problem will be often missed, or taken as something else.
>
>  IIRC, Josh did say he fed the info back to Xilinx, and it seems
> they have changed/improved their testing coverage as a result.
>  That's both significant, and a step forward.
>
>  Test coverage is a time/cost tradeoff, but there are interesting points
> that come from using a finite defect device.
>  eg it means a field upgrade needs care, and may not work 100.0% of the
> time.
> ( if the thing is in orbit, that's something of a problem :)

It also means that you may have a yield fallout in a shipping product.

>
>
>  It also suggests that a single Eval/development PCB is not a good idea,
> unless that FPGA has had the extra cost screening, or perhaps the
> designer
> is experienced enough to 'know' when it's a HW problem, not a SW one :-)
>
>  Reminds me of a story I heard about Russian Microcontrollers - they
> were
> pushing the yield/fab envelope and every chip came with it's own
> 'functional opcode' list. Code written for that device, had to avoid the
> broken opcodes :-)
>  This was many years before the 'errata' became more common practice.
>
> -jg
>
> B. Joshua Rosen wrote:
> > I'll give more detail about the nature of the failures that
> > we see. We run these tests on approximately 30,000 FPGAs a year. Prior to
> > prescreening we were seeing a fall out rate of about 1 in 50. The reports
> > that we get back form Xilinx on the screened parts are consistant with
> > that number. The nature of the failure is that a bad part will fail 2 or 3
> > patterns out of a total of about 150. We can't identify a particular node
> > because the tests are designed to give a go/no go answer. However we can
> > generally determine which half of the FPGA failed because all of the
> > tests are part of a pair, each member testing approximately 50% of the
> > CLBs. It's clear that the defects are very small, maybe as small as a
> > single gate. Bad parts mostly work, i.e. out of 150 patterns they will
> > pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are
> > completely syncronous and there are no gated clocks. Parts that fail
> > will generally fail at all clock speeds so you can see it's not a timing
> > problem. It should be obvious that a design that can't run at 12Mhz on
> > one part is unlikely to run at 30Mhz on the remaining 400 parts in the
> > system, but of course they do run on the remaining parts because there
> > are no timing problems in the designs. The reason that you haven't seen
> > these problems is because you aren't looking. We only knew that there was
> > a problem because we were getting reports from the field about failures.
> > The nature of ASIC emulators makes it's possible to identify the source
> > of a problem by shuffling the patterns between different FPGAs. The field
> > guys were then able to identify the bad FPGAs. After we realized that
> > there was a problem we developed these test patterns. Now field failures
> > are much much less frequent, although they aren't zero because our
> > coverage isn't 100%.

--
-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: 33620
Subject: Re: Xilinx/Altera "behavioral" verilog
From: Ray Andraka <ray@andraka.com>
Date: Wed, 01 Aug 2001 00:58:35 GMT
Links: << >>  << T >>  << A >>


Paul Smart wrote:

> Hi Ray,
>
> In principle, I agree with much of what you have said.
>
> On Tue, 31 Jul 2001 01:47:49 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >
> >It is behavioral in the sense that you can't go back and run that vhdl
> >through the tools to regenerate the design (wrong library).  It doesn't
> >map directly back into the unisim primitives.
> >
> >
> Is there any way to take a modified verilog simulation file and put it
> back through to create a modified design?

not any easy paths that I am aware of.  You can remap the simprims into
unisims, but it is a very painful process.  Probably less work starting on a
fresh design.

>
>
> >
> >If you have timing errors in the placed and routed design, the static
> >timing analyzer will find them, provided you have sufficiently constrained
> >the design.  Places to look out for: multiple or gated clocks, crossing
> >clock domains, clock skew introduced by not using clock nets, set-up and
> >hold (offsets) to I/o pins.  If the analyzer shows timing errors, it may
> >work in the lab, but I'll guarantee that if you make enough of them you'll
> >see some of them back from the customer (unless it is a path that you've
> >determined is not a problem, of course)
> >
> I agree that much of the problem is with the designers at my customer.
> I cannot say for sure if all of the tools at their disposal are being
> correctly used.
>
> >
> >Sounds like you have a design problem you haven't properly diagnosed.  I'd
> >check very carefully that a) your static timing analysis has full coverage
> >of the design, b) you don't have any timing failures, c) you aren't having
> >a problem with crossing clock domain boundaries improperly, d) your input
> >clocks are clean, e) you've distributed clocks on the clock networks, not
> >on general routing (your aren't gateing clocks, right?), f) your power
> >supplies are solid and properly bypassed, etc.   Also, make sure you are
> >using the latest timing files for your timing analysis.  Refinements in
> >the characterization have required adjustments to the timing parameters(in
> >both directions).
> >
> >Again, across literally hundreds of designs, I have yet to see a failure
> >caused by a device defect that was not a result of abusing the part
> >(overstressing temp or voltage)  or a silicon bug (in which case the error
> >is the same on every device).
>
> Some defects  (such as gate oxide defects) are almost never the same
> on any given device. There are statistically some amount of random
> material defects in all processed semiconductor devices. As the die
> size increases, the chance of having a defect on a given die
> increases.

Agreed.  I was referring to designed in problems when I said a silicon
bug...things like the SRL16, or the faulty parallel load configuration state
machine on early XC4025E-2s.  I am sure there are defects out there that passed
thorugh the manufacturer's test.  At issue is the percentage of fielded parts
with silicon defects (not design bugs).  Is there a number anyone can pin on
the rate of substantiated defects?

>
>
> >
> >Could you tell us which devices you have experienced these problems with?
> >Have you isolated the problems to particular structures in the FPGA?  I
> >suspect not, rather I am guessing you fail a board, then run a homespun
> >test that also fails so you assume the chip is bad.  Is there any way you
> >can post the details of your testing so that others can substantiate or
> >refute your claims?  Have the manufacturers of the chips involved had a
> >chance to review your test setup and results?  If so what are their
> >comments?
> >
>
> They have FAE from each manufacturer on site more days than not, and
> they have a weekly meeting with both manufacturers. They are a fairly
> large company, using easily over 200k units per month of FPGAs (EP10K,
> EP20K, XC4000XLA,  Virtex, and VirtexE)
>
> The manufacturers have correlated some of the failures. Others have
> been traced to software problems, others not correlated. They are
> using plenty of good tools for board analysis (such as ASSET).

So the manufacturers are heavily involved then.  That is good.

>
>
> Again I agree with what you are saying,  and that this company is
> probably causing a high level of their own pain.

Thank you. ^^^^


--
-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: 33621
Subject: What way for Xilinx to ASIC migration ?
From: litv@fromru.com (Alexander Litvinov)
Date: 31 Jul 2001 18:51:51 -0700
Links: << >>  << T >>  << A >>
Hi !
I designed Xilinx project - 1000000 gates(Virtex).
I want to convert this project to ASIC.
1.I know that Xilinx have way to automatic convert FPGA to ASIC.
  Who try this method? What about advantages of this method ?
2.Who know information about translation Xilinx EDIF file to 
  ASIC ?  I used AutoLogic for this, but now it was dead.

Thanks
Alexander

Article: 33622
Subject: Re: RAM - VHDL - Altera,...
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Wed, 01 Aug 2001 12:17:52 +1000
Links: << >>  << T >>  << A >>


Mike Treseler wrote:
> 
> Martin Schoeberl wrote:
> >
> > A never ending problem! Trying to get RAMs in my design so that there is
> > not to much vendor specific code.
> > For Altera I'm using Leonardo and Max+plus, for Xilinx WebPack.
> >
> > I need a RAM with rgistered rd and wr address and unregistered data (in/out)
> > ports.
> > One version works:
> > Generate a .tdf file with Altera wizard and declare the component in the
> > VHDL
> > code. But now I have .tdf files. I want only VHDL.
> >
> 
> Something like code below should work for leo.
> --Mike Treseler
> 
> -------------------------------------------------------------------------------
> -- Exemplar Infers lpm_ram_dq synchronous ram from this code

How does leonardo know? Is it just because a large array of words
is declared?


> -- No exemplar libraries required, generic size
> -- M. Treseler 6-13-2001
> -------------------------------------------------------------------------------
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
> 
> entity sync_ram is...

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
/__/   / Victoria, Australia, Down-Under      /__/\/\/
\  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
 \__\/                                         \__\/

Article: 33623
Subject: Re: Programming Altera EPC16
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Wed, 01 Aug 2001 12:27:08 +1000
Links: << >>  << T >>  << A >>
Have you got any neccessary pull-up resistors connected? IIRC, one or
two outputs are open-drain. There's some pdfs at altera saying what
the connections should be.

Michael Mellone wrote:
> 
> Hello,
> I am having trouble programming an Altera EPC16 via JTAG.  Has anyone
> successfully
> programmed this part yet?
> 
> Details:
> Using Quartus II version 1.0 Service Pack 2
> Trying the program the EPC16 using Quartus via a ByteBlasterMV (JTAG
> mode)
> Using a .pof file generated by Quartus (converted .sof file to .pof)
> Part is wired per Figure 11 of the EPC16 datasheet.
> 
> Symptoms:  In the programmer, I can Examine and Blank Check the part
> correctly,
> but when I select Program, the message "Programming failed" is generated
> and the
> status bar does not move from 0%.
> 
> Any help / info would be appreciated.
> 
> Thanks,
> Mike Mellone
> m-mellone@raytheon.com

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
/__/   / Victoria, Australia, Down-Under      /__/\/\/
\  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
 \__\/                                         \__\/

Article: 33624
Subject: Re: Webpack Tutorials
From: Dave Vanden Bout <devb@xess.com>
Date: Wed, 01 Aug 2001 01:12:24 -0400
Links: << >>  << T >>  << A >>
Srinivasan Venkataramanan wrote:

> Hi,
>   Try the one from XESS, kind-of-beginner's guide.
>
> HTH,
> Srini
>
> http://www.xess.com/appnotes/webpack-1_5.pdf

That's very old.  Try the newer one for WebPACK 3.1:

http://www.xess.com/appnotes/webpack-3_1.pdf

Even this one is a bit too old since it only covers CPLDs, but it does
show the design flow.



--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||





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