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 146275

Article: 146275
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Wed, 10 Mar 2010 12:14:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote:
>
> Hi Jeff,
> I've examined all the old FPGAs I've found in my office, and they all
> seem to have three dimensions already. Even the old ones from 1986.

Hehe ;) - yes, even Tabula are trying to spin 3D too...

 Still, getting back to the site itself, it seems they
have a Stacked-die prototype path, and the main thrust is really mask-
asic.

 The stacked die 'emulation devices' will come at a large price
premium, and their config density will need to be low (given this is
top-layer stuff).
I'd expect a power premium too...

 The advantage is you CAN get closer to real field emulation, (as
opposed to devices like Atmel's CAPxx, which can only offer bench-
emulation, via a large FPGA)

[" Free NRE
Qualifying production orders of $50k+ for converting an existing
production FPGA to a compatible TierASIC=99 device are eligible for free
NRE and conversion."]

That leaves the final chestnuts, of packaging and Price.

 One opening I can see in CPLD/FPGA space, is smaller devices with
MORE RAM. - ie really a RAM+CPLD, or
a smart ram, if you like.
 That type of product also tends to be somewhat more
stable in code, so could suit TierLogic flows.

 Full DualPort memories are very expensive, and large,
and FPGAs have low SRAM levels, until you get very large.

 The ProgLogic+Micro space is filling up: Atmel & ST target the
ramping-volume with their MASK variants, and
we have Cypress and Actel with FlashuC+ProgLogic offerings.

-jg


Article: 146276
Subject: Re: Why doesn't this situation generate a latch?
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 10 Mar 2010 12:19:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 12:08=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
>
> It would be interesting to have an FPGA with transparent latches
> after each LUT instead of the current edge triggered FFs.
>
> -- glen

Glen, I simplified a little. I was frustrated by all the VHDL mumbo-
jumbo.

To answer your suggestion:
Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4
and 6 can configure each flip-flop as a latch, although this is a
rarely-used feature.
(How fast I forget such exotic facts).
Peter


Article: 146277
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Wed, 10 Mar 2010 12:30:29 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 5:46=A0am, Tier Logic <jeff.ka...@gmail.com> wrote:
> The world's first 3D FPGA has arrived! We have a very compelling and
> cost effective solution.
>
> Come check it out folks.www.tierlogic.com

Pity, rather a bad fumble at first hurdle.

The Prog Logic space is VERY broad indeed, and yet there is NO
indication of which parts of that TierLogic target: Even the simplest
things, like packages and speeds.

Imagine Toyota saying "We have a new product, with 4 wheels - sign up
to learn more".  ?!

-jg






Article: 146278
Subject: Re: Why doesn't this situation generate a latch?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 10 Mar 2010 20:31:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Peter Alfke <alfke@sbcglobal.net> wrote:
(snip)
 
> To answer your suggestion:
> Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4
> and 6 can configure each flip-flop as a latch, although this is a
> rarely-used feature.
> (How fast I forget such exotic facts).

I didn't know that!  

There is discussion in another newsgroup about recreating the
IBM 360/91 in an FPGA.  I believe that is the machine that the
Earle latch was invented for.  (Maybe it was the Stretch.)

The Earle latch pretty much takes one level of logic and combines
it with the logic of a transparent latch.  When every propagation
delay counts, that helps a lot.  

-- glen

Article: 146279
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: rickman <gnuarm@gmail.com>
Date: Wed, 10 Mar 2010 13:41:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 3:14=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote:
>
> > Hi Jeff,
> > I've examined all the old FPGAs I've found in my office, and they all
> > seem to have three dimensions already. Even the old ones from 1986.
>
> Hehe ;) - yes, even Tabula are trying to spin 3D too...
>
> =A0Still, getting back to the site itself, it seems they
> have a Stacked-die prototype path, and the main thrust is really mask-
> asic.
>
> =A0The stacked die 'emulation devices' will come at a large price
> premium, and their config density will need to be low (given this is
> top-layer stuff).
> I'd expect a power premium too...

