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

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

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

Custom Search

Messages from 75325

Article: 75325
Subject: Re: Clock Extraction from Bi-Phase Data
From: Walter Dvorak <use-reply-to@gruebel.invalid>
Date: Tue, 2 Nov 2004 14:23:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
KVP <kapilpatel@yahoo.com> wrote:
> How can we extract clock from bi-phase encoded data (3.072Mbps -
> AES/EBU Data) using CLKDLL of Xilinx FPGA. The clock should be able to
> adjust itself to any slight drifting of the bi-phase data.

	consider to use a external AES/EBU receiver, like Crystal 
CS8413/14. 

	Using techniques like clock-shifting-DLL etc.. in a FPGA for 
an AES/EBU receiver is not a good idea: The clock for the audio 
samples must be very accurate. You will get bad THD & SN-ratio.

WD
-- 

Article: 75326
Subject: Re: XST - Memory Problems
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 2 Nov 2004 14:26:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
Eric <swankoski@nrl.navy.mil> wrote:
: OK, so I'm trying to synthesize a huge design. Just for quick
: reference, the inferred macros are below:

: HDL Synthesis Report

: Macro Statistics
: # Block RAMs                       : 112
...
: # Multipliers                      : 480

What part do you traget for?
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 75327
Subject: Re: CPLDs and Safety? Re: ASICs Vs. FPGA in Safety Critical Apps.
From: "Falk Salewski" <salewski@informatik.rwth-aachen.de>
Date: Tue, 2 Nov 2004 15:46:24 +0100
Links: << >>  << T >>  << A >>
Is this reliability data availible? Can I find it in your Xilinx Device 
Reliability Report?
And still there is the question, if CPLDs might have a higher reliability 
than FPGAs.

Falk

"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag 
news:BDA7AF5C.99DE%peter@xilinx.com...
> Let's keep things in pespective.
> Yes, "SRAM-based" FPGAs can be upset by random SEUs. But how likely is 
> this?
> We at Xilinx have done extensive real-time tests with thousands of large
> devices (XC2V6000) over more than a year, and here is a snapshot of the
> result:
> A device of Virtex-II 1000 complexity ( "1 million FPGA gates") is likely 
> to
> pick up a functional error due to SEU roughly once per thousand years of
> operation.
> The much smaller XC2V40 is about twice the complexity of the largest CPLD,
> and it would encounter a functional error once per 25000 years.
> That's a pretty good MTBF. Better than the FIT rate of many other, even
> passive, coponents.
> Peter Alfke, Xilinx Applications
> =====================
>> From: "Benjamin Todd" <benjamin.toddnospam@cern.ch>
>> Organization: CERN - European Laboratory for Particle Physics
>> Newsgroups: comp.arch.fpga
>> Date: Fri, 29 Oct 2004 11:37:38 +0200
>> Subject: Re: CPLDs and Safety?  Re: ASICs Vs. FPGA in Safety Critical 
>> Apps.
>>
>> Could you post a link to the original article?
>>
>> There are lots more concerns other than the reprogramming.  One such 
>> thing
>> is the effect of Single Event Upsets.
>> For example, configuration bits of the FPGA/CPLD can be flipped by SEUs
>> (even at sea-level this is more important than MTBF) making the logic you
>> designed behave incorrectly.
>>
>> Of course mitigation techniques exist, such as Triple Mode Redundancy, 
>> (and
>> Device read-back and reconfiguration for some devices)
>>
>> Having said that CPLDs are much smaller devices, often at higher internal
>> voltages, hence don't have the same problems with MTTE. If your system is
>> small enough, and can be made fully redundant to cover MTBF failures, 
>> CPLD
>> would be my advice.
>>
>> You want to check out the IEC-61508 Standard, and the Xilinx Military
>> applications page.
>> (or http://lhc-mpwg-reliability.web.cern.ch/lhc%2Dmpwg%2Dreliability/)
>> HTH
>> Ben
>>
>>
>>
>>
>> "Falk Salewski" <salewski@informatik.rwth-aachen.de> wrote in message
>> news:2uee97F28fi9jU1@uni-berlin.de...
>>> I am interested in safety for embedded applications. So I read this
>> articels
>>> dealing with "ASICs Vs. FPGA in Safety Critical Apps." posted around 
>>> 1996
>>> with great interest.
>>>
>>> People listed a lot of advantages of FPGAs, however the major problem
>>> (related to safety) left was that the FPGA has to be reprogrammed at 
>>> each
>>> power up.
>>>
>>> My question: isn't an CPLD a good solution for small safety critical
>>> applications?
>>>
>>> Falk
>>> ----------------------------------------------------------
>>> Chair of Computer Science XI
>>> RWTH Aachen University
>>> Germany
>>>
>>>
>>
>>
> 



Article: 75328
Subject: Re: How to preserve net names in DC while synthesis
From: "Tom Verbeure" <hombre@gmail.com>
Date: 2 Nov 2004 07:20:42 -0800
Links: << >>  << T >>  << A >>

> Does anyone know how to preserve the "wire" names in the netlist so
> that it is wasy for debugging the netlist. I used dont_touch command
> with net name , but I think this will reduce the logic optimization
> by the tool.. what do u think

There's no easy way if you want the best optimization. The signals
connected to registers are usually preserved, but after that you're
more or less at the mercy of the synthesis tool. If you absolutely need
to get some signals preserved, I'm not sure dont_touch will help that
much. Probably the best way is to bring internal signals to the top as
output ports and ask DC not to optimize them away if they're not
connected. I assume there must a flag for this somewhere, though I
haven't really looked into it.

We've pretty much given up on even trying to get a nice match and have
formal equivalence check validate the correctness of the netlist. Yes,
this makes netlist hacking extremely painful: just try to make sure
your RTL is correct. :-)

