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 146300

Article: 146300
Subject: Re: Spartan3AN DDR2 - bad writing zeros
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 11 Mar 2010 10:36:52 -0000
Links: << >>  << T >>  << A >>
"lusch" <lukaszschodowski@gmail.com> wrote in message 
news:9b933786-e1b2-4648-bdd4-1df24785efcd@33g2000yqj.googlegroups.com...
> 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"

A haaa, so the 1 Pin Interface would have been invaluable, how many hours
did you waste? (Without giving it too hard a sell).


At least the problem isn't FPGA or PCB based!



Nial. 



Article: 146301
Subject: Re: Some Active-HDL questions
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 11 Mar 2010 10:42:35 -0000
Links: << >>  << T >>  << A >>
> Well kiss my grits!  It seems Lattice licensees are second class
> citizens and the accelerated waveform viewer is not available.  No
> wonder I didn't know about it.  The docs say the accelerated viewer is
> the default!


Rick, is that an OEM version you're using, it's fairly standard practice
to have reduced functionality in OEM versions.

Otherwise there would be no incentive to shell out for the full version.

(Although I'm sure you knew that).


Nial. 



Article: 146302
Subject: Re: Why doesn't this situation generate a latch?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 11 Mar 2010 11:48:33 +0000
Links: << >>  << T >>  << A >>
Peter Alfke <alfke@sbcglobal.net> writes:

> 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).

And the Microblaze core uses 3 (yes a whole 3 :) of them as well!

Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 146303
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 11 Mar 2010 06:12:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 1:45=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
>
> big accuounts have no problem with registration, NDAs etc.
>
> --Kim

That's a false assumption.  Even big accounts have individual
engineers who thrive on free flow of information to <b>understand the
technologies to consider in the first place</b>.  There is a tendency
not to look into every company proclaiming new and revolutionary
technology if the information isn't readily available.

Perhaps some engineers are interested in spending the time and hassle
to dig into all the little wannabe startups but there are few that
warrant the all-out risk associated with a new single-source supplier
with no guaranteed future unless the technology is truly superb.  If
the risk is extreme, why look at it in the first place unless it's a
casual 15 minutes of web perusal to understand the claims?

Article: 146304
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 11 Mar 2010 06:32:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 2:41=A0am, Tier Logic <jeff.ka...@gmail.com> wrote:
> 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 =
are
> > > 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

Thanks for returning to talk further about the issues brought up on
this newsgroup.

I wish you success in achieving noticeable market share.

While I can understand the savings brought from removing the
configuration memories and associated die size, I still envision the
FPGA-like overhead as being significant since routing is such a large
portion of typical FPGA resources.  The routing won't go away, only
the configuration memory.  The result is still not an ASIC-killer
unless the price-point for (for instance) 40nm TierASIC devices can
compare at a price point with a couple steps behind in the process
curve.

If a turn on a 90nm or 120nm ASIC can produce similar cost points in
per-piece costs to a TierASIC on the tighter process, there might be
something here.  We all understand the issues of NRE and timing.  But
it's so much smoke and mirrors at this point it's hard for the big
customers who have ASIC suppliers or the medium customers who need to
*work* to get access to information to really consider the technology.

If the TierASIC information becomes more transparent to demonstrate
the true "technical" savings versus the ASIC approach rather than
"marketing" savings, TierASIC won't disturb the engineers responsible
for *considering* the technology in the first place.  Marketing people
tend not to sway engineers with marketing; they tend to influence with
the technology proposition and real associated cost points.

In my mind, it's a question of whether there's a desire to market to
the select few who aren't concerned about risk versus reward within
their company framework or to the many who may see how large the
reward is and how low the risk is in the end.

I want better solutions to succeed.  *I* won't pursue vague promises
but I'll consider real information.  Big difference.