Stacked die?  I read the eetimes article and didn't get anything about
stacked die from Tier Logic.  Did I read something wrong?  I thought
they were layering TFT on top of the base die to provide the config
memory which takes it out of the base die saving real estate.  I am
sure the savings is somewhat mitigated by the need for vias to the
lower layers, but still a 35% (or something like that) savings in size
is nothing to sneeze it.  I bet AMD wishes they could get that on
their CPU die right now!


> =A0The advantage is you CAN get closer to real field emulation, (as
> opposed to devices like Atmel's CAPxx, which can only offer bench-
> emulation, via a large FPGA)

They seem to be pushing their ability to more easily move to ASIC
production, but they seem to offer something to the FPGA only user as
well.  I'd be willing to bet there is a premium compared to ASICs so
they are taking a middle ground in that regard.


> [" Free NRE
> Qualifying production orders of $50k+ for converting an existing
> production FPGA to a compatible TierASIC=99 device are eligible for free
> NRE and conversion."]
>
> That leaves the final chestnuts, of packaging and Price.
>
> =A0One opening I can see in CPLD/FPGA space, is smaller devices with
> MORE RAM. - ie really a RAM+CPLD, or
> a smart ram, if you like.
> =A0That type of product also tends to be somewhat more
> stable in code, so could suit TierLogic flows.
>
> =A0Full DualPort memories are very expensive, and large,
> and FPGAs have low SRAM levels, until you get very large.
>
> =A0The ProgLogic+Micro space is filling up: Atmel & ST target the
> ramping-volume with their MASK variants, and
> we have Cypress and Actel with FlashuC+ProgLogic offerings.

I'm not clear on what you are saying about this in regards to Tier
Logic.

Rick

Article: 146280
Subject: Re: Why doesn't this situation generate a latch?
From: Peter Alfke <alfke@sbcglobal.net>
Date: Wed, 10 Mar 2010 13:44:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 12:31=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> In comp.arch.fpga Peter Alfke <al...@sbcglobal.net> wrote:
> (snip)
>
> > To answer your suggestion:
> > Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4
> > and 6 can configure each flip-flop as a latch, although this is a
> > rarely-used feature.
> > (How fast I forget such exotic facts).
>
> I didn't know that! =A0
>
> There is discussion in another newsgroup about recreating the
> IBM 360/91 in an FPGA. =A0I believe that is the machine that the
> Earle latch was invented for. =A0(Maybe it was the Stretch.)
>
> The Earle latch pretty much takes one level of logic and combines
> it with the logic of a transparent latch. =A0When every propagation
> delay counts, that helps a lot. =A0
>
> -- glen

Glen: from the Virtex-6 User Guide Lite:
The look-up tables (LUTs) in Virtex-6 FPGAs can be configured as
either 6-input LUT (64-bit ROMs) with one output, or as two 5-input
LUTs (32-bit ROMs) with separate outputs but common addresses or logic
inputs. Each LUT output can optionally be registered in a flip-flop.
Four such LUTs and their eight flip-flops as well as multiplexers and
arithmetic carry logic form a slice, and two slices form a
configurable logic block (CLB). Four flip-flops per slice (one per
LUT) can optionally be configured as latches. In that case, the
remaining four flip-flops in that slice must remain unused.

So, that says it: 4 latches per slice. Perhaps not the highest
efficiency, but not too bad.

PS, I am very proud of these User Guides Lite, created and published
as a bootleg project, but still very popular with users.
Peter

Article: 146281
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Wed, 10 Mar 2010 13:54:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 10:41=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 10, 3:14=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
>
>
> > On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote:
>
> > > Hi Jeff,
> > > I've examined all the old FPGAs I've found in my office, and they all
> > > seem to have three dimensions already. Even the old ones from 1986.
>
> > Hehe ;) - yes, even Tabula are trying to spin 3D too...
>
> > =A0Still, getting back to the site itself, it seems they
> > have a Stacked-die prototype path, and the main thrust is really mask-
> > asic.
>
> > =A0The stacked die 'emulation devices' will come at a large price
> > premium, and their config density will need to be low (given this is
> > top-layer stuff).
> > I'd expect a power premium too...
>
> Stacked die? =A0I read the eetimes article and didn't get anything about
> stacked die from Tier Logic. =A0Did I read something wrong? =A0I thought
> they were layering TFT on top of the base die to provide the config
> memory which takes it out of the base die saving real estate.

