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

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 57300

Article: 57300
Subject: Re: why so many problems Xilinx ?
From: qlyus@yahoo.com (qlyus)
Date: 27 Jun 2003 00:51:22 -0700
Links: << >>  << T >>  << A >>
Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EFB3967.50BF61F0@xilinx.com>...
> Unfair.
> 
> Since Xilinx is winning 80+% of all new FPGA designs, what else would people be
> talking about on the website?
> 
> Xilinx has a policy of "very open communications" which means just what is
> says.  If there is a bug, we fix it.  If there is a problem, we solve it.
> 

Is Xilinx the only company to fix bug and solve problem?  Sure
Microsoft does too.  All companies do.

> Sweeping something under the rug comes back to only kill you later!
> 
> I have recently noted that Altera, Actel, and others have been using this
> newsgroup.
> 
> That is a good thing.
> 
> But do not weigh the quality of the product by the number of complaints on a
> newsgroup.  The number of complaints results in a very healthy and very high
> quality product as we all read, respond, and act to fix problems, provide
> solutions, and give our customers the best service and value.
> 

Of course the number of complaints means something.  Fixing bugs is
good.  But less bugs to fix is even better.

> Who do you work for, and why did you feel motivated to post this?  Perhaps you
> need to go examine what makes up good business practices?  See below for a
> thread by thread comment.....

I am not working for Altera or any other CPLD/FPGA chip companies.  My
post is a simple question of why we have far more Xilinx software
related posts than altera's.

> Austin
> 
> qlyus wrote:
> 
> > Just took a look of a few pages of comp.arch.fpga Thread Subject:
> >
> > Jun 26, 2003 Xilinx Webpack bugs bugs bugs  (17 articles)
> 
> someone who loves schematics, hates hdl, found a bug.  old subject, but we
> care, so we respond.
> 

Is it a bug?  Old subject?  but still existing!

No Xilinx people responded in this thread by the way.  SO "we respond"
is not accurate!

> >
> > Jun 26, 2003 CoreGen/Ngdbuild help  (2 articles)
> 
> what is wrong with asking for help?
>

I did not say it is wrong.
 
> >
> > Jun 26, 2003 ERROR:iMPACT:583  (4 articles)
> 
> "done" doesn't go high is a pretty generic problem, we spend a lot of time on
> configuration issues and tools because we have to.
> 

Is iMPACT a Xilinx software? 
In other words, does it say "ERROR:Xilinx software"?

I did not ask you what kind of problem is.

> >
> > Jun 26, 2003 Addressable Register core generator  (1 article)
> > Jun 26, 2003 Handelc, Plzzz help  (1 article) P. Prasad
> > Jun 25, 2003 Xilinx ML300 JTAG Configuration Problem  (1 article)
> > Jun 25, 2003 Xilinx XC3430A  (2 articles)
> 
> Confused customer wants info on a product we don't make?
> 

I did not see confused Altera customers post help on a product Altera
does not make.

> >
> > Jun 25, 2003 Webpack 5.2i can't synthesize  (1 article)
> > Jun 24, 2003 applying SCHMITT TRIGGER to CoolRunner-II CPLD's  (2 articles)
> >
> > Xilinx related problems are overwhelming over Altera's.
> >
> > (1) Altera products are better?
> 
> Market will decide.
> 

You did not answer my question.

> >
> > (2) Altera users are smarter?
> 
> Market will decide.
> 

You did not answer my question.

> >
> > (3) Altera tech support ?
> 
> Don't know. Don't use it much.  But we did win the "top 10 best support
> websites" award this month.
> 

Thank, you answered my question.  But the answer is "Don't not know."

Well, Xilinx websites are good.  Answer database is very helpful. 
FAEs are also very good.  But I put big ? on phone support.


> >
> > (3) Very few people use Altera (Altera market share smaller than Xilinx) ?
> 
> Xlinx market share has increased every quarter for the last year
> (DataQuest-Gartner).  Market will decide, not you or I.

But altera says "Altera Tops CPLD Market in 2002".
http://www.altera.com/corporate/news_room/releases/products/nr-cpld_leader.html

Increasing for last year or winning 80+% of new designs is different
from total market pecentage or users.

Atleast Altera has a fair percent of market share.  I think my
question should change to "why altera users do not ask questions in
newsgroup?"

Again, I do not work for Altera.  I am a long time Xilinx user.

-qlyus

