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 65175

Article: 65175
Subject: MACH5 eval board - doc needed
From: widlicka@maple.cb.att.com (Bob Widlicka)
Date: 21 Jan 2004 18:53:01 GMT
Links: << >>  << T >>  << A >>
I am looking for documentation for a MACH 5 evaluation/demo
board I have. This board was made by AMD. 

The only printing on the board (beside component reference
designators) is the words "Advanced Micro Devices" in the top
left corner, and the words "MACH 5, 160 I/Os, DEMO BOARD," on
the left side toward the middle. The board contains a socket for
a 208 PQFP MACH device. It also has a reset switch, connectors
for JTAG IN and JTAG OUT, a reset switch, 4-bit DIP switch,
and 4 large 7-segment LEDS. On each of the 4 sides of the
208-pin socket are 42 header posts for I/O connections to
the MACH 5 part.

Any documentation (or pointers to doc) would be appreciated. 
I would like to use this board for some prototyping
and perhaps as a learning aid for some high school students.
I don't want to throw it out. Help!

Thanks,
Bob Widlicka
Lucent Technologies
widlicka@lucent.com

-- 


Article: 65176
Subject: Re: OT: liability insurance
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 Jan 2004 14:01:03 -0500
Links: << >>  << T >>  << A >>
$500/yr sounds like Commercial General Liability, which basically protects
you if a customer hurts himself on your premises.  It doesn't generally
provide any coverage for your product, in other words O&E.  My O&E runs
about $6000/year, and is through a different insurer than my CGL.  There are
relatively few carriers that offer O&E, and you'll likely be locked out of
it for certain products like medical instruments and nuclear controls.

Robert Sefton wrote:

> I'm a consultant/contractor. A new customer is requiring me to carry
> commercial general liability coverage, including contractual liability
> (errors and omissions). I carried a $1M policy from Hartford for several
> years, but let it lapse in '02 after customers quit insisting on it. I
> paid $500/yr back then. Any recommendations, and what should I expect to
> pay? I'm in California.
>
> Thanks,
>
> Robert
> (real email: rsefton@nextstate.com)

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 65177
Subject: Re: WTD: info on AMD palce22v10
From: Ralph Malph <noone@yahoo.com>
Date: Wed, 21 Jan 2004 14:07:00 -0500
Links: << >>  << T >>  << A >>
Raivo Nael wrote:
> 
> I too think that FPGA-s in small packages would be great things. I
> also think that this secrecy politics that programmable logic
> manufacturers use, has made FPGA very imaginationless component. Look
> at microcontrollers, how many different packages, architectures and so
> on. And hunderds of different manufacturers.


That is a good point, that MCUs and FPGAs seem to be handled very
differently in the market place.  I have seen several startup FPGA
companies look good and then fail.  This even includes large companies
like Motorola.  They talked about an FPGA line using the "Pilkington"
architecture and came very close to introduction before they shut it
down.  I never did hear anything about why they turned it off.  

I expect that there is a bit more NRE and maintenance for FPGA products
than there is for an MCU line.  I can't really rationalize this other
than to say that FPGA software seems to require constant upgrades while
most MCU compilers are supported by a smaller team that mostly does
minor upgrades and bug fixes.  Am I off base on this?  
I would also say that they seem to make more changes to FPGAs when they
introduce a new family than they typically do when they come out with a
new MCU family member.  Maybe that is it?  MCUs normally have a new
family member, while FPGAs get entirely new families.



Article: 65178
Subject: Re: Hardware to test (FPGA-based) prototype?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 Jan 2004 14:12:53 -0500
Links: << >>  << T >>  << A >>
FPGAs offer an unprecedented tool in design verification: reconfiguration.  If
done carefully, one can completely isolate the board level testing from the
FPGA guts testing when the FPGA is used as some sort of data processor.  For
example, if the FPGA is interfacing memory, you can make a fairly simple FPGA
build to test the memory using your FPGA memory interface a test pattern
generator and a test pattern checker.  Such a tester can test the memories much
more completely and under more stringent conditions than any other method of
testing.  When there are multiple memories, for example, the FPGA can test all
in parallel using worst case patterns.  If the memory passes with tht test, it
will likely not fail in normal use.  Likewise, the interface pieces can be
tested without the rest of the FPGA guts, and interfaces exercised much harder
than they might be in normal use.  Take advantage of the FPGA's
reconfigurability to check out your board level design and your FPGA interfaces
to that design.  Once those are debugged, then getting it all to play together
is not hard if you've simulated the pieces and have done your homework on the
timing.  I discuss this approach with considerably more detail in my paper "An
FPGA Based Processor Yields a Real Time High Fidelity Radar Environment
Simulator", which is available for download from my website at no charge.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 65179
Subject: Re: Tristate buffer
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 21 Jan 2004 11:49:07 -0800
Links: << >>  << T >>  << A >>
Tobias, let me assume that your microcontroller is outside the FPGA, and
has a bidirectional data connection to I/O pins of the FPGA.
Inside the FPGA you now have data input lines coming from the input
buffer, and data output lines going to the output buffer, and a 3-state
control that makes sure you are not driving the outputs while you are
receiving data.
You see that the external 3-state functionality can never be carried
through the I/O into the FPGA. (That is inherently impossible because
the input buffer has amplification, and the output buffer, too. ) Inside
the FPGA you now have two sets of lines, one set is input and the other
one is output. You can then route them to the appropriate pins on the BlockRAM.