Yes they are, which is why I called it stacked die.
- TWO die flows, one on top of the other.

 Base die is made, and then they have a second die-process that is
more complex than just TFT, as it
included connections. [Testing questions remain?]

 That will also be why they needed a lot more passes at the TFT
section, as that's where the 'new tech' mostly lies.


> They seem to be pushing their ability to more easily move to ASIC
> production, but they seem to offer something to the FPGA only user as
> well. =A0

A key question here will be: if you are unlikely to
need ASIC, why start with their devices ?

> I'm not clear on what you are saying about this in regards to Tier Logic.

 It was a general comment, about where there is space for new-comers,
or new-products in the market.

 I've often found RAM dictates the Device choice, more than the Logic.

-jg

Article: 146282
Subject: Re: Spartan3AN DDR2 - bad writing zeros
From: lusch <lukaszschodowski@gmail.com>
Date: Wed, 10 Mar 2010 14:22:36 -0800 (PST)
Links: << >>  << T >>  << A >>
Yes, the problem was in RS232 :) Actually I don't know why.
I wrote simple module to write data to RS232 from FPGA and problem
appeared when I'd like send "00"

Thanks for cooperation
Luka

Article: 146283
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: rickman <gnuarm@gmail.com>
Date: Wed, 10 Mar 2010 14:29:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 4:54=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Mar 11, 10:41=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 10, 3:14=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
> > > On Mar 11, 8:25=A0am, Symon <symon_bre...@hotmail.com> wrote:
>
> > > > Hi Jeff,
> > > > I've examined all the old FPGAs I've found in my office, and they a=
ll
> > > > seem to have three dimensions already. Even the old ones from 1986.
>
> > > Hehe ;) - yes, even Tabula are trying to spin 3D too...
>
> > > =A0Still, getting back to the site itself, it seems they
> > > have a Stacked-die prototype path, and the main thrust is really mask=
-
> > > asic.
>
> > > =A0The stacked die 'emulation devices' will come at a large price
> > > premium, and their config density will need to be low (given this is
> > > top-layer stuff).
> > > I'd expect a power premium too...
>
> > Stacked die? =A0I read the eetimes article and didn't get anything abou=
t
> > stacked die from Tier Logic. =A0Did I read something wrong? =A0I though=
t
> > they were layering TFT on top of the base die to provide the config
> > memory which takes it out of the base die saving real estate.
>
> Yes they are, which is why I called it stacked die.
> - TWO die flows, one on top of the other.
>
> =A0Base die is made, and then they have a second die-process that is
> more complex than just TFT, as it
> included connections. [Testing questions remain?]
>
> =A0That will also be why they needed a lot more passes at the TFT
> section, as that's where the 'new tech' mostly lies.

Uh, "stacked die" is normally used to refer to putting two distinct
die mechanically on top of each other.  That is a very different thing
than adding processing steps to an existing flow, which is what has
been described for this part.


> > They seem to be pushing their ability to more easily move to ASIC
> > production, but they seem to offer something to the FPGA only user as
> > well. =A0
>
> A key question here will be: if you are unlikely to
> need ASIC, why start with their devices ?

They claim an advantage in die size which normally translates into a
cost advantage.  Of course, the question of cost will be answered when
they start shipping product, or at least quoting prices.