Tom


Article: 75329
Subject: Re: "frying" FPGAs
From: Jim Lewis <Jim@SynthWorks.com>
Date: Tue, 02 Nov 2004 07:24:17 -0800
Links: << >>  << T >>  << A >>
Hi,
One of the boards I use expects a 3.3 regulated voltage.
Unfortunately the plug for the board is also compatible
with my laptop (~ 12V).  I have killed one board this way.

In the lab we avoid this by connecting the board and the
power cube before connecting the power cube to the
power strip.

For all of our labs, we provide the UCF file for the project.

The boards cost about the same price of a text book.
Perhaps the students should own the board.

Cheers,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 75330
Subject: Re: Question on Xilinx VirtexProII PCMCIA support (FPGA boards)....
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 02 Nov 2004 07:36:05 -0800
Links: << >>  << T >>  << A >>
Mark,

Please go to the website, and look up the University program, and make 
contact with them.

Austin

Mark Levitski wrote:
> Greetings Antti,
> 
> We do have one ML300 and can easily get 5 units, we're a University - this 
> board is supposedly cheaper and we're not "phasing it out" for our 
> project.... :)  I might be wrong.
> 
> Thanks for any info you provide, I relay all these Newsgroups postings to 
> our group professor/leader and fellow PhD stuidents (without disclosing your 
> emails). 
> 
> 

Article: 75331
Subject: Re: "frying" FPGAs
From: "keith.a.williams.3" <kawillia@purdue.edu>
Date: Tue, 2 Nov 2004 10:36:16 -0500
Links: << >>  << T >>  << A >>
On Mon, 1 Nov 2004, zerang shah wrote:

> I work at a university, and we just got a bunch of FPGA boards with
> Spartan 2E's on them. It's like five weeks into the quarter, and
> already 6 of 20 boards have died. I contacted tech support for the
> board manufacturer, and it seems that the FPGAs have been "fried" on
> all six of the bad boards, judging from the fact that both the onboard
> voltage regulators and FPGAs both get really hot, and the power-on LED
> fails to turn on. Looking at the boards very closely I see no signs of
> physical mistreatment though.
>
> The boards are being programmed using jtag cables + iMPACT with
> bitfiles created with Foundation. At first I thought that maybe a
> backward jtag cable would fry the FPGA, but it turns out that's not
> the case. Really I have no idea what people could be doing to these
> boards.
>
> So here's my question: How do you fry an FPGA?? I guess running like
> 50 volts through it would do the job, but I don't think the cause of
> these failures is a malicious user. Is there anyway to "accidentally"
> synthesize a design that causes an FPGA to destroy itself???
>
> Thanks for the help.
>