Article: 57301
Subject: Re: Xilinx Webpack bugs bugs bugs
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 27 Jun 2003 09:06:07 +0100
Links: << >>  << T >>  << A >>
"Patrick MacGregor" <patrickmacgregor@comcast.net> writes:

> "Martin Thompson" <martin.j.thompson@trw.com> wrote in message
> news:uk7b9z2w8.fsf@trw.com...
> > HDL doesn't force abstration - you can write gate-level HDL.  There
> >are illustrious people populating this group who frequently do the
> >"design equivalent of assembly coding" in HDL.
> 
> HDL by its very nature is abstraction in the same way that C abstracts
> from assembly.  You describe logic and let some piece of software try
> to figure out what it means.
> 

You *can* write 'at the assembly level' in HDL.  In FPGA land, You can
go as far as instantiating LUTs and FFs directly wiring them up.  Is
that assembly enough?

> > Come to think of it, last time I did a schematic I used the
> >"abstraction" of a counter block, which hides flops inside it.  Only
> >if you know how to make a counter do you know "where every flop is".
> >And that's the same in HDL - I know I've written code that will mean
> >a counter gets built, so I know what flops there are there.
> >
> 
> Hierarchies are not abstractions.  Punch down into the counter to see
> the design.  Sadly, these days it will probably be an HDL, so if a
> newbie wants to learn about counter design, it won't help any.
> 

No, it could easily be a architecture-optimised, target-specific, low
(LUT/FF) level description of how to build a counter.  Which could be
described equally well in HDL or schematic.

> I've used numerous counter types to solve different prolbems.  T-FF
> based, Johnson counters, D-FF based.  Each has a place if you know how
> they are built and what their tradeoffs are.
> 

And with a decent library (HDL or schematic) you can have any of
those.  In VHDL you could use a single generic to change the style of
a particular counter very quickly - I'm sure you can do the same in schematic.

<snip>
Debugging: 
> > I go back to my simulation, with its models and all that 'waste of
> >time'.
> >
> > Another advantage of this approach is that I can write a testbench
> >that covers all my (many) testcases and reports a pass or fail at the
> >end.  That way I can modify any code I like and know I haven't
> >recreated any old bugs.  Not quite so easy when staring at
> >waveforms...
> >
> 
> Well, I guess we mean different things when we describe "simulations".
> The Quartus tools allow me to simulate the design without having to
> "model" anything.  I can take the actual design and throw signals at
> it directly to see if it is doing what it should.  If I've built the
> circuit according to the timing diagrams, I should see resultant
> waveforms that match what I expect.  Very simple to follow visually,
> and it has the added benefit that you see a lot more about what is
> going on in the circuit instead of a simple "pass/fail".  BTW, with
> waveforms you can also do pass/fail tests really, really easily and
> automatically.  There is no penalty from using waveforms, but there is
> a lot to gain.  

I'm not opposed to the use of waveforms, just that complex transaction
based systems are easier for a machine to check than for *me* to do by
eye. YMMV.  Describing a complex testbench as a *simple* pass/fail is
misleading also - the testbench will have run the UUT through all of
its functionality, checking that the outputs do the right thing in all
circumstances.  Just like you are doing with the waveforms.

> Also, when you debug the board, you should be able to
> match appropriate I/O signals with ones witnessed in simulation.
> Seeing a blinky light turn on doesn't mean a circuit worked.  You have
> to know how well it is working, and know what the signal integrity is
> along the way.  This usually means o'scopes, which means, you guessed
> it, waveforms.
> 

Indeed - and there's no reason that because you use an HDL and
automated testbench that you don't understand how the system should
look 'in real life'.  I'm quite at home with scope, logic analyser,
printout of simulation waveforms and datasheets - never have enough
bench space!  I just find various other techniques helpful to my
methodology as well.

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 57302
Subject: Re: Xlilin xc9572XL Default register values
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Fri, 27 Jun 2003 20:20:54 +1200
Links: << >>  << T >>  << A >>
"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote
in message news:rvOKa.52693$JA5.936325@news.xtra.co.nz...
> I have a design in VHDL for a xc9572xl done using the web pack software.
>
> I am wanting to know how I can set the startup values of the registers.
>

After some more research it seems that I need to use the 'init' attribute.

But I have had no luck initing a register.

    type v_reg_type is record
        -- registers
        IOLatch     :   std_logic_vector(4 downto 0);
        IOLatch2     :   std_logic_vector(4 downto 0);
    end record;

 signal r, rin : v_reg_type;