> > I'm not clear on what you are saying about this in regards to Tier Logi=
c.
>
> =A0It was a general comment, about where there is space for new-comers,
> or new-products in the market.
>
> =A0I've often found RAM dictates the Device choice, more than the Logic.

I wish I had that luxury.  For me it is typically package since my
designs tend to be size constrained; low pin count (100 or less) in
PCB layout and manufacturing friendly packages are always welcome
(read that as TQFPs or possibly QFNs).  Right now I am trying to
squeeze 10 pounds of logic into a 5 pound FPGA because it was the only
one that fit the bill, a bill that was designed a year and a half
ago.

Rick

Article: 146284
Subject: Re: Spartan3AN DDR2 - bad writing zeros
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 10 Mar 2010 22:35:28 GMT
Links: << >>  << T >>  << A >>
lusch <lukaszschodowski@gmail.com> wrote:

>Yes, the problem was in RS232 :) Actually I don't know why.
>I wrote simple module to write data to RS232 from FPGA and problem
>appeared when I'd like send "00"

Probably a getchar() / C style strings problem.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 146285
Subject: Re: Spartan3AN DDR2 - bad writing zeros
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 10 Mar 2010 15:06:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 2:22=A0pm, lusch <lukaszschodow...@gmail.com> wrote:
> Yes, the problem was in RS232 :) Actually I don't know why.
> I wrote simple module to write data to RS232 from FPGA and problem
> appeared when I'd like send "00"
>
> Thanks for cooperation
> Luka

I think previously you said that you were using a displaying the
result in HEX in your terminal program.  Gabor pointed out that RS-232
would ignore 00 unless you were in binary (vs ascii) mode.  Your reply
here wasn't

The value 00 is the same as 0 which is also NULL or end-of-string in C
software.  You haven't said how the value is sent to the RS-232 port,
but if you were using MicroBlaze and printf think that this could be
getting swallowed by the software routine.

In order to separate the issue between the Memory read/write and the
RS-232 transmit.  I would suggest that you change your design to
simple write a number of zero and non-zero values to the RS-232 and
see if these appear correctly in your RS-232 terminal.

Ed McGettigan
--
Xilinx Inc.

Article: 146286
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Wed, 10 Mar 2010 15:14:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 11:29=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 10, 4:54=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> > Yes they are, which is why I called it stacked die.
> > - TWO die flows, one on top of the other.
>
>
> Uh, "stacked die" is normally used to refer to putting two distinct
> die mechanically on top of each other. =A0

 That depends on where you are in the time-line :)

Years ago, 'stacked die' meant post-wafer assembly using bond-wires &
discrete die, but more modern "nailed stacked die" schemes use vias,
and are done at the wafer level.

ie See this fig2 of "nailed stacked die " here :
http://www.flipchips.com/tutorial71.html

and compare with the image here :

http://www.tierlogic.com/uploads/press-room-files/Tier-Logic-Cross-Sections=
-of-TierFPGA-and-TierASIC-Devices.pdf

 The 'different process', and multiple Transistor planes, is now more
a distinguishing feature, than a literal interpretation of 'die'.

Tierlogic are quite clear they use Stacked (different) processes, and
via type contacts.

 Doing the stacking at the wafer/fab level saves handling, but you are
exposed to testing issues.

 Until you have finished the two-process flows, you really have
nothing to test. So yields are ??

 Default TFT flows are also higher voltage, and relatively coarse
grained.
 So the bit-counts will be interestng to see, when
they are finally revealed.

-jg

Article: 146287
Subject: Re: Translate Error: ngd build 604
From: Alan Fitch <apf@invalid.invalid>
Date: Wed, 10 Mar 2010 23:30:58 +0000
Links: << >>  << T >>  << A >>
On 10/03/10 14:55, Pallavi wrote:
> Hi, I'm doing this project using ISE 9.2i and am getting the ngd build
> error: 604 during translation. Can anyone please let me know how to resolve
> this error. I'm able to synthesize the code successfully. Thanks.	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Try typing

ngdbuild 604