3-state drivers are used to send data onto a common output, just by
wiring the drivers together. This assumes that only one of them is
active at any specific time. But if you know which one is active, you
could have ( and you will most of the time) implement this with a multiplexer.

TTL circuits existed for almost 10 years, until NSC invented the
"Tristate" output in the early seventies. I "invented" it a few months
too late :-(
Hope this explains it, otherwise you can contact me directly, even in
German (I got my degree from your neighboring TU in Hannover)

Peter Alfke
===================================


Tobias Moeglich wrote:
> 
> I can't see the coherence between a 3-state-buffer for a bus and a
> multiplexer.
> What I want to design is following:
> 
> The data bus of  a microcontroller shall be connected to a true dual port
> RAM of the Spartan-IIE.
> The dual port RAM (generated by the CoreGenerator) has an input port (dina)
> and an output port (douta)
> because the data port  of the DPRAM is not bidirectional. So I try to put a
> 3-state buffer between the
> data port lines of the controller and the data output port of the DPRAM
> (douta).
> The pins of the input port of the DPFRAM (dina) can be connected directly
> with the data lines of the controller.(??)
> I think this should work. Or?
> But how to implement it? How is it expressed  in VHDL?
> 
> What has a 3-state-buufer to do with a multiplexer?
> A multiplexer always chooses one out of 4,8, 16 (what ever) lines and
> directs it with the output of the mux.
> Isn't that the way a multiplexer works?? I thought so.
> How can I use a mux instead of a 3-state buffer ??
> 
> Greatings, Tobias.



Article: 65180
Subject: Re: WTD: info on AMD palce22v10
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 21 Jan 2004 12:09:37 -0800
Links: << >>  << T >>  << A >>

Ralph Malph wrote:
> 
>   I have seen several startup FPGA
> companies look good and then fail.  This even includes large companies
> like Motorola. 

Here is a partial list of major companies that introduced FPGAs, and
then gave up:

Motorola (never got out of the starting gate, relied on external software...)
Intel (sold it to Altera, who then canned it quietly)
NSC (disappeared quietly)
AMD (sold it to Lattice)
ATT (sold it to Lattice)
T.I. ( stopped being second source to Actel)
Toshiba (never really made it) 
Cypress (?)

The moral of the story is that you survive as an FPGA manufacturer only
when you are totally dedicated to that product line, which is true for
Xilinx, Altera, Lattice, Actel, Quicklogic and some small start-ups.
The Big Guys usually find it easier to make their money on other products.

Peter Alfke

Article: 65181
Subject: Soft failures (?) 9536XL
From: "Josep Duran" <j.duran@nospamteleline.es>
Date: Wed, 21 Jan 2004 21:18:23 +0100
Links: << >>  << T >>  << A >>
I have a small circuit using the 9536XL CPLD. The complete machine uses
64 of such circuits. I have tested it on the lab and everything works just
fine.

The problem is the other day, while at the client premises, I saw something
wrong
with one of the boards. The CPLD stopped responding to the commands sent by
the computer. As I had no test equipment available, I just tried to send
some reset
commands to the board and get no response. I  turned power off to change the
board, but just before replacing it I gave it another try. To my surprise,
everything worked fine this time. I did some intensive testing to the board,
and again
everything went OK.

To me, it looks like the CPLD lost its configuration.
Is this at all possible ? If so, what can I do to prevent this from
happening ?
Anybody seen something like this before ?


NB - it is a 2 layer board (no GND plane) about 3 sq inches.


Thank you for your time.

 Josep Duran



Article: 65182
Subject: Re: Altera/Xilinx Distributor in Europe?
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Wed, 21 Jan 2004 20:23:33 -0000
Links: << >>  << T >>  << A >>

Patrick Birger <bread_pitt@web.de> wrote in message
news:4454c7b.0401201545.1341dbc4@posting.google.com...
> Rene Tschaggelar <none@none.none> wrote in message
news:<22121bd70e95748cc78f4729260a05bb@news.teranews.com>...
> >
> > have a look at http://www.ebv.com for the Altera parts.
>
> Thanks for the address. I've called them: same problem as with
> "Spoerle"
> 1. They only sell to companies, not to private persons.
> 2. Their minimum package quantity is in general 30-90. But I don't
> want to order some 50 FPGAs, 10$ each.
> Is it impossible to buy a single altera FPGA chip without founding a
> company??

Patrick, have you tried Arrow?

I'm sure I bought components off them on a personal
credit card a few years ago (before starting NSD Ltd).

Nial Stewart

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
Cyclone based 'Easy PCI' eval board
www.nialstewartdevelopments.co.uk




Article: 65183
Subject: Re: OT: liability insurance
From: "Robert Sefton" <rsefton@abc.net>
Date: Wed, 21 Jan 2004 14:32:49 -0800
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message
news:400ECC6F.CF29C15D@andraka.com...
> $500/yr sounds like Commercial General Liability, which basically
protects
> you if a customer hurts himself on your premises.  It doesn't
generally
> provide any coverage for your product, in other words O&E.  My O&E
runs
> about $6000/year, and is through a different insurer than my CGL.
There are
> relatively few carriers that offer O&E, and you'll likely be locked
out of
> it for certain products like medical instruments and nuclear controls.
>

Blake, Ray -

Thanks. Obviously I didn't carry the O&E coverage before. I did the
minimum that a customer back then required. The new customer is
specifically asking for O&E (the contract calls it "Contractual
Liability" coverage). Another $6k - sweet. I love spending money on
insurance almost as much as paying taxes.

Robert



Article: 65184
Subject: Re: Tristate buffer
From: Paulo Dutra <paulo.dutra@xilinx.com>
Date: Wed, 21 Jan 2004 14:40:51 -0800
Links: << >>  << T >>  << A >>
dinb <= data_DSP when (CS = '0') else (others => 'Z');

You still express MUX logic in VHDL as you do for tri-state inference.
The synthesis tool automatically maps the tri-states to
muxes in hardware. As peter pointed out, the tri-state hardware
capability doesn't exist in the FPGA's CLB fabric.

Tri-states can be thought of as a fully-decoded muxes. In other
words, the tri-state enable signal selects which of the drivers
has control of the bus. Thus, synthesis tools map the tri-state
enable lines to the select lines for the muxes.

There's a good book, "Essential VHDL - RTL synthesis done right"
by Sundar Rajan that talks about writing VHDL for FPGA fabric. The
author uses synplify as the example synthesis engine. There's a
discussion of hardware creation that talks about the tri-state to
mux mapping performed by synthesis tools.



> What has a 3-state-buufer to do with a multiplexer?
> A multiplexer always chooses one out of 4,8, 16 (what ever) lines and
> directs it with the output of the mux.
> Isn't that the way a multiplexer works?? I thought so.
> How can I use a mux instead of a 3-state buffer ??
> 
> Greatings, Tobias.
> 


-- 
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ `  Xilinx                              hotline@xilinx.com
/ /    2100 Logic Drive                    http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA

Article: 65185
Subject: map gives yet another error!
From: nachikap@yahoo.com (Nachiket Kapre)
Date: 21 Jan 2004 14:47:13 -0800
Links: << >>  << T >>  << A >>
I get the following error while doing map on my design

--------------------------------------------------------------
this is what echoes on the terminal...
"Found an unexpected XMODULE_CELLTYPE property on frag"

--------------------------------------------------------------
this is what is seen in the mrp file?
WARNING:MapLib:328 - Block abcd_inst is not a recognized logical
block. The mapper will continue to process the design but there may be design
problems if this block does not get trimmed.

any help is appreciated.
nachiket.

Article: 65186
Subject: Synthesis errors?
From: "Ken Morrow" <junk@not_morro.co.uk>
Date: Wed, 21 Jan 2004 22:51:42 -0000
Links: << >>  << T >>  << A >>
Hi,

I have recently had lots of incorrectly synthesised logic with the
synthesiser I am using.
My latest design occupied approx 20% of a "6 million gate" FPGA, and had a
total of 5
incorrectly synthesised parts (which took some finding).

Can anyone recommend any synthesisers which do not suffer from this sort of
problem?

The synth takes approx 1 hour to synth this (much quicker than most of my
"large" designs), and timing far
exceeds the requirements as the clock frequency is low.

If anyone is interested, the sort of errors I was getting were:-

A connection between 2 components was simply not made. An input to the
second component was hardwired to '0'.
Tried the very latest version of the same synth and the problem went away.

The following problems were seen in the latest version:-

OUT_DATA <= IN_DATA & "0";
synthesised to
OUT_DATA <= "0" & IN_DATA;
put this in a clocked process and it synthesised correctly.

OUT_DATA <= 2**IN_DATA;
had OUT_DATA(0) hardwired to '1'.
replaced with a case statement and it synthesised correctly

if X = -1 then
  OUT_DATA <= IN_DATA;
elsif X= 1 then
  OUT_DATA <= 0 - IN_DATA;
elsif X=0 then
  OUT_DATA <= 0;
else
  OUT_DATA <= 0 - IN_DATA;
end if;
had OUT_DATA=0 when X=-1
put calculation of 0 - IN_DATA in a separate clocked process, and it
synthesised correctly.


An inferred ROM which synthesised correctly in an earlier version of the
synthesiser, now infers a ROM filled with zeros.
I worked around this by adding a reset to cause the ROM function to be built
from logic. This greatly increased
the size, but this is not a problem for the particular design.

I tried synthing the rogue pieces of code standalone, and they were synthed
correctly (apart from the ROM).

Thanks,

Ken,
Morrow Electronics Limited,
Milton Keynes,
UK.

kenm@morro.co.uk without the m after my name otherwise it will not be
delivered.




Article: 65187
Subject: Re: changing values in a fifo
From: "Patrick Klacka" <pklacka@trexenterprises.com>
Date: Wed, 21 Jan 2004 23:03:23 GMT
Links: << >>  << T >>  << A >>
Thank you everyone for your suggestions thus far. It's clear that more
details are needed in order to better explore this problem. Please see
http://www.trexenterprises.com/~pklacka/fifo.html for implementations in C
code.

It seems that all the solutions favor one change to a particular value, but
do not consider the case of the changed value being changed. For example,
the value of 5 is changed to 6. Now a 5 is retrieved from the fifo. We know
through the Blake's CAM implementation and Jim's SyncRAM implementation that
the value of 5 will be transformed to a 6. Now the 6 is changed to a 7. When
we retrieve a 6 from the fifo, we get a 7 as intented. But should a 5 come
off the fifo, we still get a 6, unless some sort of recursion is used. The
recursion is what I am attempting to avoid. If all the 5's in the fifo could
be changed to 6's before the 6's get changed to 7's, then I have a working
solution.

Here is another idea that may be impossible to implement, but it might shed
some more light on what I am trying to achieve. Consider a full fifo that
expects a value to be inserted every time you remove a value. So there is a
constant flow from one side to the other. (I think this was correctly
likened to a vector shift-register) Could there be another fifo of the exact
same length that flowed in the opposite direction which contains the compare
and the change values. Each time a new value is inserted/removed from the
primary fifo, the secondary fifo compares register values at the same
location in the primary fifo, makes the appropriate change if necessary,
then shifts itself with a new value. Using this idea, all of the 5's will be
changed to 6's before the 6's get changed to 7's, but I think it uses the
same amount of resources as my original solution.



Article: 65188
Subject: Re: Soft failures (?) 9536XL
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 21 Jan 2004 17:15:38 -0800
Links: << >>  << T >>  << A >>
The XC9536XL is a Flash-based CPLD.  Different from an SRAM-based FPGA,
you do not reconfigure it just by cycling Vcc. The CPLD would need a
fresh in-system programming operation, which is not automatic nor
happens by accident.
So, what might have happened is that your design got into an illegal
state, out of which it cannot excape, but which did not affect the configuration.

A more far-fetched explanation is based on the fact that a small part of
the Flash-based configuration actually gets transferred into internal
latches (like in an FPGA), which of course might get upset, and that
would be fixed by cycling Vcc.
All CPLD manufacturers use this convenient mechanism, but hardly anybody
talks about it, since it creates the impression of "volatility"...

Peter Alfke
===================================
Josep Duran wrote:
> 
> I have a small circuit using the 9536XL CPLD. The complete machine uses
> 64 of such circuits. I have tested it on the lab and everything works just
> fine.
> 
> The problem is the other day, while at the client premises, I saw something
> wrong
> with one of the boards. The CPLD stopped responding to the commands sent by
> the computer. As I had no test equipment available, I just tried to send
> some reset
> commands to the board and get no response. I  turned power off to change the
> board, but just before replacing it I gave it another try. To my surprise,
> everything worked fine this time. I did some intensive testing to the board,
> and again
> everything went OK.
> 
> To me, it looks like the CPLD lost its configuration.
> Is this at all possible ? If so, what can I do to prevent this from
> happening ?
> Anybody seen something like this before ?
> 
> NB - it is a 2 layer board (no GND plane) about 3 sq inches.
> 
> Thank you for your time.
> 
>  Josep Duran

Article: 65189
Subject: Re: OT: liability insurance
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 Jan 2004 21:59:30 -0500
Links: << >>  << T >>  << A >>
Thing about O&E is you more or less have to keep it in force once you have
it too.  It usually is issued on a claims made basis, so it only protects
you for claims made while the policy is in effect, if you do work while
under the policy, then drop the policy and then the customer sues you after
the policy coverage is gone, it doesn't cover the work even though it was
done while the policy was in effect.  THe coverage is expensive, but I
wouldn't want to be without it if a claim was ever made.   It's a cost of
doing business, it's tax deductable, and it is a relatively small cost
compared to the taxes, salary, pension, tools & equipment that go with the
territory if you are serious about this business.

Robert Sefton wrote:

> "Ray Andraka" <ray@andraka.com> wrote in message
> news:400ECC6F.CF29C15D@andraka.com...
> > $500/yr sounds like Commercial General Liability, which basically
> protects
> > you if a customer hurts himself on your premises.  It doesn't
> generally
> > provide any coverage for your product, in other words O&E.  My O&E
> runs
> > about $6000/year, and is through a different insurer than my CGL.
> There are
> > relatively few carriers that offer O&E, and you'll likely be locked
> out of
> > it for certain products like medical instruments and nuclear controls.
> >
>
> Blake, Ray -
>
> Thanks. Obviously I didn't carry the O&E coverage before. I did the
> minimum that a customer back then required. The new customer is
> specifically asking for O&E (the contract calls it "Contractual
> Liability" coverage). Another $6k - sweet. I love spending money on
> insurance almost as much as paying taxes.
>
> Robert

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 65190
Subject: Re: WTD: info on AMD palce22v10
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 Jan 2004 22:09:44 -0500
Links: << >>  << T >>  << A >>
Atmel  .. still in it, but I still can't figure out why
Dynachip .. got as far as producing silicon before dying
Gatefield ..  sold to was it Actel?
Concurrent Logic ..  became the Atmel/NSC architecture
IBM ..  got rights from the spoils of concurrent.  Toyed with multi-chip module
implementations, but never really made it out of the labs
Not to mention numerous universities with academic architectures
and the list goes on...

The fact of the matter is that development tools for MCUs are a heck of a lot
easier to develop.  The problem is much more constrained (limited number of
instructions and linear sequential operation) for an MCU.  As I'm sure both
Xilinx and ALtera have found, the tools development is a larger effort than the
silicon architecture and design effort by a large margin.  I still maintain that
FPGA companies are really software companies that just happen to have an
expensive dongle that happens to be useful to circuit designers.

Peter Alfke wrote:

> Ralph Malph wrote:
> >
> >   I have seen several startup FPGA
> > companies look good and then fail.  This even includes large companies
> > like Motorola.
>
> Here is a partial list of major companies that introduced FPGAs, and
> then gave up:
>
> Motorola (never got out of the starting gate, relied on external software...)
> Intel (sold it to Altera, who then canned it quietly)
> NSC (disappeared quietly)
> AMD (sold it to Lattice)
> ATT (sold it to Lattice)
> T.I. ( stopped being second source to Actel)
> Toshiba (never really made it)
> Cypress (?)
>
> The moral of the story is that you survive as an FPGA manufacturer only
> when you are totally dedicated to that product line, which is true for
> Xilinx, Altera, Lattice, Actel, Quicklogic and some small start-ups.
> The Big Guys usually find it easier to make their money on other products.
>
> Peter Alfke

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 65191
Subject: Re: Synthesis errors?
From: "Subroto Datta" <sdatta@altera.com>
Date: Thu, 22 Jan 2004 03:12:56 GMT
Links: << >>  << T >>  << A >>
The Quartus II 3.0 Tool from Altera has a good VHDL/Verilog parser and
synthesis capability. The output of the synthesiser will work only with the
place and route tools from Altera, and you target all of the Altera devices.
A free version of the tools is available from:

https://www.altera.com/support/software/download/altera_design/quartus_we/dn
l-quartus_we.jsp

- Subroto Datta
Altera Corp.


"Ken Morrow" <junk@not_morro.co.uk> wrote in message
news:wmDPb.26583$qx2.3022656@stones.force9.net...
> Hi,
>
> I have recently had lots of incorrectly synthesised logic with the
> synthesiser I am using.
> My latest design occupied approx 20% of a "6 million gate" FPGA, and had a
> total of 5
> incorrectly synthesised parts (which took some finding).
>
> Can anyone recommend any synthesisers which do not suffer from this sort
of
> problem?
>
> The synth takes approx 1 hour to synth this (much quicker than most of my
> "large" designs), and timing far
> exceeds the requirements as the clock frequency is low.
>
> If anyone is interested, the sort of errors I was getting were:-
>
> A connection between 2 components was simply not made. An input to the
> second component was hardwired to '0'.
> Tried the very latest version of the same synth and the problem went away.
>
> The following problems were seen in the latest version:-
>
> OUT_DATA <= IN_DATA & "0";
> synthesised to
> OUT_DATA <= "0" & IN_DATA;
> put this in a clocked process and it synthesised correctly.
>
> OUT_DATA <= 2**IN_DATA;
> had OUT_DATA(0) hardwired to '1'.
> replaced with a case statement and it synthesised correctly
>
> if X = -1 then
>   OUT_DATA <= IN_DATA;
> elsif X= 1 then
>   OUT_DATA <= 0 - IN_DATA;
> elsif X=0 then
>   OUT_DATA <= 0;
> else
>   OUT_DATA <= 0 - IN_DATA;
> end if;
> had OUT_DATA=0 when X=-1
> put calculation of 0 - IN_DATA in a separate clocked process, and it
> synthesised correctly.
>
>
> An inferred ROM which synthesised correctly in an earlier version of the
> synthesiser, now infers a ROM filled with zeros.
> I worked around this by adding a reset to cause the ROM function to be
built
> from logic. This greatly increased
> the size, but this is not a problem for the particular design.
>
> I tried synthing the rogue pieces of code standalone, and they were
synthed
> correctly (apart from the ROM).
>
> Thanks,
>
> Ken,
> Morrow Electronics Limited,
> Milton Keynes,
> UK.
>
> kenm@morro.co.uk without the m after my name otherwise it will not be
> delivered.
>
>
>



Article: 65192
Subject: Re: WTD: info on AMD palce22v10
From: jim granville <no.spam@designtools.co.nz>
Date: Thu, 22 Jan 2004 16:37:09 +1300
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Atmel  .. still in it, but I still can't figure out why
> Dynachip .. got as far as producing silicon before dying
> Gatefield ..  sold to was it Actel?

Yes, and might yet hit critical mass - they service
a niche with true one chip FPGAs (FLASH included)


> Concurrent Logic ..  became the Atmel/NSC architecture
> IBM ..  got rights from the spoils of concurrent.  Toyed with multi-chip module
> implementations, but never really made it out of the labs
> Not to mention numerous universities with academic architectures
> and the list goes on...

Triscend anyone ?
Both the Triscend, and Atmel FPSlic must struggle against the
NIOS/MicroBlaze (etc) solutions.

> 
> The fact of the matter is that development tools for MCUs are a heck of a lot
> easier to develop.  The problem is much more constrained (limited number of
> instructions and linear sequential operation) for an MCU.  As I'm sure both
> Xilinx and ALtera have found, the tools development is a larger effort than the
> silicon architecture and design effort by a large margin.  I still maintain that
> FPGA companies are really software companies that just happen to have an
> expensive dongle that happens to be useful to circuit designers.

  Correct - Some stats were released last year (Altera?) showing they 
employed more SW engineers than HW designers.

-jg


Article: 65193
Subject: Re: Soft failures (?) 9536XL
From: jim granville <no.spam@designtools.co.nz>
Date: Thu, 22 Jan 2004 16:48:33 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> The XC9536XL is a Flash-based CPLD.  Different from an SRAM-based FPGA,
> you do not reconfigure it just by cycling Vcc. The CPLD would need a
> fresh in-system programming operation, which is not automatic nor
> happens by accident.
> So, what might have happened is that your design got into an illegal
> state, out of which it cannot excape, but which did not affect the configuration.

Correct - Check if you have any state machines, and what they do from
illegal states.

> 
> A more far-fetched explanation is based on the fact that a small part of
> the Flash-based configuration actually gets transferred into internal
> latches (like in an FPGA), which of course might get upset, and that
> would be fixed by cycling Vcc.
> All CPLD manufacturers use this convenient mechanism, but hardly anybody
> talks about it, since it creates the impression of "volatility"...
> 
> Peter Alfke

  You can sometimes find this hidden in the fine print, in the appx form
of "Vcc must be reduced to < 0.9V before being increased again'.
  Systems that are prone to brown-out and non monotonic Vcc are
more risky in this area.

  If you have the resource room, you can add read-back or similar
'check-it-actually-happened' to the PLD code, and have your system
watch for any out-to-lunch behaviour.

-jg



Article: 65194
Subject: Re: xilinx 70% tracking rule
From: jim granville <no.spam@designtools.co.nz>
Date: Thu, 22 Jan 2004 16:55:15 +1300
Links: << >>  << T >>  << A >>
guille wrote:

> Hi there,
> 
> Sorry for another Xilinx-specific question :)
> 
> Peter Alfke mentioned this 70% tracking rule for timing parameters,
> which basically says that if a parameter is at its max value, then all
> other parameters are between 70% and 100% of their guaranteed maximums.
> For Xilinx CPLDs, at least.
> 
> This makes a lot of sense from a physical standpoint, and I've seen
> it mentioned in other posts too.
> 
> I have only one question, if somebody can help. How is this 70% figure
> calculated, or estimated? Is it based on lab results only, or was it
> first derived analytically in some way or another and then verified
> experimentally? (I believe the latter). I'm curious about the physics
> involved.

It will be experimental / empirical.
It derives from all gates being on the same wafer (thus largely process 
track), and at the same Vcc, and similar Temperatures.
Normal process tracking these days is very good, and a portion of
variance will be physical location dependant, but it's easier to
umbrella that under process or min/max timing.

-jg




Article: 65195
Subject: Re: Soft failures (?) 9536XL
From: Jim Lewis <Jim@SynthWorks.com>
Date: Wed, 21 Jan 2004 20:08:15 -0800
Links: << >>  << T >>  << A >>
Did you analyze your design for nominal conditions
or worst case operating conditions?

I have seen boards fail when the got warm after
being closed up (or after a friend sets their engineering
notebook on top of the box and it heated up a little).

This happened to a board that I was interfacing to.
Problem went away after we drilled larger vent
holes in the product.  I guess that is what you
get when you get a product that is still in beta
testing.

Cheers,
Jim



Josep Duran wrote:

> I have a small circuit using the 9536XL CPLD. The complete machine uses
> 64 of such circuits. I have tested it on the lab and everything works just
> fine.
> 
> The problem is the other day, while at the client premises, I saw something
> wrong
> with one of the boards. The CPLD stopped responding to the commands sent by
> the computer. As I had no test equipment available, I just tried to send
> some reset
> commands to the board and get no response. I  turned power off to change the
> board, but just before replacing it I gave it another try. To my surprise,
> everything worked fine this time. I did some intensive testing to the board,
> and again
> everything went OK.
> 
> To me, it looks like the CPLD lost its configuration.
> Is this at all possible ? If so, what can I do to prevent this from
> happening ?
> Anybody seen something like this before ?
> 
> 
> NB - it is a 2 layer board (no GND plane) about 3 sq inches.
> 
> 
> Thank you for your time.
> 
>  Josep Duran
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: 65196
Subject: Re: Spirit on Mars
From: "Pablo Bleyer" <pbleyerN@SPAMembedded.cl>
Date: Thu, 22 Jan 2004 02:23:06 -0300
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin@xilinx.com> escribió en el mensaje
news:bup6dl$8dl2@cliff.xsj.xilinx.com...
> The reason for the failure of other parts could be that they are NOT
> FPGAs.  FPGAs are manufactured in huge volumes, and are all tested in
> the qualification for latch up under irradiation.  Many SRAM,s and other
> products do not have the volume to afford such testing, and in fact
> recent shrinks of common parts are known to latch up with a single
> event, and destroy themselves.

 Interesting. Under what conditions and what kind of tests are Xilinx
rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed
information about rad parameters...

 Regards.





Article: 65197
Subject: Re: Soft failures (?) 9536XL
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Thu, 22 Jan 2004 06:42:45 +0100
Links: << >>  << T >>  << A >>
Souds like you have asynchronous circuit in your design.
I saw many times your troubles in the past using CPLD andor FPGA. Every 
times these troubles became from kinds of asynchronous circuit or 
conception. When running asynchronous circuit, temperature can be affect 
your design, sometimes or sometimes not.

First, make sure you synchronize all your input signals, before to use 
it !!! Make sure your design DONT use comb. latch !

Regards,
Laurent
www.amontec.com



Josep Duran wrote:
> I have a small circuit using the 9536XL CPLD. The complete machine uses
> 64 of such circuits. I have tested it on the lab and everything works just
> fine.
> 
> The problem is the other day, while at the client premises, I saw something
> wrong
> with one of the boards. The CPLD stopped responding to the commands sent by
> the computer. As I had no test equipment available, I just tried to send
> some reset
> commands to the board and get no response. I  turned power off to change the
> board, but just before replacing it I gave it another try. To my surprise,
> everything worked fine this time. I did some intensive testing to the board,
> and again
> everything went OK.
> 
> To me, it looks like the CPLD lost its configuration.
> Is this at all possible ? If so, what can I do to prevent this from
> happening ?
> Anybody seen something like this before ?
> 
> 
> NB - it is a 2 layer board (no GND plane) about 3 sq inches.
> 
> 
> Thank you for your time.
> 
>  Josep Duran
> 
> 


Article: 65198
Subject: Re: Synthesis errors?
From: Eyck Jentzsch <jentzsch@cadence.com>
Date: Thu, 22 Jan 2004 07:38:37 +0100
Links: << >>  << T >>  << A >>
Ken Morrow wrote:
> Hi,
> 
> I have recently had lots of incorrectly synthesised logic with the
> synthesiser I am using.
> My latest design occupied approx 20% of a "6 million gate" FPGA, and had a
> total of 5
> incorrectly synthesised parts (which took some finding).
> 
> Can anyone recommend any synthesisers which do not suffer from this sort of
> problem?
> 
> The synth takes approx 1 hour to synth this (much quicker than most of my
> "large" designs), and timing far
> exceeds the requirements as the clock frequency is low.
> 
> If anyone is interested, the sort of errors I was getting were:-
> 
> A connection between 2 components was simply not made. An input to the
> second component was hardwired to '0'.
> Tried the very latest version of the same synth and the problem went away.
> 
> The following problems were seen in the latest version:-
> 
> OUT_DATA <= IN_DATA & "0";
> synthesised to
> OUT_DATA <= "0" & IN_DATA;
> put this in a clocked process and it synthesised correctly.
> 
> OUT_DATA <= 2**IN_DATA;
> had OUT_DATA(0) hardwired to '1'.
> replaced with a case statement and it synthesised correctly
> 
> if X = -1 then
>   OUT_DATA <= IN_DATA;
> elsif X= 1 then
>   OUT_DATA <= 0 - IN_DATA;
> elsif X=0 then
>   OUT_DATA <= 0;
> else
>   OUT_DATA <= 0 - IN_DATA;
> end if;
> had OUT_DATA=0 when X=-1
> put calculation of 0 - IN_DATA in a separate clocked process, and it
> synthesised correctly.
> 
> 
> An inferred ROM which synthesised correctly in an earlier version of the
> synthesiser, now infers a ROM filled with zeros.
> I worked around this by adding a reset to cause the ROM function to be built
> from logic. This greatly increased
> the size, but this is not a problem for the particular design.
> 
> I tried synthing the rogue pieces of code standalone, and they were synthed
> correctly (apart from the ROM).
> 
> Thanks,
> 
> Ken,
> Morrow Electronics Limited,
> Milton Keynes,
> UK.
> 
> kenm@morro.co.uk without the m after my name otherwise it will not be
> delivered.
> 
> 
> 

Every synthesizer will suffer 'cause all of them are SW and SW (as well 
as HW ;-) has bugs... The only solution to that problem would be to use 
an equivalence checker to check the generated Netlist against the RTL. 
They are also not bug free, but if the do not share code, the 
probability of having the same bug is near to 0. Tools in that area are 
for example Verplex LEC but there are a lot more.
HTH

-Eyck


Article: 65199
Subject: Re: xilinx 70% tracking rule
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Thu, 22 Jan 2004 06:41:07 GMT
Links: << >>  << T >>  << A >>

I don't know whether 70% is the correct number or not, as it depends on many
things and on how sophisticated the timing model was for the "maximum"
numbers in the first place.  But here are a few other phenomena to add to
the laundry list:
- Differences between rising and falling delay (is the max # worst case of
two?)
- Localized IR drop in power network causes differences in Vdd seen by
transistors in different areas of chip
- Temperature gradients due to differing power densities
- Unmodeled differences in physical structure between similar resources.
For example, in a crude timing model all wires of length 4 could be given
same delay, but in reality there are differences in what metal they are
adjacent to, they could have slightly different lengths, etc.  Or trace
lengths for two IOs could be slightly different.  Of course, whether this
need be included in the 70% depends on whether timing model accounts for
this stuff or not.
- Cross-coupling, which can speed up (or slow down) a signal.

Also, some aspects of process track very well across a die (e.g. metal,
dielectric thickness), while others do not -- for example, tranistor
threshold voltage can vary significantly from one transistor to the next due
to the stoicastic nature of implants/dopants, though the average Vt value
will be similar across the die.  Since timing paths include multiple
transistors, you tend to get an averaging effect, but still, it is another
thing to worry about.

But this is why FPGA companies have timing modeling and characterization
groups, and part of why FPGAs are slowly taking over the world (or so I hope
:-) -- imagine having to worry about all this stuff when doing your ASIC?

Regards,

Paul Leventis
Altera Corp.


> It will be experimental / empirical.
> It derives from all gates being on the same wafer (thus largely process
> track), and at the same Vcc, and similar Temperatures.
> Normal process tracking these days is very good, and a portion of
> variance will be physical location dependant, but it's easier to
> umbrella that under process or min/max timing.





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