I want to do something like

attribute init of signal r.IOLatch  : signal "10101";

(Clearly assuming I am on the right path)

But I have had no luck persuading webpack to compile it.


Thanks for any pointers.
Ralph




Article: 57303
Subject: Partial reconfiguration of Vertex-2 devices.
From: kelvin_xq@hotmail.com (Kelvin Tsai @ Singapore)
Date: 27 Jun 2003 02:20:06 -0700
Links: << >>  << T >>  << A >>
Hi, all: 

In the Vertex-2 datasheet, it mentioned about partial reconfiguration,
where can I find more information on this topic? I have a variable
design and a fixed design to put on same V-2 chip.

Will partial reconfiguration process halt the current operation of the
'fixed' design on the chip?

How can I guarantee the variable design doesn't rob away the hardware
of my fixed design?

Thanks. 
Kelvin

Article: 57304
Subject: Re: Eighty layers of metal!
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 27 Jun 2003 10:43:40 +0100
Links: << >>  << T >>  << A >>
Bernd Paysan <bernd.paysan@gmx.de> writes:

> Robert Myers wrote:
> > Possible solutions: get away from Manhattan
> > routing (25% savings in wire delay--yawn)
> 
> He even said this was "novel". Looking at the 25 years old die of the 8086, 
> 45 angle wiring wasn't novel back then - when layout was made by hand, and 
> digitized afterwards. What's novel is chip place&route tools that can 
> handle 45 angle wiring.
> 

One thing I've never understood is what makes IC P&R different to
PCBs?  PCB autorouters have been doing 45 degree routing for
years... Interested minds want to know.

Cheers!

Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 57305
Subject: Offset and falling edge clocks
From: dnagy@rbni.com (Darrin Nagy)
Date: 27 Jun 2003 02:48:18 -0700
Links: << >>  << T >>  << A >>
How do I define an offset constraint for an input signal that is
referenced to the falling edge of the input clock?

Do I simply add half a clock period?

Eg NET "input_pad"   OFFSET = IN (clk_period - (clk_period/2 +
clk_to_out_fall)) ns BEFORE "clk_pad";

Article: 57306
Subject: multiple asychronous resets
From: "Ruth" <ruthsims@hotmail.com>
Date: Fri, 27 Jun 2003 10:51:44 +0100
Links: << >>  << T >>  << A >>
re-post with subject header!

Hi,

Are there any problems with having more than one asynchronous reset?
(Altera1k50 - datasheet has some info but uncertain as to what it implies).
I assumed that the synthesis tool just added an 'or' gate in front of the
reset on the FF, but I've ben told recently that this is not necessarily the
case and that it can cause problems.  Can anyone shed any light on what
these might be please?

process (reset, clk, o_mreset)
      begin
           if (reset = '1') or (o_mreset = '1') then
                dummy <= '0';
                dummy2 <= '1';
         elsif rising_edge(slow_clk) then
               if control = '1' then
                    dummy <= i_dummy;
                    dummy2 <=  i_dummy2;
            end if;
        end if;
end process;

Thanks

Ruth







Article: 57307
Subject: IP core generation
From: santi@eee.strath.ac.uk (Santi)
Date: 27 Jun 2003 03:07:28 -0700
Links: << >>  << T >>  << A >>
Hi all,

I'm looking for a tutorial/how-to/book/anything in IP core creation
and reuse.
What I'm looking for is something from the tools point of view (Xilinx
preferable, I found their help docs pretty bad).

Any suggestion?

Santi

Article: 57308
Subject: Re: CoreGen/Ngdbuild help
From: santi@eee.strath.ac.uk (Santi)
Date: 27 Jun 2003 03:11:05 -0700
Links: << >>  << T >>  << A >>
Stephane Guyetant <sguyetan.dislikes.spam@IRISA.fr> wrote in message news:<bdf0b9$2hf$1@news.irisa.fr>...
> I had this error while implementing RAMs with BlockRAMs:
> the blockram is a componant instanciated within the coregen-generated 
> component which in my case was wrong (dualport vs single port).
> I would suggest:
> * make sure your library is compiled before your design.
> * check the PORT MAP of the components
> 
> VHDL is case unsensitive. IIRC Verilog is case sensitive.
> 
> 
Finally I found the problem.

It was that the name of the IP and the name of the container files
(edf/ngo) it didn't match.

