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
2017JanFebMarApr2017

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 27225

Article: 27225
Subject: Re: Problem with Endianess in Xilinx Tools.
From: Phil Hays <spampostmaster@sprynet.com>
Date: Wed, 15 Nov 2000 18:35:52 -0800
Links: << >>  << T >>  << A >>
Richard Rooney wrote:


> Any ideas on how to solve this - without re-writing 1000's of lines if code

Write a wrapper that connects the buses your way to the busses that Xilinx tools
write:

Entity foo...
  busa	: in std_logic_vector(3 to 17); -- your way
...
component x_foo ...
  busa  : in std_logic_vector(17 downto 3); -- Xilinx default
...
x: x_foo port map (
     busa(3) <= busa(3), -- all the busa signals must be listed in one group
     busa(4) <= busa(4),
     busa(5) <= busa(5),
     busa(6) <= busa(6),
...


-- 
Phil Hays

Article: 27226
Subject: Hidden DLL mode bit - 1x vs 2x feedback
From: murray@pa.dec.com (Hal Murray)
Date: 16 Nov 2000 02:38:20 GMT
Links: << >>  << T >>  << A >>

The Virtex DLLs can operate in either of two modes.  One
expects the feedback clock to be running at the input
frequency.  The other expects it to be running at 2x.

The software figures out which mode to use.  There is
a description of this in XAPP132 on page 5.

I'd expect this mode bit to be visible in FPGAEditor,
but I can't find it there.

Anybody know where to find this flag/bit?  How can
I verify that the (magic) software did what I expect?

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27227
Subject: Re: Microprocessor Verilog/VHDL Models
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Thu, 16 Nov 2000 02:39:21 GMT
Links: << >>  << T >>  << A >>
     I just found out that Synopsis wants $80K for a one year license of
their Mot 5307 or 8260 instruction set model!  I consider this an ARM and a
leg!!
     My client will never go for this.  I guess I'm back to just simulating
the FPGAs and memories on the board, unless one of you out there knows of a
cheaper alternative.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.

********************************************************************
>      Does anyone here know of sources for microprocessor Verilog or VHDL
> behavioral models?
>      I am doing a board level simulation that involves FPGAs, memories,
> peanut components, and a Mot ColdFire microprocessor.  I checked with Mot
> about providing a C behavioral model or an encrypted Verilog/VHDL
behavioral
> model, and they referred me to the Big S -- Synopsis.  This means that it
> will cost an ARM and a leg, and I'm not talking about an ARM processor!
>      Does anyone know of alternatives?
> -Simon Ramirez, Consultant
>  Synchronous Design, Inc.




Article: 27228
Subject: mailing list for this newsgroup ?
From: xiao_john@excite.com (frank johson)
Date: 16 Nov 2000 04:45:14 +0100
Links: << >>  << T >>  << A >>
Is there a mailing list for this newsgroup ?

regards





_______________________________________________________
Tired of slow Internet? Get @Home Broadband Internet
http://www.home.com/xinbox/signup.html


-- 
Posted from kuku-rwcmta.excite.com [198.3.99.63] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 27229
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: gillies@cs.ubc.ca (Donald Gillies)
Date: 15 Nov 2000 20:14:39 -0800
Links: << >>  << T >>  << A >>
Michael Barr <mbarr@netrino.com> writes:

>This is a cryptographically signed message in MIME format.

>--------------ms4B962FB2094CDF47ED9278AE
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit

>I've just (finally) gotten around to posting a three-part article I
>wrote about a year ago on computing checksums and CRCs and the source 
>code that goes with it.  The URLs of the three articles are:

>        http://www.netrino.com/Connecting/1999-11/
>	http://www.netrino.com/Connecting/1999-12/
>	http://www.netrino.com/Connecting/2000-01/

>If you're new to the subject, I recommend reading them in order.  If,
>however, you are familiar with the theory of checksums and CRCs and just 
>want to get directly into the CRC implementation, you can just read the
>third.

First of all, the aforementioned piece of code appears to be
needlessly slow; the reflect() function will just nuke performance.
To avoid nuking performance, nay, if you just want a piece of code
that will BOMB performance, insteead of NUKING performance, see the
fast table-based lookup algorithm in the appendix for the PPP protocol
spec:

   http://www.cis.ohio-state.edu/htbin/rfc/rfc1331.html   

However, even this table lookup-based CRC algorithm will BOMB
performance, and if you want a decent checksum that won't destroy your
CPU, and have any freedom of design choice,

   YOU SHOULD DEFINITELY PICK A NON-GENERATOR POLYNOMIAL CHECKSUM.

It just turns out that the typical 8-bit generator polynomial
checksum, even with a table lookup implementation, requires 5 memory
fetches to checksum each 32-bit word.  Morevoer, the algebraic
instructions to do this checksum HAVE NO DATAFLOW PARALLELISM, meaning
a superscalar processor cannot achieve ANY speedup, and so you
gigahertz pentium will run the checksum loop like an 8080 at 50 Mhz.

If you compare this to the Internet's TCP/IP CRC (1's complement
addition - a single memory fetch & add), you'll understand why we're
throwing out telecom networks and installing Internet networks all
over the earth... :) :)