into Google,

regards
Alan

-- 
Alan Fitch

Article: 146288
Subject: Re: Tabula. (FPGA start up)
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 10 Mar 2010 18:00:06 -0600
Links: << >>  << T >>  << A >>
-jg wrote:
> On Mar 9, 7:25 am, Jon Elson <jmel...@wustl.edu> wrote:
>> -jg wrote:
>> I make a line of products that have multiple quadrature encoder counters
>> in FPGAs.  I've been thinking that due to the digital filtering of the
>> inputs that is required, I could time multiplex the logic of these
>> counters pretty easily and save a bunch of space.  The filtering runs at
>> 1 MHz!  But, I could just as easily figure out how to do this in the HDL
>> of my choice, with just a little thinking.
> 
> If you have spare BRAM, that can easily create many time-sliced
> counters, with a simple add/subt.
> 
> At a guess, a Xmos part could likely manage ~32 x 32 bit quad
> counters, at 1MHz poll rates.
But, you'd QUICKLY run out of I/O pads!  So, such level of multiplexing 
doesn't take much advantage of the possibilities.  If a much larger task 
than quadrature counting was needed, then you'd get a bigger benefit. 
As it is in the project mentioned above, I'm tight on pins with a 
144-pin Spartan 2 FPGA (there's a lot of other stuff on it than the 4 
quadrature counters), but could add a few more counters.

Jon

Article: 146289
Subject: Re: Tabula. (FPGA start up)
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 10 Mar 2010 18:06:35 -0600
Links: << >>  << T >>  << A >>
rickman wrote:

> Multiplexing things like counters is not very efficient because of the
> granularity.  A counter is no more complex in an FPGA than a 2 input
> mux.  If you add a mux to share a counter in two processes you gain
> nothing.
But, if you replace N counters with one adder/subtracter and a BRAM, it 
may well save real estate.  Muxing 2 counters seems pointless, but maybe 
when it gets to replacing 8 counters with one add/sub block it pays off.
Even at 8 units it may just be a lot simpler to leave it dedicated 
hardware.  If I had the I/O lines, I could probably multiplex 40 
counters at 1 MHz to one add/sub running at 40 MHz and save a BUNCH of 
area, but with the index pulse, each counter would take 3 inputs for 120 
pins.  We don't need 40 quadrature counters on one chip, anyway.

Jon

Article: 146290
Subject: Xilinx ISE Webpack Schematics
From: TudaPellini <elpellini@gmail.com>
Date: Wed, 10 Mar 2010 16:23:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi ASICFriends,

I'm using XILINX ISE WebPack, release 8.2 (due to compatibility issues
with older projects).
Does anyone know how to make some symbol inputs to be "don't care"
inside an ISE schematic ? For example, at some mux inputs ? As we can
do on VHDL or Verilog ?
I expect that such issues would allow the synthesis tools to better
optimize the design.
Nowadays I manually tie every unused input to '0' (GND) or '1' (VCC)
sources and the synthesis tool really reduces and optmize the logic as
expected. However, I choose between '1' or '0' by my own analysis.
Is there a way to name these inputs on the schematic as 'X' or
something ?

Greetings to you all
TUDA Pellini