Thanks.

Santi

Article: 57309
Subject: Re: Eighty layers of metal!
From: Chris Torek <nospam@elf.eng.bsdi.com>
Date: 27 Jun 2003 04:18:53 -0600
Links: << >>  << T >>  << A >>
In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
>Won't happen of course.  Possible solutions: get away from Manhattan
>routing (25% savings in wire delay--yawn), copper interconnect (been
>done of course, discovered from the same article that copper atoms
>like to diffuse into silicon, maybe it's just as well that chips
>become obsolete every few years) ...

It is, apparently, common knowledge that copper is doom, in terms
of silicon.  So I asked my chip-process-engineer brother how Intel
and IBM can be investigating the use of copper.  My digest of his
answer is that the "copper equals doom" theory appears to be bunk.
It certainly has some ways to go wrong, but from a chemistry and
solid-state physics standpoint, it ought to be able to work.

I may have misinterpreted what he said, but I throw this into the
mix for discussion purposes. :-)
-- 
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (4039.22'N, 11150.29'W)  +1 801 277 2603
email: forget about it   http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

Article: 57310
Subject: Re: I need a commercial PCI FPGA board, please help
From: Bram Stolk <b.stolk@chello.nl>
Date: Fri, 27 Jun 2003 10:47:30 GMT
Links: << >>  << T >>  << A >>
On Thu, 26 Jun 2003 21:56:58 GMT
"Garrett Mace" <g.ryan@macetech.com> wrote:

> Annapolis Micro Firebird, http://www.annapmicro.com/firebird_pci.html

A powerhouse, for sure.

But browsing your link, I saw that they also have 'Wildcard': an FPGA on
a PCMCIA card: a really smart concept! It even has linux support.
However, a real winner would be FPGA on a compact flash card.
Does such a board exist? None are listed on 
http://www.fpga-faq.com/FPGA_Boards.shtml
It would be a perfect match for a second hand iPaq as a development kit.

Thanks,

  Bram

-- 
 "Gates' Law: Every 18 months, the speed of software halves."

Article: 57311
Subject: Re: Xilinx par at max effort
From: hamish@cloud.net.au
Date: 27 Jun 2003 12:18:56 GMT
Links: << >>  << T >>  << A >>
Morten Leikvoll <mleikvol@online.nospam> wrote:
> When I implement my design using max effort (=5), and the timing analyser
> reports no timing errors, the implemented design does not work at all (very
> buggy!). I am using several clock nets, but I make sure (I hope) that all
> domains are crossed in a safe way. (The design works fine at effort 4, even
> if some of the timings are reported bad). I know others have had this
> problem. (All my small state machines are binary)
> 
> Does anyone know what the actual problem with effort 5 is: I'd like to try
> tweaking my design around those problems.

Is your design fully synchronous? How do you handle the interaction
between clock domains?

Perhaps your design depends on minimum delays which are not met when you
use the higher effort level? 

I've never seen anything like what you describe. But I would never use
an effort level less than 5.

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

Article: 57312
Subject: Spartan2e variable input threshold
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 27 Jun 2003 13:29:45 +0100
Links: << >>  << T >>  << A >>
I need to use a variable _input_ threshold on an
interface to a Xilinx Spartan2e.  I have a DAC which
can generate a voltage between 0.5V and 2.8V for Vref.
Does anyone know which of the myriad I/O standards
is optimum for this application?

I have been using SSTL3-I, which seems to work,
but I don't really know what is going on inside
the input pad - does anyone except Xilinx?




Article: 57313
Subject: Re: Eighty layers of metal!
From: mayan@sandbridgetech.com
Date: Fri, 27 Jun 2003 08:44:05 -0400
Links: << >>  << T >>  << A >>


Chris Torek wrote:
> 
> In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>,
> Robert Myers  <rmyers@rustuck.com> wrote:
> >Won't happen of course.  Possible solutions: get away from Manhattan
> >routing (25% savings in wire delay--yawn), copper interconnect (been
> >done of course, discovered from the same article that copper atoms
> >like to diffuse into silicon, maybe it's just as well that chips
> >become obsolete every few years) ...
> 
> It is, apparently, common knowledge that copper is doom, in terms
> of silicon.  So I asked my chip-process-engineer brother how Intel
> and IBM can be investigating the use of copper.  My digest of his
> answer is that the "copper equals doom" theory appears to be bunk.
> It certainly has some ways to go wrong, but from a chemistry and
> solid-state physics standpoint, it ought to be able to work.
> 
> I may have misinterpreted what he said, but I throw this into the
> mix for discussion purposes. :-)