While it a 1's complement CRC-32 will not detect byte reordering,
there are similar CRC's (Fletcher's Algorithm) that still run 10x
faster than any generator polynomial checksum, and they detect byte
reordering.


Don Gillies - gillies@netapp.com - Network Appliance, Inc.
Adjunct Professor of Computer Engineering, UBC, Vancouver BC Canada V6T 1Z4
http://www.ee.ubc.ca/home/staff/faculty/gillies/etc/www/index.html


Article: 27230
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Dan Kotlow <dank@micrologic.com>
Date: Thu, 16 Nov 2000 07:59:58 GMT
Links: << >>  << T >>  << A >>

I'm sure you get much better performance with the methods you suggest,
provided that you don't count undetected errors as reducing
performance.  However, if undetected errors are important in your
application, then those arithmetic checks suck badly compared to real
CRC.

I, in particular, have the misfortune to be working with a satellite
communications provider that uses the Fletcher checksum for error
control.  We get corrupted data constantly.  It only takes two
"well-placed" bit errors to fool the Fletcher checksum.

CRCs are bit-oriented, and so may not use a Pentium to its best
advantage, but they're not that bad.  My 16-bit CRC routine for the
8051 (idata), IIRC, takes 17 instruction cycles per bit (shift and
XOR, not table lookup).  And you get a lot more error detection power
for your extra CPU cycles.

I'm sure there are applications where speed is more important than
correctness, but, for most embedded applications, I'd recommend CRCs
over arithmetic checksums.

-Dan

PS: The word "cyclic" in "CRC" generally refers to a linear code which
is invariant under cyclic shifts (although in error detection they are
"shortened", and then no longer cyclic).  Such a code necessarily has
a generator polynomial.  Calling arithmetic checksums CRCs is
misleading, in my opinion.  They are not in the same league.


On 15 Nov 2000 20:14:39 -0800, gillies@cs.ubc.ca (Donald Gillies)
wrote:


>
>First of all, the aforementioned piece of code appears to be
>needlessly slow; the reflect() function will just nuke performance.
>To avoid nuking performance, nay, if you just want a piece of code
>that will BOMB performance, insteead of NUKING performance, see the
>fast table-based lookup algorithm in the appendix for the PPP protocol
>spec:
>
>   http://www.cis.ohio-state.edu/htbin/rfc/rfc1331.html   
>
>However, even this table lookup-based CRC algorithm will BOMB
>performance, and if you want a decent checksum that won't destroy your
>CPU, and have any freedom of design choice,
>
>   YOU SHOULD DEFINITELY PICK A NON-GENERATOR POLYNOMIAL CHECKSUM.
>
>It just turns out that the typical 8-bit generator polynomial
>checksum, even with a table lookup implementation, requires 5 memory
>fetches to checksum each 32-bit word.  Morevoer, the algebraic
>instructions to do this checksum HAVE NO DATAFLOW PARALLELISM, meaning
>a superscalar processor cannot achieve ANY speedup, and so you
>gigahertz pentium will run the checksum loop like an 8080 at 50 Mhz.
>
>If you compare this to the Internet's TCP/IP CRC (1's complement
>addition - a single memory fetch & add), you'll understand why we're
>throwing out telecom networks and installing Internet networks all
>over the earth... :) :)
>
>While it a 1's complement CRC-32 will not detect byte reordering,
>there are similar CRC's (Fletcher's Algorithm) that still run 10x
>faster than any generator polynomial checksum, and they detect byte
>reordering.
>
>
>Don Gillies - gillies@netapp.com - Network Appliance, Inc.
>Adjunct Professor of Computer Engineering, UBC, Vancouver BC Canada V6T 1Z4
>http://www.ee.ubc.ca/home/staff/faculty/gillies/etc/www/index.html
>