Article: 146291
Subject: Re: Why doesn't this situation generate a latch?
From: Andy <jonesandy@comcast.net>
Date: Wed, 10 Mar 2010 16:25:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > I would strongly encourage you to change the RESET function from
> > > asynchronous to synchronous.
>
> > On what basis do you make this recommendation, and what does this have
> > to do with latches?
>
> > Andy
>
> Synchronous versus asynchronous resets have been discussed at length
> in other threads.
>
> Asynchronous resets have their place in a designer's toolbox, however
> they should be used sparingly. =A0Some reasons to use these are for
> handshakes crossing clock domains, anticipated loss of clock and
> asynchronous inputs to the synchronous domain.
>
> In a synchronous domain, such as the original state machine example,
> the asynchronous functionality offers no additional benefit in FPGAs
> as the area cost is identical for both.
>
> Asynchronously asserting and de-asserting a reset across multiple
> registers may/will result in the registers being released before and
> after a clock edge due to large net delay and skew on the reset net.
> This will result in different parts of a design coming out of reset
> across clock boundaries and being out of sync with each other.
>
> Synchronous resets simplify timing analysis and timing closure without
> having to worry about the consequences of the asynchronous functions
> and how to correctly constrain them.
>
> I often see problems with FPGA designs that are built with
> asynchronous resets, but I have yet to see a problem with a FPGA
> design that was traced to a synchronous reset.
>
> In an FPGA there is no downside to a synchronous reset, but there are
> many pitfalls with an asynchronous reset.
>
> None of this has anything to do with a latch, which you also want to
> avoid using in an FPGA.
>
> Ed McGettigan
> --
> Xilinx Inc.

Given that most sources of reset signals are not already synchronized
to the clock domain(s) that need resetting, both asynchronous and
syncrhonous resets require at least the deasserting edge to be
synchronized. Proper syncrhonization for each case takes the same
amount of design effort and resources.

I will agree that getting the constraints set to make sure that the
synchronous deassertion path meets timing in an asynchronously reset
system can be non-obvious, but that is a tools issue, not a design
issue (in other words, fix the tools!)

Given that an asynchronous reset reliably resets the circuit,
regardless of the presence or stability of the clock signal, when an
asynchronous reset is correctly designed, it is a more reliable reset
than a synchronous one.

Andy

Article: 146292
Subject: Re: Why doesn't this situation generate a latch?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 10 Mar 2010 17:01:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 4:25=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > > I would strongly encourage you to change the RESET function from
> > > > asynchronous to synchronous.
>
> > > On what basis do you make this recommendation, and what does this hav=
e
> > > to do with latches?
>
> > > Andy
>
> > Synchronous versus asynchronous resets have been discussed at length
> > in other threads.
>
> > Asynchronous resets have their place in a designer's toolbox, however
> > they should be used sparingly. =A0Some reasons to use these are for
> > handshakes crossing clock domains, anticipated loss of clock and
> > asynchronous inputs to the synchronous domain.
>
> > In a synchronous domain, such as the original state machine example,
> > the asynchronous functionality offers no additional benefit in FPGAs
> > as the area cost is identical for both.
>
> > Asynchronously asserting and de-asserting a reset across multiple
> > registers may/will result in the registers being released before and
> > after a clock edge due to large net delay and skew on the reset net.
> > This will result in different parts of a design coming out of reset
> > across clock boundaries and being out of sync with each other.
>
> > Synchronous resets simplify timing analysis and timing closure without
> > having to worry about the consequences of the asynchronous functions
> > and how to correctly constrain them.
>
> > I often see problems with FPGA designs that are built with
> > asynchronous resets, but I have yet to see a problem with a FPGA
> > design that was traced to a synchronous reset.
>
> > In an FPGA there is no downside to a synchronous reset, but there are
> > many pitfalls with an asynchronous reset.
>
> > None of this has anything to do with a latch, which you also want to
> > avoid using in an FPGA.
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Given that most sources of reset signals are not already synchronized
> to the clock domain(s) that need resetting, both asynchronous and
> syncrhonous resets require at least the deasserting edge to be
> synchronized. Proper syncrhonization for each case takes the same
> amount of design effort and resources.
>
> I will agree that getting the constraints set to make sure that the
> synchronous deassertion path meets timing in an asynchronously reset
> system can be non-obvious, but that is a tools issue, not a design
> issue (in other words, fix the tools!)
>
> Given that an asynchronous reset reliably resets the circuit,
> regardless of the presence or stability of the clock signal, when an
> asynchronous reset is correctly designed, it is a more reliable reset
> than a synchronous one.
>
> Andy- Hide quoted text -
>
> - Show quoted text -