Actually, from what I remember, your brother and robert are both right.

If copper gets into silicon, you have a decent chance of a
non-functional chip. So, what you do is you put a layer of metal(s) +
other insulators between the copper and the silicon, forming a diffusion
barrier. Bit like the rubber/plastic coating on the copper wire powering
your favorite appliance.

See:
http://domino.research.ibm.com/comm/wwwr_thinkresearch.nsf/pages/copper397.html
for a public-domain account of the development of copper at IBM.

Mayan

Article: 57314
Subject: Re: Xilinx Webpack bugs bugs bugs
From: hamish@cloud.net.au
Date: 27 Jun 2003 12:56:38 GMT
Links: << >>  << T >>  << A >>
David Brown <david@no.westcontrol.spam.com> wrote:
> FPGA design is the same.  Some things can be better expressed as schematics,
> especially for small designs, and some designers will work better with
> schematics than HDL depending on their background, experiance, and
> interests.  But to suggest that schematics are always easier to understand,
> or to design, or will always generate faster/smaller circuits, is just
> silly.

Obviously this argument depends on your definition of 'better'. The
schematic might produce fewer FFs/LUTs, but that's all. It won't be more
extendable, more generic, more reusable, or quicker to design. Unless
you're talking about a trivial design - I'm talking about a design which
can fill a pair of 2V6000s.

For the last nine months I've been working (in a team) on a design where
the major components are common to five different PCBs, using a mix of
Virtex-E and Virtex-II, speeds from 25 MHz up to 175 MHz, and even
different internal bus formats from one board to the next. VHDL lets you
parameterise your code so you can do things like this. The final code
for this design (synthesisable design plus test benches) appears to run
to about 800,000 lines.

It's been argued that schematics give you control over the gates and
flip-flops that you don't get in VHDL. Firstly, that's wrong; you can
instantiate individual FFs and LUTs in your source code and have the
synthesiser just pass them through. Or you can code so that the
synthesiser infers exactly what you want. It's not always easy and
usually requires hints (attributes) to the synthesiser.

But more importantly, IMHO the big advantage of HDL is that I don't
always have to worry about the exact FFs and LUTs. Sure, some of the
time I have to think about every last detail to get the design to run
fast. But that's what, 20-30% of the design at most? I don't want to
worry about the rest. If it runs fast enough and doesn't take too much
space then I've got better ways to use my time, like testing.

Often maintainability and reusability are more important than saving
every last flip flop, and schematics don't have a chance compared to
well-written HDL code.


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

Article: 57315
Subject: Re: MIPS instruction set?
From: Petter Gustad <newsmailcomp5@gustad.com>
Date: 27 Jun 2003 15:21:31 +0200
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp5@gustad.com> writes:

> > how is prosperity of MIPS? Who uses MIPS? What are the areas that MIPS

There's an embedded R3000 (maybe slightly modified) in the Sony
Playstation (if memory serves me right). So don't be surprised if
somebody claim that MIPS is one of the top selling architectures...

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 57316
Subject: Re: I need a commercial PCI FPGA board, please help
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Fri, 27 Jun 2003 13:22:26 GMT
Links: << >>  << T >>  << A >>
Hi Seth,

You may want to take a look at the APEX or Stratix PCI Development Kits from
Altera: http://www.altera.com/products/devkits/kit-dev_platforms.jsp.

The Stratix PCI kit looks pretty cool, and comes with the following
features:
    - Stratix 1S25 device (cutting-edge fpga)
    - PCI 32-bit/64-bit, 33/66 Mhz (PCI spec 2.3)
    - 133 Mhz PCI-X (PCI-X 2.0 Mode 1)
    - 3.3V and 5V tolerance
    - 256 MB of DDR266 memory
    - On-board flash for the FPGA
    - Ethernet 10/100 and RS-232 connectors
    - A whole bunch of debugging stuff
    - Can hook up to the Nios Development Kit (which is also pretty nifty)

Go to http://www.altera.com/products/devkits/altera/kit-pci_stx.html for
more details.

If you are interested in this dev kit, I'd talk to an Altera rep or file an
issue with mysupport.altera.com to determine whether what you want to do on
Linux is feasible.

*** Best guesses below -- contact Altera to be sure! ***