Article: 27231
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: "Niall Murphy" <nmurphynews@panelsoft.com>
Date: Thu, 16 Nov 2000 08:55:30 -0000
Links: << >>  << T >>  << A >>

Dan Kotlow <dank@micrologic.com> wrote in message
news:3a138b05.91598579@news.ma.ultranet.com...
>
> I'm sure you get much better performance with the methods you suggest,
> provided that you don't count undetected errors as reducing
> performance.  However, if undetected errors are important in your
> application, then those arithmetic checks suck badly compared to real
> CRC.
>
> I, in particular, have the misfortune to be working with a satellite
> communications provider that uses the Fletcher checksum for error
> control.  We get corrupted data constantly.  It only takes two
> "well-placed" bit errors to fool the Fletcher checksum.
>
I agree with you completely, that the previous poster was misleading
everyone by implying that the IP checksum is as good as a CRC (and Michael's
articles referenced in the original post explain all that in detail). My
question is that I am curious if a CRC would solve your specific problem.
When you say that you get corrupted dataconstantly, do you mean that you get
data with a valid checksum, even though it has been corrupted?

Mathematically CRC is definitly better than a checksum, I have just not come
across a real practical case where the difference could be identified. I
suspect that it is a function of how large the packets are - 16 bits as a
check on 100 bytes seems reasonable, but as a check on 10000 bytes seems
riskier to me (but I do not know if there is a simple mathematical
justification of that) - what is the ratio on your appication. If anyone
knows a recommended ratio where you should switch to CRC I would be curious.
    Niall Murphy (http://www.panelsoft.com)




Article: 27232
Subject: Basic question on PLD & FPGA
From: Daniel Hanczewski <danhan@wp.pl>
Date: Thu, 16 Nov 2000 10:07:58 +0100
Links: << >>  << T >>  << A >>
Hi all,

I am rookie in programmable logic and I have just started getting in
this subject.
My question is: what is the difference between PLD, CPLD and FPGA? If I
have a logical circuit and want to implement it in programmable chip
what circumstances should I consider to choose a proper kind of chip? Is
it so that PLD and CPLD are used for large combinational projects while
FPGA are used for register-based circuits?

Thank you in advance.
Daniel


Article: 27233
Subject: Re: Schematics & VHDL
From: Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de>
Date: Thu, 16 Nov 2000 10:27:06 +0100
Links: << >>  << T >>  << A >>
Hi,

V Ram wrote:

> I have a quick question...
>
> What third-party tools offer "good" schematic entry combined with the
> ability to graphically hook up VHDL blocks? I have MaxPlusII which allows
> this, but I'm using some outside tools for the VHDL synthesis and didn't
> know if better third-party schematic entry tools existed.
>
> As far as I know, things like Renoir & Active HDL are only meant for
> "block" diagrams and VHDL entry, not providing the ability to tack down a
> DFF and some combinational logic, etc.
>
> I know Aldec has such a program and I think that's what is bundled with
> the Xilinx Foundation tools and I wasn't too impressed. Any others? Anyone
> use ViewDraw?
>

You may take a look at part 3 section 5 of the VHDL FAQ
(http://www.vhdl.org/comp.lang.vhdl/). It lists some free
and commercial VHDL <-> Schematic/FSM Translators.

--
Edwin



Article: 27234
Subject: Problems wirh JTAG-Configuration of 18V512 and Spartan XCS40
From: "Christian Reichherzer" <creich@rzws.fh-aalen.de>
Date: Thu, 16 Nov 2000 10:55:05 +0100
Links: << >>  << T >>  << A >>
Hello!!!

Iīm student and I still working on my diploma. In addition to the line up of
my hardeware, I need support for configuring the JTAG-chain.
My Boundary-Scan chain is built up with a Spartan XCS40 and an ISP XC18V512.
The configuration of the FPGA via the ISP is established, but the direct
JTAG download with the parallel Xilinx cable (required for JTAG-Programmer
with XC18V00 devices) doesnīt work. Whenever I try to download the following
messages  appear:

JTAGProgrammer:Release WebPACK 3.2WP3.x - JTAG Boundary-Scan Download D.23
Copyright:1991-1999
JTAG Programmer Started 2000/11/16 10:37:06
Loading Boundary-Scan Description Language (BSDL) file
'xc18v512_so20.bsd'.....completed successfully.
Loading Boundary-Scan Description Language (BSDL) file
'C:/Xilinx_WebPACK/spartan/data/xcs40_pq208.bsd'.....completed successfully.
Checking boundary-scan chain integrity...done.
Verifying device positions in boundary-scan chain...
Instance 'design_level_1_fpga4(Device1)' at position '1'...verified.
Verification completed.
Boundary-scan chain validated successfully.
'design_level_1_fpga4(Device2)': Checking boundary-scan chain
integrity...done.
'design_level_1_fpga4(Device2)': Reading bit-stream file...done.
'design_level_1_fpga4(Device2)': Programming device.....done.
'design_level_1_fpga4(Device2)': Programming completed successfully.

Oh fine, it should work, but on my hardware, the DONE-pin never changes to
HIGH (also no changes on /INIT). The input TDI receives data via the TDO of
the XC18V512.
By the way, the JTAG-Programmer canīt read the ID from the Spartan FPGA.
Whatīs wrong? Is that the reason for the failure?

Christian



Article: 27235
Subject: Re: Basic question on PLD & FPGA
From: Michael Strothjohann <strothjohann@rheinahrcampus.de>
Date: Thu, 16 Nov 2000 10:40:14 +0000
Links: << >>  << T >>  << A >>
Hi,
PLD/CPLDs: They use a 'crossbar' in connecting
the different logical elements, each of them containing
a FF and some simple logic. Classical application :
state machine. In general: no additioal elements
( like memory ). Example: lattice/cypress/..
The difference between CPLDs and FPGAs are
now disappearing :The new Cypress chip is another
game. ( it is with memory )

FPGAs: The logical elements are connected via
channels, so there structure is more like an asic
than a cpld ( with all pros and cons ).
Example: Xilinx ( often disscussed in this news ),
Altera,Quicklogic,..
regards
michael


Daniel Hanczewski schrieb:

> Hi all,
>
> I am rookie in programmable logic and I have just started getting in
> this subject.
> My question is: what is the difference between PLD, CPLD and FPGA? If I
> have a logical circuit and want to implement it in programmable chip
> what circumstances should I consider to choose a proper kind of chip? Is
> it so that PLD and CPLD are used for large combinational projects while
> FPGA are used for register-based circuits?
>
> Thank you in advance.
> Daniel


Article: 27236
Subject: Re: Xilinx Foundation Sudent Version 1.5
From: Michael Strothjohann <strothjohann@rheinahrcampus.de>
Date: Thu, 16 Nov 2000 11:08:19 +0000
Links: << >>  << T >>  << A >>
Hi,
    if you want a low-cost tool and you are
    a friend of xilinx-chips you would probably
    be happy with their wep-pack 3.2i.
    (vhdl and verilog included, prob. as
    a beginner you need a textbook on synthesis)
    In this news wep-pack32i is often
    classified as useless,
    -i am using it without any relevant fault -
    it is with spartan2 and Virtex300 and
    download is free. As an alternate you may
    also concern the other big player Altera
    and there student edition.

    regards
    michael

djley schrieb:

> Would some one be interested in answering questions on this software.
> I'm not a student but would like to learn and there is no support for this
> product by Xilinx.


Article: 27237
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: dempson@actrix.gen.nz (David Empson)
Date: Fri, 17 Nov 2000 00:40:07 +1300
Links: << >>  << T >>  << A >>
Niall Murphy <nmurphynews@panelsoft.com> wrote:

> Mathematically CRC is definitly better than a checksum, I have just not come
> across a real practical case where the difference could be identified. I
> suspect that it is a function of how large the packets are - 16 bits as a
> check on 100 bytes seems reasonable, but as a check on 10000 bytes seems
> riskier to me (but I do not know if there is a simple mathematical
> justification of that) - what is the ratio on your appication. If anyone
> knows a recommended ratio where you should switch to CRC I would be curious.

Well, let us start with the well known mathematical properties of a
correctly implemented 16-bit CRC (e.g. CRC-CCITT or CRC-16), courtesy of
Tanenbaum.  It will detect errors as follows:

- All single bit errors (as does a simple checksum)
- All double bit errors
- All errors with an odd number of bits
- All burst errors of 16 bits or less
- 99.997% of 17 bit burst errors
- 99.998% of 18 bit or longer burst errors

A "burst error" is one in which the first and last bits are wrong, and
all the bits in between may be right or wrong.  (If there are two or
more burst errors in the message, they must be treated as a single burst
error starting at the first bit of the first burst and ending at the
last bit of the last burst.)  These percentages assume the corruption
pattern of burst errors are completely random.  If not, these
percentages may need to be reduced.

An interesting example of this: if a CRC is preset to zero and
transmitted without being complemented, then any message consisting of
16 or more zero bits will be regarded as correct.  (A "burst error"
which forces all bits to be zero.)


I haven't seen the corresponding stats for a 32-bit CRC, but I expect
the last three statements are simply replaced with 32, 33 and 34, with
even higher percentages in the last two cases.

Looking at random single bit errors, assume there is a very low
probability P of an error occuring for each bit in the message.  The
longer the message, the higher the probability that there will be at
least one error.

For N bits, the probability of at least one error is (1-(1-P)^N).

If this number is too large, then you are not likely to get very many
messages through, so in a relatively noisy environment it is a good idea
to keep N as low as possible by limiting the maximum message length.

For the CRC to fail (i.e. pass a erroneous message without flagging a
CRC error), you need a minimum of four single bit errors, and the first
and the last error must be at least 17 bits apart.

As it is after midnight and my brain has switched off, I don't want to
go through the maths for this right now, but you should be able to see
that the longer the message, the higher the probability of this
occurring.  We then have to take the 99.998% figure into account (i.e.
0.002% of burst errors will slip through) to calculate the probability
of an undetected error.

There are also real burst errors to consider, i.e. a short burst of
completely random noise which ends up corrupting a consecutive range of
bits in the message.  These are harder to analyse and depend to some
extent on what sort of bursts might be expected on a particular
transmission medium (e.g. colliding transmissions from other stations,
power surges, or whatever).  The likelihood of multiple burst errors
needs to be considered as well, as well as the likelihood of one or more
random single bit errors in the same message as a real burst error.

Assuming you can pick some reasonable figure for the probability of a
burst error and its possible length, you should be able to calculate the
probability of it passing undetected, and add this to the above figure
for random single bit errors to determine the total probability of an
undetected error.

Good luck!

The decision about a reasonable "maximum length" may be influenced by
the expected probability of errors (of either type).

On a relatively error-free link it may be acceptable to send quite long
messages with a 16-bit CRC to detect the occasional error.

If the error probability is high enough then the maximum message length
should be reduced so that the number and length of retransmissions can
be kept to a minimum.

If there is a reasonable possibility of getting at least four errors in
a single message then there is a slim chance of an erroneous message
slipping through; reducing the maximum message length may help to reduce
the likelihood of this.

Article: 27238
Subject: VHDL & Spartan: How to power-up a Register to '1' ?
From: "Peter Lang" <Peter.Lang@rmvmachinevision.de>
Date: Thu, 16 Nov 2000 13:38:53 +0100
Links: << >>  << T >>  << A >>
Hi,
by default FGPA Express will init all Registers in my Spartan device to
zero.
How can I change this default?
When doing schematic entry this was easyly done by adding "INIT=S"
But how can I do this with VHDL?

Thanks
peter




Article: 27239
Subject: Re: BUFT conflict with LOC
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 16 Nov 2000 15:01:24 +0200
Links: << >>  << T >>  << A >>
Tom Branca wrote:
> 
> Hello Utku,
>     I think I would use the area group constraints in this situation,
> rather than the LOC range constraints.  Area groups allow you to define
> groups of logic by assigning logical instance to a specific area group,
> then you can assign this area group to a specific range in the device.
> There is more flexibility with area groups because you can specify the
> type of resource that you want constrained to the area via the RANGE
> constraint.  I have included some syntax and usage information for the
> area group constraint below.
> 
> Cheers,
> Tom

  Tom,

  thank you for your response.

  The AREA_GROUP is not supported by M2.1i SP6. As I stated
  in my first posting, I am using M2.1i SP6.

  Utku

Article: 27240
Subject: Re: Basic question on PLD & FPGA
From: "Steve Fair" <sfair6@home.com>
Date: Thu, 16 Nov 2000 13:27:22 GMT
Links: << >>  << T >>  << A >>
Daniel -

A bit of a gray definition, but . . .

PLD - Macrocell (product term) architecture, rich in combinatorial logic,
not too many flops.  Do a good job with state machines, arbiters / address
decoders, etc.  Claim to fame is speed from input to output (as little as 4
ns) and non-volatility (PROM or flash based)

CPLD - Altera terminology (complex PLD), associate this with FPGA

FPGA - Typically lookup table architecture (4-input lut with a flop is
prevalent architecture, although others use more of a mux - 8 inputs in some
Actel devices).  These devices go up into the 40-50k luts & flops with
internal memory.  Applications tend to be more data / data path oriented due
to large FLOP resources.  The big boys (Xilinx and Altera) are SRAM based
(i.e. volatile, need to be programmed at power up with an external prom or
flash), other variations are OTP or flash-based.

In a nutshell, you'll see PLDs in smaller, fast applications, FPGAs where
more resources are needed - I don't mean to denigrate the FPGA's on speed,
though - they're extremely fast these days, too.  I see CPLD's more in glue
logic applications and FPGAs where you're doing data manipulations.

If you really want to get a thread started, ask which one is best!!!

Steve



"Daniel Hanczewski" <danhan@wp.pl> wrote in message
news:3A13A3EE.7CD09B9C@wp.pl...
> Hi all,
>
> I am rookie in programmable logic and I have just started getting in
> this subject.
> My question is: what is the difference between PLD, CPLD and FPGA? If I
> have a logical circuit and want to implement it in programmable chip
> what circumstances should I consider to choose a proper kind of chip? Is
> it so that PLD and CPLD are used for large combinational projects while
> FPGA are used for register-based circuits?
>
> Thank you in advance.
> Daniel
>



Article: 27241
Subject: Re: VHDL & Spartan: How to power-up a Register to '1' ?
From: "Keith R. Williams" <krw@btv.ibm.com>
Date: Thu, 16 Nov 2000 09:23:36 -0500
Links: << >>  << T >>  << A >>


Peter Lang wrote:
> 
> Hi,
> by default FGPA Express will init all Registers in my Spartan device to
> zero.
> How can I change this default?
> When doing schematic entry this was easyly done by adding "INIT=S"
> But how can I do this with VHDL?

Try: 
  
signal  widget: std_logic_vector(7 downto 0); -- my register    

Reg:    process (Clk,Reset) 
        begin
        if      Reset  = '1'                  -- If asynchronous reset
          then	widget  <=  (others => '1');  --   then set flop to one
        elseif  rising_edge(Clk)              -- else if clock
 	  then                                --   then whatever
          ...
        end if;
        end process;

----
  Keith

Article: 27242
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Joe Durusau <joseph.a.durusau@lmco.com>
Date: Thu, 16 Nov 2000 06:53:04 -0800
Links: << >>  << T >>  << A >>
	Well, in the olden days of mainframe computers, the larger IBM
systems came with a memory that read something like 32 bits of data and
8 bits of crc with each memory reference.  There was a special trick
that
the service people did to find out if the memory controller was seeing
(and correcting) errors.  Never did a day go by that there was not an
error.
Simple parity checks helped, but did not allow correction of the data.
If the bit in question did something serious, like say "dump the air
from
the space station" or "reset and reboot all the flight contorl logic in
the aircraft" the problems could be quite spectacular.  There are
hardware
implementations for crc in existance, for those who need speed.  

I guess it just depends on how important the accuracy offthe data is. 
After
all, in the telephone networkm if Aunt Minnie sounds a little off,
nobody 
will likely care.  OTOH, if a missile gets launched at the wrong country 
because a bye gets exchanged with another, I suspect a lot of folks
would
care, at least for a short time.

Speaking only for myself,

Joe Durusua


Niall Murphy wrote:
> 
> Dan Kotlow <dank@micrologic.com> wrote in message
> news:3a138b05.91598579@news.ma.ultranet.com...
> >
> > I'm sure you get much better performance with the methods you suggest,
> > provided that you don't count undetected errors as reducing
> > performance.  However, if undetected errors are important in your
> > application, then those arithmetic checks suck badly compared to real
> > CRC.
> >
> > I, in particular, have the misfortune to be working with a satellite
> > communications provider that uses the Fletcher checksum for error
> > control.  We get corrupted data constantly.  It only takes two
> > "well-placed" bit errors to fool the Fletcher checksum.
> >
> I agree with you completely, that the previous poster was misleading
> everyone by implying that the IP checksum is as good as a CRC (and Michael's
> articles referenced in the original post explain all that in detail). My
> question is that I am curious if a CRC would solve your specific problem.
> When you say that you get corrupted dataconstantly, do you mean that you get
> data with a valid checksum, even though it has been corrupted?
> 
> Mathematically CRC is definitly better than a checksum, I have just not come
> across a real practical case where the difference could be identified. I
> suspect that it is a function of how large the packets are - 16 bits as a
> check on 100 bytes seems reasonable, but as a check on 10000 bytes seems
> riskier to me (but I do not know if there is a simple mathematical
> justification of that) - what is the ratio on your appication. If anyone
> knows a recommended ratio where you should switch to CRC I would be curious.
>     Niall Murphy (http://www.panelsoft.com)

Article: 27243
Subject: Re: Need help locking pins for Spartan XL
From: "Qian Zhang" <qianz@cae.wisc.edu>
Date: Thu, 16 Nov 2000 08:53:55 -0600
Links: << >>  << T >>  << A >>
So Can i lock the pin number in the VHDL file?
If yes what is the syntax?
Dan <daniel.deconinck@sympatico.ca> wrote in message
news:OqVN5.26401$1C6.1280515@news20.bellglobal.com...
> My pin locs are based on my PCB needs.
>
> I like the PCB routing to flow out radially away from the FPGA in all
> directions. I can route directly to memory/ buses / ADCs/ DACs etc. with
> next to no vias. Its a beautiful thing.
>
> Only if the design is going to challenge the FPGA do I reconsider this
> approach.
>
> Dan
>
>
>



Article: 27244
Subject: Re: BUFT conflict with LOC
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 16 Nov 2000 16:58:35 +0200
Links: << >>  << T >>  << A >>
Tim Jaynes wrote:
> 
> The problem essentially boils down to the fact that you've used:
> 
> >
> >  CLB/Slice Constraint: CLB_RnCm
> >
> 
> But should have used:
> 
> >  TBUF: TBUF_RnCm
> >
> 
> a LOC is fine, you just need to use the right element group.
> Tim

  When you use LOC=TBUF_* then FMAP and HMAP will conflict with LOC=CLB_*.
  When you use LOC=CLB_* then TBUF elements will conflict with LOC=TBUF_*

  You must use both commands at the same time (Xilinx support):

  INST "..." LOC=CLB_*
  INST "..." LOC=TBUF_*

  But when a INST "..." contains TBUF, CLB and RAMB4_* elements
  at the same time, there is no solution yet announced by Xilinx.
  MAP always gives an error, if you use three LOC:

  INST "..." LOC=CLB_*
  INST "..." LOC=TBUF_*
  INST "..." LOC=RAMB4_*

  Isn't there anybody in the world who has tried this?
 
  Utku

Article: 27245
Subject: Actel Compiler errors..... from Synplify?!
From: James Buchanan <jbuchanan@west.raytheon.com>
Date: Thu, 16 Nov 2000 08:57:08 -0700
Links: << >>  << T >>  << A >>
HI All,
   Here's a seemingly easy problem that has me running for the hills!!!

Using Synplify to construct edif listings that are later pulled into
Actel's designer. Problem seems to be that Synplify is using pre-define
MACROS that construct an HCLK like architecture. Problem is that I am
NOT using this HCLK architecture for the overall design. Thus, Synplify
constructs an FPGA using macros that construct this HCLK stuff that I am
NOT using. Granted, I am using the high performance IOCLKs, but NO WHERE
do I use this HCLK. THE PIN IS EMPTY!!! THE VHDL DOES NOT CALL FOR
THEM!!!

  HELP!!! HELP !!!!! 
     HELP!!!!!!


jhbuchanan@west.raytheon.com

Article: 27246
Subject: Re: Problems wirh JTAG-Configuration of 18V512 and Spartan XCS40
From: Ray Andraka <ray@andraka.com>
Date: Thu, 16 Nov 2000 16:20:43 GMT
Links: << >>  << T >>  << A >>
You need to set the start-up clock to the JTAG clock in the configuration
options during bitstream generation.  That should fix your problem.

Christian Reichherzer wrote:
> 
> Hello!!!
> 
> Iīm student and I still working on my diploma. In addition to the line up of
> my hardeware, I need support for configuring the JTAG-chain.
> My Boundary-Scan chain is built up with a Spartan XCS40 and an ISP XC18V512.
> The configuration of the FPGA via the ISP is established, but the direct
> JTAG download with the parallel Xilinx cable (required for JTAG-Programmer
> with XC18V00 devices) doesnīt work. Whenever I try to download the following
> messages  appear:
> 
> JTAGProgrammer:Release WebPACK 3.2WP3.x - JTAG Boundary-Scan Download D.23
> Copyright:1991-1999
> JTAG Programmer Started 2000/11/16 10:37:06
> Loading Boundary-Scan Description Language (BSDL) file
> 'xc18v512_so20.bsd'.....completed successfully.
> Loading Boundary-Scan Description Language (BSDL) file
> 'C:/Xilinx_WebPACK/spartan/data/xcs40_pq208.bsd'.....completed successfully.
> Checking boundary-scan chain integrity...done.
> Verifying device positions in boundary-scan chain...
> Instance 'design_level_1_fpga4(Device1)' at position '1'...verified.
> Verification completed.
> Boundary-scan chain validated successfully.
> 'design_level_1_fpga4(Device2)': Checking boundary-scan chain
> integrity...done.
> 'design_level_1_fpga4(Device2)': Reading bit-stream file...done.
> 'design_level_1_fpga4(Device2)': Programming device.....done.
> 'design_level_1_fpga4(Device2)': Programming completed successfully.
> 
> Oh fine, it should work, but on my hardware, the DONE-pin never changes to
> HIGH (also no changes on /INIT). The input TDI receives data via the TDO of
> the XC18V512.
> By the way, the JTAG-Programmer canīt read the ID from the Spartan FPGA.
> Whatīs wrong? Is that the reason for the failure?
> 
> Christian

-- 
-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  or http://www.fpga-guru.com

Article: 27247
Subject: Re: Need help locking pins for Spartan XL
From: Ray Andraka <ray@andraka.com>
Date: Thu, 16 Nov 2000 16:22:51 GMT
Links: << >>  << T >>  << A >>
Yes, but it is quite a bit easier to do it in a UCF file.

TO do it in VHDL, you need to create an attribute called LOC and attach it to
each IOB, which means you also have to instantiate the IO buffers rather than
letting the tool infer them

attribute LOC:string;
attribute LOC of iob_name:label is "P111";

begin

iob_name:OBUF port map(
	...





Qian Zhang wrote:
> 
> So Can i lock the pin number in the VHDL file?
> If yes what is the syntax?
> Dan <daniel.deconinck@sympatico.ca> wrote in message
> news:OqVN5.26401$1C6.1280515@news20.bellglobal.com...
> > My pin locs are based on my PCB needs.
> >
> > I like the PCB routing to flow out radially away from the FPGA in all
> > directions. I can route directly to memory/ buses / ADCs/ DACs etc. with
> > next to no vias. Its a beautiful thing.
> >
> > Only if the design is going to challenge the FPGA do I reconsider this
> > approach.
> >
> > Dan
> >
> >
> >

-- 
-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  or http://www.fpga-guru.com

Article: 27248
Subject: Re: Schematics & VHDL
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 16 Nov 2000 16:29:46 +0000
Links: << >>  << T >>  << A >>
On Wed, 15 Nov 2000 21:41:34 +0000 (UTC), V Ram
<ipickledthefigsmyeslf@mrbourns.com> wrote:

>I have a quick question...
>
>What third-party tools offer "good" schematic entry combined with the
>ability to graphically hook up VHDL blocks? I have MaxPlusII which allows
>this, but I'm using some outside tools for the VHDL synthesis and didn't
>know if better third-party schematic entry tools existed.
>
>As far as I know, things like Renoir & Active HDL are only meant for
>"block" diagrams and VHDL entry, not providing the ability to tack down a
>DFF and some combinational logic, etc.

You _can_ do that in Renoir; at the gate/VHDL level if you so wish
(after making components for your DFF's etc) or by inserting a text
block containing combinatorial expressions. It's not as convenient a way
to build a complete schematic but it's fine for augmenting a block
diagram with moderate quantities of glue logic.

- Brian

Article: 27249
Subject: 5v parallel cable with 2.5/3.3v spartan II?
From: cottons@concmp.com
Date: 16 Nov 2000 11:42:19 -0500
Links: << >>  << T >>  << A >>
I have a Xilinx Parallel Cable III, model DLC5, labeled as operating
at 5v.  Does anyone know if this will work with a 2.5vccint/3.3vcco
Spartan II board?  I'm using the Insight Electronics Spartan II board.

        - Cotton



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
2017JanFebMarApr2017

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