Article: 146305
Subject: Compiling a design in Quartus that doesn't fit
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 11 Mar 2010 15:05:01 GMT
Links: << >>  << T >>  << A >>
I want to be able to generate an encrypted netlist of a core using 
Quartus. Does Quartus have a switch that allows you to compile a design 
that doesn't fit into an FPGA? The issue is that the ports on the core 
exceed the number of pins on any device.  


Article: 146306
Subject: Re: Compiling a design in Quartus that doesn't fit
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 11 Mar 2010 15:25:58 -0000
Links: << >>  << T >>  << A >>
"General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message 
news:7vsf4tFaprU4@mid.individual.net...
>I want to be able to generate an encrypted netlist of a core using
> Quartus. Does Quartus have a switch that allows you to compile a design
> that doesn't fit into an FPGA? The issue is that the ports on the core
> exceed the number of pins on any device.


There are settings to allow you to compile lower level entites for incremental
compilation, although I can't remember what they are.

A quick search shows that 'virtual pin' might be what you're looking for, or lead
in the right direction.


Nial. 



Article: 146307
Subject: fastest multiplier for dsps
From: vineeth sukumaran <vineeth.sukumaran@gmail.com>
Date: Thu, 11 Mar 2010 07:39:09 -0800 (PST)
Links: << >>  << T >>  << A >>
The fastest multiplier in fpga for dsps are designed using a method
using Vedic mathematics technique.. To view tha technology go the iete
journals website..
http://jr.ietejournals.org/downloadpdf.asp?issn=0377-2063;year=2009;volume=55;issue=6;spage=282;epage=286;aulast=Pushpangadan;type=2

http://jr.ietejournals.org/article.asp?issn=0377-2063;year=2009;volume=55;issue=6;spage=282;epage=286;aulast=Pushpangadan;type=0

Article: 146308
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: austin <austin@xilinx.com>
Date: Thu, 11 Mar 2010 08:23:14 -0800 (PST)
Links: << >>  << T >>  << A >>
John,

Correct, you got it.

I was always looking for the best solution when I did my stint as a
design engineer from 1978 to 1998 in telecom.

The last thing on my list was the vendor:  there were many things
ahead of that (although, the vendor, and their history is important,
too).

So, in the telecoms business:  here was my order of importance:

1. Price
2. Price
3. Price.
4. Power:  (yes, even so long ago, telecoms were 'green')
5. Availability:  (if it had the advantages above, I would pre-order,
stock, and do whatever needed to get those advantages)
6. Performance (I would make do with less performance if I had the
advantages above)
7. Reliability:  (I would burn in, re-test, operate at a lower
temperature, if I could get an inexpensive part to meet my 20 year
life requirement)
8. Vendor: (support, applications notes, demo boards, free IP, code,
tools -- I would tolerate a lot missing here to meet the first three
goals)

The bottom line was if I could make an equivalent, or better product,
for a lower cost than my competition, I would get the contract.

I once lost a million dollar contract to MCI being just $0.01 more
expensive on a $125 circuit pack than my competition, so it was (and
still is) a rough real world out there.


So, for those who used to do what I did, log onto their website, give
them the required information, download the information, and get
going.

Austin


Article: 146309
Subject: Re: Compiling a design in Quartus that doesn't fit
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 11 Mar 2010 16:23:27 GMT
Links: << >>  << T >>  << A >>
On Thu, 11 Mar 2010 15:25:58 +0000, Nial Stewart wrote:

> "General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message
> news:7vsf4tFaprU4@mid.individual.net...
>>I want to be able to generate an encrypted netlist of a core using
>> Quartus. Does Quartus have a switch that allows you to compile a design
>> that doesn't fit into an FPGA? The issue is that the ports on the core
>> exceed the number of pins on any device.
> 
> 
> There are settings to allow you to compile lower level entites for
> incremental compilation, although I can't remember what they are.
> 
> A quick search shows that 'virtual pin' might be what you're looking
> for, or lead in the right direction.
> 
> 
> Nial.