If you willing to develop the hardware under Windows, then port the device
drivers on Linux, that looks like it can be done.  The kit ships with the
Windows version of Jungo's WinDriver software, but according to their web
site a Linux edition is available and they claim that the driver code is
cross-OS portable so this *should* work.  Quartus is available for Linux, so
you could do your hardware coding under Linux.  But the Stratix PCI
Development Kit Application is made for Windows, so you would have to do
without that aspect of the tool-kit.  It *is* open-source if you're the
adventurous type!

Good luck in your hunt,

Paul Leventis
Altera Corp.


"Seth" <skintigh_spam@yahoo.com> wrote in message
news:65541f48.0306261249.2e82dd3f@posting.google.com...
> I need an FPGA board with a 64-bit 66MHz PCI bus and Linux drivers,
> and I need to be able to demo it, and I need it fast.
>
> If that's not demanding enough I can add more requirements.
>
> I have looked through 53 vendors so far and there are no real winners.
>
> Thanks in advance.



Article: 57317
Subject: Re: why so many problems Xilinx ?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 27 Jun 2003 14:23:26 +0100
Links: << >>  << T >>  << A >>
qlyus@yahoo.com (qlyus) writes:

> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EFB3967.50BF61F0@xilinx.com>...
> > qlyus wrote:
> > 
> > > Just took a look of a few pages of comp.arch.fpga Thread Subject:
> > >
> > > Jun 26, 2003 Xilinx Webpack bugs bugs bugs  (17 articles)
> > 
> > someone who loves schematics, hates hdl, found a bug.  old subject, but we
> > care, so we respond.
> > 
> 
> Is it a bug?  Old subject?  but still existing!

Most of that thread was/is a debate as to the merits of schematic vs
HDL design.  

> 
> No Xilinx people responded in this thread by the way.  SO "we respond"
> is not accurate!
> 

Steve Lass from Xilinx responded:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3EFA391B.4000806%40xilinx.com

I think the biggest reason for more Xilinx postings here is because
until very recently (ie when Altera and Xilinx settled their legal
differences and Altera were allowed to acknowledge the existence of
the word FPGA in relation to their products) you couldn't get a
response from Altera on this group, so *most* people with Altera
questions presumably asked them elsewhere.  This is starting to
change, which is a good thing IMHO.

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 57318
Subject: Re: Eighty layers of metal!
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Fri, 27 Jun 2003 13:38:27 GMT
Links: << >>  << T >>  << A >>
Hi Chris,

Copper has been solved by the process guys.  The trick is that you have to
put a barrier metal (tantalum?) between the copper and the silicon
dioxide/FSG in order to prevent the copper from diffusing into the
dielectric.  This makes copper processes more complicated (dual damascene)
and hence a little more costly, have higher defect rates (tantalum bridging,
via underfill, etc.)  Apparently, things get trickier when you mix copper
with lower-k dielectrics.

There's a nice little paper here that describes things at a pretty high
level: http://www.icknowledge.com/threshold_simonton/techtrends01.pdf

It took a while for the fab guys to get everything worked out, but now adays
I think almost everyone's in copper at .13u and definitely below.  We've
been successfully manufacturing and yielding chips use copper interconnects
since the 0.15u node (in 2001), and all of our recent FPGAs use an
all-copper process (APEX 20KC, APEX II, Stratix, Stratix GX, Cyclone).

Regards,

Paul Leventis
Altera Corp.


"Chris Torek" <nospam@elf.eng.bsdi.com> wrote in message
news:bdh5md$pa1$1@elf.eng.bsdi.com...
> In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>,
> Robert Myers  <rmyers@rustuck.com> wrote:
> >Won't happen of course.  Possible solutions: get away from Manhattan
> >routing (25% savings in wire delay--yawn), copper interconnect (been
> >done of course, discovered from the same article that copper atoms
> >like to diffuse into silicon, maybe it's just as well that chips
> >become obsolete every few years) ...
>
> It is, apparently, common knowledge that copper is doom, in terms
> of silicon.  So I asked my chip-process-engineer brother how Intel
> and IBM can be investigating the use of copper.  My digest of his
> answer is that the "copper equals doom" theory appears to be bunk.
> It certainly has some ways to go wrong, but from a chemistry and
> solid-state physics standpoint, it ought to be able to work.
>
> I may have misinterpreted what he said, but I throw this into the
> mix for discussion purposes. :-)
> -- 
> In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
> Salt Lake City, UT, USA (4039.22'N, 11150.29'W)  +1 801 277 2603
> email: forget about it   http://67.40.109.61/torek/index.html (for the
moment)
> Reading email is like searching for food in the garbage, thanks to
spammers.