With my first attempt at VHDL about ten years ago, I inadvertantly
instantiated two logic blocks to try to drive the same pin.  I cooked two
chips before finding the contention.

This, however, was with a very rudimentary VHDL compiler with very little
sanity checking.

Keith

Article: 75332
Subject: Re: TIME borrowing in synthesis
From: "Tom Verbeure" <hombre@gmail.com>
Date: 2 Nov 2004 07:39:49 -0800
Links: << >>  << T >>  << A >>

Time borrowing is a concept that is used in latch based pipelines in
which you typically have 2 stages of combinatorial surrounded by
latches. If the first combinational piece of logic has a much longer
delay than the second one, you can borrow some of the time of the
second part to the first part. A somewhat more comprehensive
explanatation can be found here:

http://www.synopsys.com/products/logic/design_comp_tb.html

Search for 'borrowing'...
We have used this technique in FF based design where we captured the
output of a RAM that was too slow to finished in a clock cycle and then
registered it with FF's in a later stage. The use of latches in
standard FF based design kills regular scan-based testing, so these
technique should be used with great care!

Since these latches aren't used a lot these day, my guess is that you
unintentionally added latches to your design and this resulted in the
warning above. If this is the case, just remove them and the warning
will be gone. :-)

Tom


Article: 75333
Subject: Re: max frequency with TSMC .18u std cell library
From: "Tom Verbeure" <hombre@gmail.com>
Date: 2 Nov 2004 07:43:31 -0800
Links: << >>  << T >>  << A >>

Just an idea: could it be that you set the accuracy of the verilog
simulator to 1 ns? In this case, all timings will be rounded up to a
multiple of 1 ns...

Tom


Article: 75334
Subject: Re: XST - Memory Problems
From: Laurent Gauch <laurent.gauch@DELETEALLCAPSamontec.com>
Date: Tue, 02 Nov 2004 16:57:15 +0100
Links: << >>  << T >>  << A >>
Eric wrote:
> OK, so I'm trying to synthesize a huge design. Just for quick
> reference, the inferred macros are below:
> 
> HDL Synthesis Report
> 
> Macro Statistics
> # Block RAMs                       : 112
> # Multipliers                      : 480
> # Registers                        : 13434
> # Multiplexers                     : 1070

your design is two huge to be put in only one FPGA ...

You will need to split your desing in more FPGAs.

Laurent

Article: 75335
Subject: Re: XST - Memory Problems
From: "Antti Lukats" <antti@case2000.com>
Date: Tue, 2 Nov 2004 17:13:59 +0100
Links: << >>  << T >>  << A >>
"Eric" <swankoski@nrl.navy.mil> wrote in message
news:84d8efa2.0411020557.78be0f2e@posting.google.com...
> OK, so I'm trying to synthesize a huge design. Just for quick
> reference, the inferred macros are below:

> "ERROR: Portability:3 - This Xilinx application has run out of memory
> or has encountered a memory conflict..."