Thanks, that sounds like what I want.

Article: 146310
Subject: Re: Why doesn't this situation generate a latch?
From: Andy <jonesandy@comcast.net>
Date: Thu, 11 Mar 2010 09:15:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 7:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> I wouldn't take it as a given that most resets are not already
> synchronized to the clock domains. =A0Resets are routinely used based on
> termination count, end of packet, return to state0 from other states
> or invalid states, etc.... =A0All of these cases would be within the
> same clock domain.

OK, now I see where we're missing each other: in the definition of
what constitutes a reset function. When I say reset, I mean "device
initialization", either upon power up, power failure, BIT failure,
system watchdog event, etc. that resets darn near the whole device.
When you say "reset" you mean anytime the logic loads a zero or other
static value into a counter, etc.

Our best practice policies forbid combining local, functional
"restarts" like you mentioned, with the reset (initialization)
circuit, or from using asynchronous (causal) reset/preset controls for
them. If a register is not reset for initialization, it is acceptable
to use a synchronous reset control on a register for functional
restarts, etc. There are a few cases where asynchronous controls are
acceptable in sync boundaries, etc. but they are subject to specific
review and approval. These "restart" functions are, as you say, often
triggered by synchronous signals anyway, and are part of the
functional nature of the design, not part of the initialization.

But for device initialization, our best practices recommend the use of
asynchronous resets where possible (subject to device support).

> 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.

Why is it not obvious that an output from a same clocked register,
driving an asynchronous reset input to another same-clocked register,
should be checked for the timing relative to that clock? Every
asynchronously reset register still has a setup and hold requirement
for the deasserting edge of that reset input, so check it the same way
you check synchronous inputs (i.e. depending upon the clock domain of
the driven input). You don't even have to check any asyncrhonous paths
through the registers to do this.

Thanks,

Andy


Article: 146311
Subject: Re: Why doesn't this situation generate a latch?
From: Andy <jonesandy@comcast.net>
Date: Thu, 11 Mar 2010 09:29:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> 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"

Example:

A <=3D B when ENABLE; -- implies a latch for A
C <=3D A when rising_edge(CLK); -- a register using A
E <=3D A or D; -- another combinatorial function using A

If not for E, the latch could be replaced by a clock enable on the C
register. I suppose C could still use a clock enable and the B input
directly, but it does not wholly "replace" the latch, because the
latch is still needed to derive E.

Andy

Article: 146312
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 11 Mar 2010 17:59:50 GMT
Links: << >>  << T >>  << A >>
John_H <newsgroup@johnhandwork.com> wrote:

>On Mar 10, 11: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
>>
>> Jeff
>
>Sad.
>
>I have a passing interest in anything proclaiming itself "new" and
>"revolutionary" but I won't bother to register to get more
>information.
>
>I *might* have the next $1M+ design but it will go to standard FPGAs
>because I can't find out about the promising technology on a casual
>basis.

I agree. We use a 1000+ ARM controllers per year. Luminary required
registration so they didn't even make it on the short list.

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

Article: 146313
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Thu, 11 Mar 2010 11:08:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 12, 3:32=A0am, John_H <newsgr...@johnhandwork.com> wrote:
> > 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.

The claim of Auto-generate test vectors is interesting.
Who pays for < 100% coverage 'issues' ?

> While I can understand the savings brought from removing the
> configuration memories and associated die size, I still envision the
> FPGA-like overhead as being significant since routing is such a large
> portion of typical FPGA resources. =A0

 The memory has not gone away, in the FPGA flow is it
merely stacked, so die size has shifted to more process steps. Raw
silicon is actually quite cheap.

 Even in their ASIC flow, that 'memory ghost' remains, as the die size
is locked to the larger of the two possible choices. Their fpga to
asic step saving
is some process steps, testing savings, and yield gains
as they hope you are not using defects.

 Where die size savings really kick in, is when they allow MORE logic