Article: 57319
Subject: Re: multiple asychronous resets
From: mrand@my-deja.com (Marc Randolph)
Date: 27 Jun 2003 07:16:02 -0700
Links: << >>  << T >>  << A >>
"Ruth" <ruthsims@hotmail.com> wrote in message news:<3efc13b6$0$18497$ed9e5944@reading.news.pipex.net>...
> re-post with subject header!
> 
> Hi,
> 
> Are there any problems with having more than one asynchronous reset?
> (Altera1k50 - datasheet has some info but uncertain as to what it implies).
> I assumed that the synthesis tool just added an 'or' gate in front of the
> reset on the FF, but I've ben told recently that this is not necessarily the
> case and that it can cause problems.  Can anyone shed any light on what
> these might be please?
> 
> process (reset, clk, o_mreset)
>       begin
>            if (reset = '1') or (o_mreset = '1') then
>                 dummy <= '0';
>                 dummy2 <= '1';
>          elsif rising_edge(slow_clk) then
>                if control = '1' then
>                     dummy <= i_dummy;
>                     dummy2 <=  i_dummy2;
>             end if;
>         end if;
> end process;

Perhaps the person that told you to beware of this was referring to
the fact that some devices either (1) have reset nets that can not be
driven from within the device or (2) it is difficult to guarantee
timing under all conditions when an async reset is released.

Item 2 is still a problem as far as I'm aware, at least for Xilinx
(haven't tried Altera recently, so not sure there).

But other than those two issues, I'm not aware of any reason that it
would cause problems.

I don't know why, but I keep holding out hope that Xilinx will someday
address the release of async resets, or at least Peter or Austin will
help us find an answer to this issue (referring to Hals unanswered
questions in http://groups.google.com/groups?selm=v71unlhlf3ds74%40corp.supernews.com
and the related thread ).

   Marc

Article: 57320
Subject: Re: Eighty layers of metal!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Fri, 27 Jun 2003 16:33:39 +0200
Links: << >>  << T >>  << A >>
Paul Leventis wrote:

> Hi Chris,
> 
> Copper has been solved by the process guys.  The trick is that you have to
> put a barrier metal (tantalum?) between the copper and the silicon
> dioxide/FSG in order to prevent the copper from diffusing into the
> dielectric.

http://www.chipscalereview.com/issues/0301/techReport.html

gives an overview of barriers used. Tantalum Nitride is one of them, you 
also can use Titanium or Tungsten Nitride, and optionally add Silicon. 
Basically what you want is a robust crystal that doesn't allow the copper 
to migrate through. There are many available, pick those which can be 
processed easily and don't cost too much. Titanium Nitride is already used 
as barrier for the AlCu alloys, so the question is whether it's good enough 
(there are doubts). Tungsten has the disadvantage of crystalizing into 
nano-needles, which increases the surface resistance (not that Tungsten has 
a good inner resistance, either), but it works. Tungsten is also often used 
as local interconnect, and some processes use Tungsten barriers for AlCu 
(e.g. xfab 0.6u).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Article: 57321
Subject: Re: Xlilin xc9572XL Default register values
From: Dennis McCrohan <mccrohan@xilinx.com>
Date: Fri, 27 Jun 2003 07:40:57 -0700
Links: << >>  << T >>  << A >>
Ralph Mason wrote:

> "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote
> in message news:rvOKa.52693$JA5.936325@news.xtra.co.nz...
> > I have a design in VHDL for a xc9572xl done using the web pack software.
> >
> > I am wanting to know how I can set the startup values of the registers.
> >
>
> After some more research it seems that I need to use the 'init' attribute.
>
> But I have had no luck initing a register.
>
>     type v_reg_type is record
>         -- registers
>         IOLatch     :   std_logic_vector(4 downto 0);
>         IOLatch2     :   std_logic_vector(4 downto 0);
>     end record;
>
>  signal r, rin : v_reg_type;
>
> I want to do something like
>
> attribute init of signal r.IOLatch  : signal "10101";
>
> (Clearly assuming I am on the right path)
>
> But I have had no luck persuading webpack to compile it.
>
> Thanks for any pointers.
> Ralph

Hi Ralph:

The proper VHDL syntax is:

  attribute init: string;
  attribute init of q : signal is "S"; -- power up to 1, use "R" for 0.

Where the attribute statements go in your entity declaration, right after the
port declarations, e.g:

entity mydesign is
    port( .... );
   attribute init: string;
   attribute init of q : signal is "S"; -- power up to 1, use "R" for 0.
end mydesign;

The attribute statement will not, of course, affect the behaviorial simulation
results. To change those, use the normal VHDL default value mechanism.

An alternate mechanism to attribute init that works for all entry methods
(Abel, schematic, Verilog, VHDL) is to add the constraint to a .ucf file:

NET mysignal INIT=S;

If you don't already have a .ucf file as part of your design, use Project->New
Source in iSE 5.2i to add one.

Good Luck,

Dennis McCrohan
Xilinx CPLD S/W




Article: 57322
Subject: Re: Eighty layers of metal!
From: cecchi@signa.rchland.ibm.com (Del Cecchi)
Date: 27 Jun 2003 14:46:24 GMT
Links: << >>  << T >>  << A >>
In article <bdh5md$pa1$1@elf.eng.bsdi.com>,
 Chris Torek <nospam@elf.eng.bsdi.com> writes:
|> In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>,
|> Robert Myers  <rmyers@rustuck.com> wrote:
|> >Won't happen of course.  Possible solutions: get away from Manhattan
|> >routing (25% savings in wire delay--yawn), copper interconnect (been
|> >done of course, discovered from the same article that copper atoms
|> >like to diffuse into silicon, maybe it's just as well that chips
|> >become obsolete every few years) ...
|> 
|> It is, apparently, common knowledge that copper is doom, in terms
|> of silicon.  So I asked my chip-process-engineer brother how Intel
|> and IBM can be investigating the use of copper.  My digest of his
|> answer is that the "copper equals doom" theory appears to be bunk.
|> It certainly has some ways to go wrong, but from a chemistry and
|> solid-state physics standpoint, it ought to be able to work.
|> 
|> I may have misinterpreted what he said, but I throw this into the
|> mix for discussion purposes. :-)
|> -- 