I wouldn't take it as a given that most resets are not already
synchronized to the clock domains.  Resets are routinely used based on
termination count, end of packet, return to state0 from other states
or invalid states, etc....  All of these cases would be within the
same clock domain.

Placing the onus of creating a reliable design on software tools to
correctly determine the designer's intent for timing paths that are
"non-obvious" is not a working solution IMHO.

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

Ed McGettigan
--
Xilinx Inc.

Article: 146293
Subject: Re: Why doesn't this situation generate a latch?
From: -jg <jim.granville@gmail.com>
Date: Wed, 10 Mar 2010 17:10:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

> The cons of an asynchronous reset significantly outweigh the single
> pro that the reset will occur in the absence of clock.

 For Logic 'buried deep', that would be correct, but
for pin-drive logic, having a defined state BEFORE the clock, can be
quite mission-critical.

 -jg

Article: 146294
Subject: Re: Why doesn't this situation generate a latch?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 10 Mar 2010 17:42:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > The cons of an asynchronous reset significantly outweigh the single
> > pro that the reset will occur in the absence of clock.
>
> =A0For Logic 'buried deep', that would be correct, but
> for pin-drive logic, having a defined state BEFORE the clock, can be
> quite mission-critical.
>
> =A0-jg

I absolutely agree that asynchronous resets have a very valid use in
certain cases.  My position is that should be avoided in the general
case.

FPGAs with the asynchronous global set/reset can also get you into
that known state before any clocks are applied.

Ed McGettigan
--
Xilinx Inc.

Article: 146295
Subject: Re: Why doesn't this situation generate a latch?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 10 Mar 2010 18:44:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 5:42=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
> > On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > The cons of an asynchronous reset significantly outweigh the single
> > > pro that the reset will occur in the absence of clock.
>
> > =A0For Logic 'buried deep', that would be correct, but
> > for pin-drive logic, having a defined state BEFORE the clock, can be
> > quite mission-critical.
>
> > =A0-jg
>
> I absolutely agree that asynchronous resets have a very valid use in
> certain cases. =A0My position is that should be avoided in the general
> case.
>
> FPGAs with the asynchronous global set/reset can also get you into
> that known state before any clocks are applied.
>
> Ed McGettigan
> --
> Xilinx Inc.

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by
a clock enable on a register. "

I am interested in above your comment. Can you list an example to show
"the latch cannot be replaced by
a clock enable on a register"

My opinion is that you never will find an example to support your
claim.

1. Whether generating a latch for a intermediate data or not doesn't
change a state machine's behavior. Do you agree?

2. In a synchronous system, signal's data is valid and used near the
clock triggering edge: between set-up time and hold time. Generating a
latch for intermediate data for a state machine would make system
slower, not faster in any situation.

3. Timing for other signals may be affected, of course.

Weng








Andy

Article: 146296
Subject: Re: Tabula. (FPGA start up)
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 10 Mar 2010 19:08:21 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 7:06=A0pm, Jon Elson <jmel...@wustl.edu> wrote:
>
> But, if you replace N counters with one adder/subtracter and a BRAM, it
> may well save real estate. =A0Muxing 2 counters seems pointless, but mayb=
e
> when it gets to replacing 8 counters with one add/sub block it pays off.
> Even at 8 units it may just be a lot simpler to leave it dedicated
> hardware. =A0If I had the I/O lines, I could probably multiplex 40
> counters at 1 MHz to one add/sub running at 40 MHz and save a BUNCH of
> area, but with the index pulse, each counter would take 3 inputs for 120
> pins. =A0We don't need 40 quadrature counters on one chip, anyway.
>
> Jon

The thing I liked about multiplexing large counters (I had about 7
values I needed to keep track of) was the reduction in readout logic.
If I use a distributed CLB SelectRAM for the count values, I can read
multiple values from the memory without adding (much) readout logic.