most Xilinx errors are in the "Portability" DLL :( usually such error means
you need to wait for next Service pack. or the next one, etc..

2.5Gb is not enough :(
I guess you are targetting VP100
not sure if more memory solves the problem, users with 3GB RAM have seen the
same error even with VP70

Xilinx is "commited" to fix all fatal errors, such as yours, so just go
start complaining! open webcase etc..

Antti



Article: 75336
Subject: Re: FPGA & DDR-SDRAM
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 2 Nov 2004 08:40:17 -0800
Links: << >>  << T >>  << A >>
Hi Allan,
Good points but, playing Devil's advocate, with just one address/control
bus, there's only half as many signals to worry about. Duplicating the
busses, you start eating up board area, lengthening the traces, making the
problem worse than if you just placed the two DIMMs right next to each other
on the same short bus.
So, I vote for one bus. Especially as the DDR SDRAM data sheets are full of
apps notes telling you how to do it!
Cheers, Syms.
p.s. If you're really worried, I believe Xilinx will tell you about the
trace lengths in the BGA package substrate to include in your simulations.

"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:g9heo0d68i44rl387ke5gahitnmnid6loh@4ax.com...
> On Tue, 2 Nov 2004 09:12:11 +0100, "Quinn"
> <quinn_the_esquimo@freenet.de> wrote:
>
> It will soon become apparent that a simple "point to point" connection
> can be made to work at speeds up to several hundred MHz without too
> much pain, but things are a little harder if you have multiple loads.
> The signal will take longer to settle, and this will eat into your
> timing margin.
>
> I assume that you will be using a clock of >= 200MHz, which means that
> your timing margin is probably less than 1ns.
>
> Also, when simulating, don't forget to take the DIMM tracks into
> account.  You care about the signal quality at the chip pins, not the
> DIMM pins.
>
> Regards,
> Allan



Article: 75337
Subject: Re: XST: suppressing incorrect optimizations in VHDL code
From: newman5382@aol.com (newman)
Date: 2 Nov 2004 08:58:25 -0800
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote in message news:<cNmdnRwJMaA2TBvcRVn-uA@megapath.net>...
> >I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. 
> >There appear to be some third party offerings.  One may easily write
> >one that does the job with sed (less than 10 lines).
> 
> Standard cpp works fine.  Everything gets much saner if you have a makefile.

Hal,
  Thanks for the tip.  I'll have to try it out sometime.  My sed trick
worked OK for small design differences, but it raised a few
eye-browses because it was so ad-hoc.

Newman

Article: 75338
Subject: Re: FPGA & DDR-SDRAM
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 02 Nov 2004 17:06:48 GMT
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message
news:2uprjlF2ectrlU1@uni-berlin.de...
> Hi Allan,
> Good points but, playing Devil's advocate, with just one address/control
> bus, there's only half as many signals to worry about. Duplicating the
> busses, you start eating up board area, lengthening the traces, making the
> problem worse than if you just placed the two DIMMs right next to each
other
> on the same short bus.

[snip]

I'd agree with the single address/control bus as well if the two modules are
placed next to each other as are typical dual-DIMM systems.  The only
difference here is that the bank selects are common to both modules rather
than separate and there are twice the number of byte lanes.  Otherwise, all
dual-DIMM issues still apply.  Different clocks go to the different modules
so there is 1 load per clock.  A preload of the address/control bus may be
helpful.  Check out the Micron app notes for DDR DIMMs and you'll see the
issues that need to be addressed for using two DIMMs.

If the board is too crowded with 16 bytes lanes going through 2 DIMMs (which
does sound agressive) then the separate address/control for the separate
modules would be helpful for DIMMs that aren't parallel.



Article: 75339
Subject: FPGA/CPLD Basics
From: nospam4u_jack@yahoo.com (Jack// ani)
Date: 2 Nov 2004 09:14:36 -0800
Links: << >>  << T >>  << A >>
Hi all,

Is there any tutorial on web, where I can learn about working and
architecture of FPGA and CPLD?

Google turned out to be useless. Someone out there maybe is having
some helpful pointer.

Any suggestion regarding reference/text books is also appreciated. 

TIA

Article: 75340
Subject: ise and edk integration
From: cybershakith@hotmail.com (Shakith)
Date: 2 Nov 2004 09:35:34 -0800
Links: << >>  << T >>  << A >>
I am working on project on ML310 board with Virtex 2 Pro
There is a AES encryption that was converted to verilog from Systemc for usage.
How do i callup and integrate this to C application i am developing in EDK??


Thanks in Advance
Cheers
Shakith

Article: 75341
Subject: FPGA Advantage and Xilinx Specific Libs (like Unisim)
From: mmdst23@gmail.com (Mike Delaney)
Date: 2 Nov 2004 12:56:43 -0800
Links: << >>  << T >>  << A >>
What's the best way to get the Xilinx libs like Unisim working for
simulating a design in FPGA Advantage 6.1?  I got it working before,
but I have no idea what I did last time, and I need to set it up
again.

Also, if I just comment out the library-related statements, should it
synthesize properly in Precision?  And is it possible to synthesize IP
from the Xilinx EDK in anything but XST?

Thanks,
Mike

Article: 75342
Subject: Re: Strange XST error in ISE 6.3.02i
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 02 Nov 2004 17:44:42 -0500
Links: << >>  << T >>  << A >>
Alan Fitch wrote:
> 
> Something that is locally static can have its value determined purely
> during analysis of that design unit, it doesn't require elaboration
> of the complete design hierarchy.
> 
> The standard defines static and locally static in section 7.4.

Thanks.  It says a function call has to be an "implicitly defined
operator", which I can't find a meaning for.  


> It does look to me as though XST may be correct, as it says that
> a constant is only locally static if it is initialized by a locally
> static primary (which doesn't include a function call).

It doesn't include the word "primary", just initialized by a locally
static expression.  

> I don't understand what your TO_INTEGER function does, sorry :-(

It just converts and array of three integers to another integer by
treating them as exponents of 2 and summing them.  The binary number
11010 could be represented as (1, 3, 4) which would be evaluated as 26
decimal.  This was just to allow me to input my info in the form it was
already in.  Not a biggie, I have already fixed it by making it an
expression.  

-- 

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: 75343
Subject: Re: "frying" FPGAs
From: Mike Peattie <mike.peattienospam@xilinxnospam.com>
Date: Tue, 02 Nov 2004 15:40:56 -0800
Links: << >>  << T >>  << A >>
zerang shah wrote:
> I work at a university, and we just got a bunch of FPGA boards with
> Spartan 2E's on them. It's like five weeks into the quarter, and
> already 6 of 20 boards have died. I contacted tech support for the
> board manufacturer, and it seems that the FPGAs have been "fried" on
> all six of the bad boards, judging from the fact that both the onboard
> voltage regulators and FPGAs both get really hot, and the power-on LED
> fails to turn on. Looking at the boards very closely I see no signs of
> physical mistreatment though.
> 
> The boards are being programmed using jtag cables + iMPACT with
> bitfiles created with Foundation. At first I thought that maybe a
> backward jtag cable would fry the FPGA, but it turns out that's not
> the case. Really I have no idea what people could be doing to these
> boards.
> 
> So here's my question: How do you fry an FPGA?? I guess running like
> 50 volts through it would do the job, but I don't think the cause of
> these failures is a malicious user. Is there anyway to "accidentally"
> synthesize a design that causes an FPGA to destroy itself???
> 
> Thanks for the help.

One way to blow up a device is to try to download a bitstream that is 
targeted to a different device, like loading a 2s50 bitstream into a 
2s200 part.  Here's the link:

http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=8436

Not that likely in a strict design environment, but I could see it 
happening quite often in a classroom setting.  Notice this is no longer 
an issue for Virtex-II(Spartan-3) and later devices.

HTH,

Mike

-- 
--
-- Please ignore the reply to address, and use
-- mike -dot- peattie -at- xilinx -dot- com
--

Article: 75344
Subject: Xilinx Maximum output required time after clock
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 2 Nov 2004 15:49:08 -0800
Links: << >>  << T >>  << A >>
What does this mean?

Maximum output required time after clock: 6.060ns

Is this the time required for the clock edge at the pin
to some register inside the fpga or from the edge to
some signal at an output pin or something else?

b r a d



Article: 75345
Subject: Re: Low-power FPGAs?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 03 Nov 2004 10:43:26 +1000
Links: << >>  << T >>  << A >>
Phil Short wrote:
> On Mon, 01 Nov 2004 00:32:27 -0500, rickman wrote:
> 
>>Yes, but I explained how in a real time system, this only moves the
>>problem from the clock domain to the system domain.  Your chip can run
>>at faster speeds when it is cooler or just a faster chip (process) but
>>that won't be of any value since you have to design your system to the
>>worst case chip delay.
>>
> 
> I wasn't talking about the system domain.  You are correct in hinting that
> there are significant problems interfacing between sync and async chips,
> such that the literature suggests that most of the speed benefits of async
> design may be lost in this case.  It seems that it would be better if
> everything in the system is async, rather than a mix.  Just another
> problem in gaining more widespread acceptance.

Although risking pouring petrol on the embers of this discussion, the 
following might be of interest:

ARM And Philips' Handshake Solutions Collaborate To Develop Clockless 
Processor

http://www.arm.com/news/6936.html

Regards,

John

Article: 75346
Subject: Re: Low-power FPGAs?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 03 Nov 2004 13:47:52 +1300
Links: << >>  << T >>  << A >>
John Williams wrote:
<snip>
> Although risking pouring petrol on the embers of this discussion, the 
> following might be of interest:
> 
> ARM And Philips' Handshake Solutions Collaborate To Develop Clockless 
> Processor
> 
> http://www.arm.com/news/6936.html

  Yes, that was the trigger to this thread, first noted by Symon on 28 Oct.
  Some silicon should appear in 2005, and then 'like process' comparisons
can be made.
  It could be that this will be used for Async versions of the 
ARM-Cortex, ( http://www.arm.com/news/6750.html )
which would make 'like core' comparisons harder :)


-jg


Article: 75347
Subject: Re: Low-power FPGAs?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 03 Nov 2004 10:57:45 +1000
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> John Williams wrote:
> <snip>
> 
>> Although risking pouring petrol on the embers of this discussion, the 
>> following might be of interest:
>>
>> ARM And Philips' Handshake Solutions Collaborate To Develop Clockless 
>> Processor
>>
>> http://www.arm.com/news/6936.html
> 
> 
>  Yes, that was the trigger to this thread, first noted by Symon on 28 Oct.

Oh no, I've triggered thread-recursion - prepare for a usenet meltdown! :)

John


Article: 75348
Subject: Re: information about Nuhorizon Spartan-3 Development Board ?
From: Richard Newman <newmanrf@precisioneagles.com>
Date: Tue, 02 Nov 2004 20:33:29 -0500
Links: << >>  << T >>  << A >>

>Looking at mail from other people and their expierence with that board,
>I guess, I'm pretty happy without ;-)
>

	I prefer to purchase through NuHorizons because our sales
person takes good care of us by getting us samples quickly with the
least amount of hassle. He has introduced us to great devices like the
smsc 91c111 ethernet chip, ST line of small CPU's and Micrel's single
chip MICRF505 radio transceiver, all of which are doing well for us.

	Because of NuHorizons good support when I decided to divest
into FPGA the Xilinx line was a obvious choice and I purchased one
NuHorizons HW-AFX-SP3-400-DB board and one Xilinx Spartan 3 Starter
kit, both of which were in stock, delivered very quickly and worked
out of the box. Both of the kits are relatively easy to use even
though the Xilinx kit came with printed documentation.

	The world is changing and customer service is not what it used
to be and people who work at companies act like they would rather be
somewhere else but still get paid for it. NuHorizons has treated my
company and I well for over two years and I prefer to work with them
given my options.

	The NuHorizons Xilinx 3 evkit is a valuable and interesting
design resource at a unbeatable price. That is my experience.

Richard Newman
PST Precision Design
Allentown PA USA





Article: 75349
Subject: Re: "frying" FPGAs
From: Jim Lewis <Jim@SynthWorks.com>
Date: Tue, 02 Nov 2004 18:16:45 -0800
Links: << >>  << T >>  << A >>
Mike,
> One way to blow up a device is to try to download a bitstream that is 
> targeted to a different device, like loading a 2s50 bitstream into a 
> 2s200 part.  Here's the link:
> 
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=8436 
> 
> 
> Not that likely in a strict design environment, but I could see it 
> happening quite often in a classroom setting.  Notice this is no longer 
> an issue for Virtex-II(Spartan-3) and later devices.

Can the same thing happen if I use the correct device, but the
device does not successfully program?   I have a particularly
high programming failure rate with XST 6.2.02i.  The parallel
port programming cable is thin and it is right next to the
power cord on the laptop, so there may be some noise issues.

Regards,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



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

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

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

Custom Search