into what is a 'practical size ceiling' - but we still have no
indications of WHO their customers are ? - no logic or package info ?.

 If your package is IO bound, then die size claims are
totally illusory.

-jg

Article: 146314
Subject: Re: Why doesn't this situation generate a latch?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 11 Mar 2010 11:38:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 9:29=A0am, Andy <jonesa...@comcast.net> wrote:
> On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > 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"
>
> Example:
>
> A <=3D B when ENABLE; -- implies a latch for A
> C <=3D A when rising_edge(CLK); -- a register using A
> E <=3D A or D; -- another combinatorial function using A
>
> If not for E, the latch could be replaced by a clock enable on the C
> register. I suppose C could still use a clock enable and the B input
> directly, but it does not wholly "replace" the latch, because the
> latch is still needed to derive E.
>
> Andy

Andy,
We don't argue about the latch replacement as you show. What we argue
about is when a fast next state signal StateA_NS is replaced by a
slower latched version.
It occurs if a condition in an if statement misses a signal assignment
statement as we have been discussing about.

Weng

Article: 146315
Subject: Re: Why doesn't this situation generate a latch?
From: Andy <jonesandy@comcast.net>
Date: Thu, 11 Mar 2010 12:08:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 1:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Mar 11, 9:29=A0am, Andy <jonesa...@comcast.net> wrote:
>
>
>
>
>
> > On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > 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 sho=
w
> > > "the latch cannot be replaced by
> > > a clock enable on a register"
>
> > Example:
>
> > A <=3D B when ENABLE; -- implies a latch for A
> > C <=3D A when rising_edge(CLK); -- a register using A
> > E <=3D A or D; -- another combinatorial function using A
>
> > If not for E, the latch could be replaced by a clock enable on the C
> > register. I suppose C could still use a clock enable and the B input
> > directly, but it does not wholly "replace" the latch, because the
> > latch is still needed to derive E.
>
> > Andy
>
> Andy,
> We don't argue about the latch replacement as you show. What we argue
> about is when a fast next state signal StateA_NS is replaced by a
> slower latched version.
> It occurs if a condition in an if statement misses a signal assignment
> statement as we have been discussing about.
>
> Weng- Hide quoted text -
>
> - Show quoted text -