In my case, I had 27-bit counters which were only read after the
counting events so the CLB SelectRAM was single port.  Seven 27-bit
counters and associated readout, implemented in around 60 LUTs.  Not
bad.  The "simple" approach would have been about 300 LUTs once
readout is thrown in.

Article: 146297
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Thu, 11 Mar 2010 08:45:07 +0200
Links: << >>  << T >>  << A >>
austin wrote:

> Except you require registration to even see what it is that you have.

At least they don't require NDAs etc. for basic information. I don't
see any problem in registration or even NDAs. A and X also require
NDAs before they tell anything about their future products.

> What are you afraid of?  Competition?

Possibly yes. The big guys are very happy to steal the good ideas of
the smaller ones and use their muscle to push the innovations to
their products, and the original inventor gets nothing (unless
they vere good at patenting it).

> So, until you decide to stop "qualifying customers" I am afraid you
> will remain a relatively unknown company.

A and X qualify also customers for early access etc. And for a small
startup the qualifying is even more important, they don't have the
muscle to support big amount of customers.

> That is OK:  the longer it takes for you to make money, the more
> likely the investors pull the plug, and you go away like all the other
> FPGA companies have in the past.

The money is not in the hobbyist market but on the big accounts. And
big accuounts have no problem with registration, NDAs etc.


--Kim

Article: 146298
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Thu, 11 Mar 2010 08:54:15 +0200
Links: << >>  << T >>  << A >>
-jg wrote:
>  Doing the stacking at the wafer/fab level saves handling, but you are
> exposed to testing issues.
> 
>  Until you have finished the two-process flows, you really have
> nothing to test. So yields are ??

I don't see it impossible to test the cmos wafer before the tft process,
depending on how they constructed the topmost metal layer. For example
they could have some dummy bump pads there for power, and then internal
bist with certain coverage built with the lower metal layers.

FPGAs are quite easy in terms of yield, because you can have redundant
structures for yield improvement (in fabric and in memories).

--Kim

Article: 146299
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: Tier Logic <jeff.kaady@gmail.com>
Date: Wed, 10 Mar 2010 23:41:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 10:54=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> -jg wrote:
> > =A0Doing the stacking at the wafer/fab level saves handling, but you ar=
e
> > exposed to testing issues.
>
> > =A0Until you have finished the two-process flows, you really have
> > nothing to test. So yields are ??
>
> I don't see it impossible to test the cmos wafer before the tft process,
> depending on how they constructed the topmost metal layer. For example
> they could have some dummy bump pads there for power, and then internal
> bist with certain coverage built with the lower metal layers.
>
> FPGAs are quite easy in terms of yield, because you can have redundant
> structures for yield improvement (in fabric and in memories).
>
> --Kim


I don't want to marketeer too much here because this is a technical
site. All I can tell you is that our FPGAs will save you money because
our die size is reduced. If you convert it to our ASIC you will save
even more money for a minimal NRE. ( zero NRE for early access
customers).

I did want to clear up any questions on our testing methodolgies.

Our FPGA is tested the same as any other SRAM based FPGA is tested.
The only difference is that our configuration SRAM is above the CMOS
base layer in a second active layer resulting in a smaller die size.
We test it to 100% functional FPGA test patterns in the same way any
other SRAM-based FPGA is tested. There is no need to test until the
complete FPGA is done being processed.

The TierASIC is tested with a scan-based ASIC methodology we added to
the silicon. The customer is not required to generate any test
vectors. Once you lock your design, you simply send us the bitstream
and we auto generate the test vectors for your ASIC. We create one M9
hard mask and stop there. I do believe that the significant cost
reduction in moving from our FPGA to our ASIC will make it a popular
choice. You also get the advantages of no possibility of configuration
SEUs, bitstream security, no config rom needed, instant on, and
customer logos.

The yield of the ASIC increases over the yield of the FPGA because the
ASIC is only tested to that customer pattern. Also, the timing is
identical to the FPGA version which means zero conversion risk. We can
deliver ASIC samples in about 4 weeks.

Jeff






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