Copper is doom.  IBM shipping large quantities of copper metallized chips.  Hmm,
secret double damascene process to keep copper out of si.  

Change "it ought to be able to work" to "It works"
-- 

Del Cecchi  
cecchi@us.ibm.com
Personal Opinions Only

Article: 57323
Subject: Re: Partial reconfiguration of Vertex-2 devices.
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 27 Jun 2003 10:48:32 -0400
Links: << >>  << T >>  << A >>
"Kelvin Tsai @ Singapore" wrote:
> 
> Hi, all:
> 
> In the Vertex-2 datasheet, it mentioned about partial reconfiguration,
> where can I find more information on this topic? I have a variable
> design and a fixed design to put on same V-2 chip.
> 
> Will partial reconfiguration process halt the current operation of the
> 'fixed' design on the chip?
> 
> How can I guarantee the variable design doesn't rob away the hardware
> of my fixed design?
> 
> Thanks.
> Kelvin

Now that's the sticky wicket, isn't it?  

While manufacturers offer devices that support partial reconfiguration,
they don't seem to offer the required support in software to generate
useful bitstreams.  The tricky part is keeping the routing from a given
portion from running into the routing from another portion and also
being able to provide interfaces for the wiring that needs to hookup.  

If there is support for this, I am not aware of it.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 57324
Subject: Re: Xlilin xc9572XL Default register values
From: Steven Elzinga <steven.elzinga@xilinx.com>
Date: Fri, 27 Jun 2003 08:50:54 -0600
Links: << >>  << T >>  << A >>
Ralph,

Another method (aside from passing an INIT) is to initialize the signal 
that will be registered:

library ieee;
ues ieee.std_logic_1164.all;

entity ff is
port (d, c : in std_logic;
      q : out std_logic);
end entity;

architecture ff_arch of ff is
signal q_temp : std_logic := '0';  -- XST will pass the proper INIT 
value based off of the signal initialization
                                   -- This INIT value is the state to 
which the register will power up
                                   -- q_temp is the signal that will be 
registered
begin
:
:


Steve


Ralph Mason wrote:

>I have a design in VHDL for a xc9572xl done using the web pack software.
>
>I am wanting to know how I can set the startup values of the registers.
>
>Thanks
>Ralph
>
>
>
>  
>




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

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