I'm not sure why you are concerned about this. Everyone seems to agree
that inferring latches is not a good idea. The fact that it slows
performance (at least in FPGA's, see below) is just one more reason to
avoid them.

It just so happens that in FPGAs, the clock enable mux is always there
on the front of the flip-flop, so there is no timing penalty whether
you actually use it or not, and adding a latch in front of it is
always slower.

In other technologies, you have a choice of having a clock enabled or
regular flip-flop, with the latter being faster. Now the question is,
in such a technology, is the latch plus regular flop faster than the
clock enabled flop?

Andy

Article: 146316
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: Tier Logic <jeff.kaady@gmail.com>
Date: Thu, 11 Mar 2010 12:19:45 -0800 (PST)
Links: << >>  << T >>  << A >>
The extra processing steps for the TFT do cost more. However, the die
size reduction swamps that out to create a low cost FPGA. The ASIC
gets rid of that extra cost and benefits from the yield improvement
for an even lower cost solution.

All I can tell you is come get a quote and we can save you money.
Xilinx and Altera love all the skepticism here and want you to
conitnue paying too much for your solutions.

Regards,

Jeff

Article: 146317
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: whygee <yg@yg.yg>
Date: Thu, 11 Mar 2010 22:31:42 +0100
Links: << >>  << T >>  << A >>
Hello,

Tier Logic wrote:
> All I can tell you is come get a quote and we can save you money.
it is a curious statement !
I assume that you have been too long in "stealth mode".

Now I tell you this :
"show me your public price list, your products,
demo boards, detailed datasheet and distributors.
Then maybe I'll choose you for a project".

I'll take the example of a competitor.
SiliconBlue has maybe "slow" chips
(according to only one test I did) but they got
it almost right for the rest, at least for me :
  - decent development tool (not bloated)
     that installs easily on Linux AND Windows !
  - datasheet and other informations, enough to understand
     how it is ticking inside so it can be used
  - at least one distributor that talks to anyone
     (even though the distributor is not large,
      at least it does its job and doesn't scare potential customers)
  - unit price that is decent is small quantities.
  - ultra-low power is a plus but not critical for me.

And still it's not functional enough for me.
Antti has developped for it and I'm curious.
Now before you can save me money, try to beat SBt,
and then... beat the others :-P
The Actel ProAsic3 family is working very fine
for me and wonder how it can be displaced.

good luck,

> Regards,
> Jeff
yg

-- 
http://ygdes.com / http://yasep.org

Article: 146318
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: Raymund Hofmann <info2@rayed.de>
Date: Thu, 11 Mar 2010 13:37:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On 11 Mrz., 21:19, Tier Logic <jeff.ka...@gmail.com> wrote:
> The extra processing steps for the TFT do cost more. However, the die
> size reduction swamps that out to create a low cost FPGA. The ASIC
> gets rid of that extra cost and benefits from the yield improvement
> for an even lower cost solution.
>
> All I can tell you is come get a quote and we can save you money.
> Xilinx and Altera love all the skepticism here and want you to
> conitnue paying too much for your solutions.

Isnt the biggest area in FPGAs covered by routing (lines & switches)
which are still present in Tier Logic?

Anyway it looks interesting to me and i have registered to evaluate
further...

But one thing i am concerned with is design security of the
programmable devices.

Article: 146319
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 11 Mar 2010 13:40:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 11, 12:19=A0pm, Tier Logic <jeff.ka...@gmail.com> wrote:
>
> Xilinx and Altera love all the skepticism here and want you to
> conitnue paying too much for your solutions.
>
> Regards,
>
> Jeff

Jeff, you should be ashamed of that cheap shot, especially when Austin
earlier today invited the audience to check out your alleged lower
prices.
I can understand when a newcomer is aggressive in his claims, and
nebulous in his explanations. But do not get sarcastic and nasty.
You still have a lot to prove before you can climb on a high horse.
Peter Alfke


Article: 146320
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Thu, 11 Mar 2010 14:22:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 12, 9:19=A0am, Tier Logic <jeff.ka...@gmail.com> wrote:
>
> All I can tell you is come get a quote and we can save you money.
> Xilinx and Altera love all the skepticism here and want you to
> conitnue paying too much for your solutions.

 So you have real, shipping silicon ? Great!

You claim 'we can save you money', Great too!!
- I love a clairvoyant supplier, who knows already
what packages and prices points I have!!.

- now tell me what packages, speeds and logic counts
you offer, as before I can _actually_ 'save money' here in the real
world, first the product actually has to be functional in a circuit
board that I can sell !!

-jg


Article: 146321
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: -jg <jim.granville@gmail.com>
Date: Thu, 11 Mar 2010 14:25:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 12, 10:31=A0am, whygee <y...@yg.yg> wrote:
> I'll take the example of a competitor.
> SiliconBlue has maybe "slow" chips
> (according to only one test I did)....
> The Actel ProAsic3 family is working very fine
> for me and wonder how it can be displaced.

We have ProASIC3 and SiliconBlue on a short list.
[maybe SmartFusion too, depends on $/package choices]

I'm interested in how much slower were the SiliconBlue devices ?
What tests did you do to compare them ?

-jg

Article: 146322
Subject: Re: Tier Logic introduces the world's first 3D FPGA
From: whygee <yg@yg.yg>
Date: Thu, 11 Mar 2010 23:31:42 +0100
Links: << >>  << T >>  << A >>
-jg wrote:
> On Mar 12, 10:31 am, whygee <y...@yg.yg> wrote:
> We have ProASIC3 and SiliconBlue on a short list.
> [maybe SmartFusion too, depends on $/package choices]
wait a bit before things stabilize
and the distributors sing to the same tune.

I met Future and Actel France
today at the annual parisian Actel seminar,
I was not interested by their new offering,
I'm waiting for an eventual next generation with
a better SRAM/logic ratio.

> I'm interested in how much slower
 > were the SiliconBlue devices ?
> What tests did you do to compare them ?
disclaimer : I'm not as good as Antti ;-)
HE has the boards and can tell more acurate
stories than mine.

I "only" installed their SW, and tried to
compile a simple adder design, probably
http://yasep.org/VHDL/asu_rop2/testdiff.vhd (test nr 1)
http://yasep.org/VHDL/asu_rop2/ASU_ROP2_16.vhd
and got such a low MHz rating that I thought
that I hit the wrong button or something like that.
I tweaked many stuff and could not influence
the result much, tried different architectures...
and I gave up.
It just means that it did not meet my expectations.
I know that SBt's chips are created for ultraultralow power
and low speed. I'm not expecting Virtex performance
but i'm demanding anyway ;-)

If you want acurate figures, I prefer that you
try yourself, because i'm not sure why it is slow.
i've read "80MHz performance" or something like that
in the datasheets at the time
but like other FPGA claims, i'm not able to reach them.
I've seen people able to do about 300MHz designs
with ProASIC, I can only do 100MHz and Actel's
soft ARM maxes at around 60MHz... for a chip that
is meant to be "able of 350MHz".

so test yourself :-)

> -jg
yg

-- 
http://ygdes.com / http://yasep.org

Article: 146323
Subject: Comparing FPGA with ASIC implementations
From: Marcus <MJones@hotmail.com>
Date: Fri, 12 Mar 2010 00:55:39 +0000
Links: << >>  << T >>  << A >>
Hi all,

I just wanna get some feedback if I understood this correctly:

Althoug there is something out called gate-equivalent, it essentially
does not make sense to compare FPGA with ASIC implementations. The 
reason is that ASICs actually require one gate for each logical 
operation in a logical expression. For instance, d = a AND b OR c
requires two logical gates. In contrast, on FPGAs there are LUTS
that permit to implement any complex expression with up to 4 inputs
that do not produce more than 1 output. So that is basically the
reason why this gate-equivalent metric is not accurate since we
can never be sure how many logical expression are combined in a LUT.

Does this argumentation make a bit of sense?

Thanks

Article: 146324
Subject: Re: Comparing FPGA with ASIC implementations
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Thu, 11 Mar 2010 17:06:02 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Mar 2010 00:55:39 +0000
Marcus <MJones@hotmail.com> wrote:

> Hi all,
> 
> I just wanna get some feedback if I understood this correctly:
> 
> Althoug there is something out called gate-equivalent, it essentially
> does not make sense to compare FPGA with ASIC implementations. The 
> reason is that ASICs actually require one gate for each logical 
> operation in a logical expression. For instance, d = a AND b OR c
> requires two logical gates. In contrast, on FPGAs there are LUTS
> that permit to implement any complex expression with up to 4 inputs
> that do not produce more than 1 output. So that is basically the
> reason why this gate-equivalent metric is not accurate since we
> can never be sure how many logical expression are combined in a LUT.
> 
> Does this argumentation make a bit of sense?
> 
> Thanks

It's not even as simple as that.  While you could design that
combinational circuit as a casacade of two logic gates, you could also
roll it into a 3-input compound gate and save a couple of transistors.
Then if the output could stand inversion, you'd save a couple more by
making your output D# instead of D.  That's assuming that everything
remains CMOS; if you needed to really get aggressive you could play
tricks with dynamic logic that you just can't do in an FPGA.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order



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