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 27675

Article: 27675
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Marc Warden <marc.warden@att.net>
Date: Sat, 02 Dec 2000 00:11:11 GMT
Links: << >>  << T >>  << A >>
Michael Barr wrote:

> 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.
>
> A ZIP file containing just the source code for the CRC routines is at:
>
>         http://www.netrino.com/Connecting/2000-01/crc.zip
>
> The code is placed into the public domain and may be used for any purpose
> public or private.  There are some limitations in its use (it's written
> in C), but the underlying algorithms are solid and could be ported to the
> assembly language (or hardware) of your choice if necessary.
>
> Enjoy,
>         Michael Barr

Hi Michael.

Question for you: Have you ever come across a method in a CRC of removing a
byte, word, or long from the block of data, changing it (on purpose) and
putting it back into the block of data (in its same location) and then
modifying the CRC and if the CRC is checked it will check out OK?

That is, I don't want to have to modify the data location and then
recalculate the CRC on the whole block of data, but would like to have the
CRC verify.

The data is code being run in 'real time' and because it was written for one
processor but being run on a new processor (the code is down loaded into the
new processor's address space) and before the data/code is run, it is patched
to address some instruction differences between teh original CPU target vs.
the new one.

Right now I'm patching the code/data and have disabled CRC checking (because
I know it will fail and cause the system to halt any further processing) but
I would like to (if possible) re-enable CRC checking (to catch unententional
changes to the code/data) but have the checking insensitive to intentional
changes to a few locations in the code/data.

I know I know. No matter how I put it, it sounds goofy...

Sincerely,

 MarcW. (And it is.)


Article: 27676
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Marc Warden <marc.warden@att.net>
Date: Sat, 02 Dec 2000 00:12:59 GMT
Links: << >>  << T >>  << A >>
Donald Gillies wrote:

> 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

That Fletcher checksum is limited to (fairly) small blocks of data, I think
around 8191 bits (that's bits, not bytes).

Sincerely,

 MarcW.


Article: 27677
Subject: Re: Virtex ROM ques.
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 01 Dec 2000 16:43:01 -0800
Links: << >>  << T >>  << A >>
Phil James-Roxby <phil.james-roxby@xilinx.com> writes:
> You could use JBits to do this.  On the main Xilinx web site, go to
> products -> System solutions -> Xilinx Online and there is a little
> description of JBits.

Sounds nifty.  It says "JBits will be available over the web in 1Q99."
But I can't seem to actually find it.  Any hints?

Article: 27678
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Herman Oosthuysen <aerosoft@AerospaceSoftware.com>
Date: Sat, 02 Dec 2000 01:31:54 GMT
Links: << >>  << T >>  << A >>
Well, you can run a CRC forwards and reverse.  The reverse is actually a
different polynomial.  See DSP Guru for the trick, but basically you
just take the (order - power) for each term to get the other
polynomial.  You should be able to use this info to gen a CRC patch - I
dunno how though, but I think it would be workable.  If you get
completely stuck, drop me some mail, I know a few tricks.

Cheers,

Herman
http://www.AerospaceSoftware.com

Marc Warden wrote:
> 
> Michael Barr wrote:
> 
> > 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.
> >
> > A ZIP file containing just the source code for the CRC routines is at:
> >
> >         http://www.netrino.com/Connecting/2000-01/crc.zip
> >
> > The code is placed into the public domain and may be used for any purpose
> > public or private.  There are some limitations in its use (it's written
> > in C), but the underlying algorithms are solid and could be ported to the
> > assembly language (or hardware) of your choice if necessary.
> >
> > Enjoy,
> >         Michael Barr
> 
> Hi Michael.
> 
> Question for you: Have you ever come across a method in a CRC of removing a
> byte, word, or long from the block of data, changing it (on purpose) and
> putting it back into the block of data (in its same location) and then
> modifying the CRC and if the CRC is checked it will check out OK?
> 
> That is, I don't want to have to modify the data location and then
> recalculate the CRC on the whole block of data, but would like to have the
> CRC verify.
> 
> The data is code being run in 'real time' and because it was written for one
> processor but being run on a new processor (the code is down loaded into the
> new processor's address space) and before the data/code is run, it is patched
> to address some instruction differences between teh original CPU target vs.
> the new one.
> 
> Right now I'm patching the code/data and have disabled CRC checking (because
> I know it will fail and cause the system to halt any further processing) but
> I would like to (if possible) re-enable CRC checking (to catch unententional
> changes to the code/data) but have the checking insensitive to intentional
> changes to a few locations in the code/data.
> 
> I know I know. No matter how I put it, it sounds goofy...
> 
> Sincerely,
> 
>  MarcW. (And it is.)

Article: 27679
Subject: Re: Hey there anybody!!
From: Muzaffer Kal <muzaffer@dspia.com>
Date: 02 Dec 2000 01:53:20 GMT
Links: << >>  << T >>  << A >>
"InGenius Engineering" <Ellen@ingeniusengineering.com> wrote:

>Hi there,
>
>My name is Ellen Ann Nichol and I am a recruiter...before you spam me..I am
>not hear to use this posting board to recruit FPGA people. Since I have a
     ^^^^
>dire need for FPGA people, I only wanted to know if people could send me
>suggestions on how to recruit you guys.  Call it a survey if you like.  If
>you were looking for a job where would you look? Do you go to certain web
>sites? That sort of thing. Any tips would be greatly appreciated.
>
>ellen@ingeniusengineering.com
>
>

I always see "great written and verbal communication skills" in
engineering job descriptions. Isn't this also requirement for
recruiters?

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 27680
Subject: Re: Synplify Benchmarks
From: Ray Andraka <ray@andraka.com>
Date: Sat, 02 Dec 2000 02:26:48 GMT
Links: << >>  << T >>  << A >>
If you are using the DLLs in VIrtex, you can't really stop the clock because it
makes the DLL lose lock.  In fact there is a configuration mode that will hold
GSR on until the DLL locks.  WIthout the DLL, you gt pretty poor clock to out
timing, which tends to make the DLL a requirement for moderate to high clock
rates.

pbmueller@my-deja.com wrote:
> 
> What I have done in a Lucent (OR3T80) design is to disable the clock as long
> as the GSR is asserted (and a few cycles longer). This should also be
> possible in the virtex parts, but... -The BUFG primitive does not show the CE
> (Clock Enable)  input of the elemet, that can be seen in the FPGAEditor -If
> one creates a macro that allows to access the CE signal, this only works when
> you do not use a DLL (This is because of a bug of the Alliance 3.2i software,
> that does not handel the XIL_MAP_ALLOW_ANY_DLL_INPUT variable as it
> should...and stops with an error)
> 
> Patrick
> 
> In article <3A27369A.BDF76883@andraka.com>,
>   Ray Andraka <ray@andraka.com> wrote:
> > Use GSR to initialize all your FF's, but then have only one point in your design
> > depend on when the GSR is released.  For example, use a synchronized version of
> > GSR to hold a master state machine in reset after GSR is released, then after
> > GSR is safely gone away let the thing start going.
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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: 27681
Subject: pcmcia host controller ??
From: "chris.wei" <chris.wei@philips.com>
Date: Sat, 02 Dec 2000 12:12:20 +0800
Links: << >>  << T >>  << A >>
Hi,

I am looking for a synthesizable non-commercial / open source pcmcia
host controller for quick  prototyping purpose.  Any suggestions.

Regards,
Chris


Article: 27682
Subject: Re: DLLs driving DLLs in Virtex.
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Fri, 01 Dec 2000 20:35:48 -0800
Links: << >>  << T >>  << A >>

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

Hello Dan,

Its possible to connect two DLLs in series to generate a 4x clock. Each DLL has
+/- 60ps jitter and this may be accumulated or compensated across both DLLs.
Just make sure the external input clock doesn't have any jitter, as this would
be propagated through the DLLs. Other than this, the  4x clock will be stable
and does not loose lock unless  one of the DLL is reset or the input clock
frequency changes.

You can refer XAPP132: Using the Virtex Delay-Locked Loop available at
http://support.xilinx.com/apps/virtexapp.htm

This app. note explains details on generating 4x clock with two DLLs and other
DLL applications. Also refer Virtex datasheet for DLL specs.

-Vikram
Xilinx Applications





Dan wrote:

> Hello,
>
> Is is possible to drive the input of a DLL with the output of another DLL ?
>
> I need to multiply by 4. A DLL will only multiply by 2.
>
> Will the resultant 4X clock have poor characteristics if I do this?
> (unstability/ bad jitter/ loss of lock ......) ?
>
> Also, I may want to use tw DLL to get multiply by 1.3333 ( 1st DLL 2X, 2nd
> DLL /1.5)
>
> Sincerely
> Daniel DeConinck
> High Res Technologies, Inc.

--------------64DBD04C3BE1155F277E6C3D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Dan,
<p>Its possible to connect two DLLs in series to generate a 4x clock. Each
DLL has +/- 60ps jitter and this may be accumulated or compensated across
both DLLs. Just make sure the external input clock doesn't have any jitter,
as this would be propagated through the DLLs. Other than this, the&nbsp;
4x clock will be stable and does not loose lock unless&nbsp; one of the
DLL is reset or the input clock frequency changes.
<p>You can refer <a href="http://support.xilinx.com/xapp/xapp132.pdf">XAPP132:
Using the Virtex Delay-Locked Loop</a> available at
<br><A HREF="http://support.xilinx.com/apps/virtexapp.htm">http://support.xilinx.com/apps/virtexapp.htm</A>
<p>This app. note explains details on generating 4x clock with two DLLs
and other DLL applications. Also refer Virtex datasheet for DLL specs.
<p>-Vikram
<br>Xilinx Applications
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Dan wrote:
<blockquote TYPE=CITE>Hello,
<p>Is is possible to drive the input of a DLL with the output of another
DLL ?
<p>I need to multiply by 4. A DLL will only multiply by 2.
<p>Will the resultant 4X clock have poor characteristics if I do this?
<br>(unstability/ bad jitter/ loss of lock ......) ?
<p>Also, I may want to use tw DLL to get multiply by 1.3333 ( 1st DLL 2X,
2nd
<br>DLL /1.5)
<p>Sincerely
<br>Daniel DeConinck
<br>High Res Technologies, Inc.</blockquote>
</html>

--------------64DBD04C3BE1155F277E6C3D--


Article: 27683
Subject: Re: glbl
From: chsw <chen.songwei@mail.zte.com.cn>
Date: Sat, 2 Dec 2000 02:03:45 -0800
Links: << >>  << T >>  << A >>
Hello:
  But,the type of software i use is
Foundation2.1,after i synthesis the project on PC ,it will creat a "time_sim.v" file.I translate it to Sun Sloaris Workstation .Finally,i use NC-VERILOG to simulate it.The questio i
mentioned will occrue.How do i?
 Thanks a lot

Article: 27684
Subject: Column on FPGAs
From: peter_raeth@juno.com
Date: Sat, 02 Dec 2000 18:06:20 GMT
Links: << >>  << T >>  << A >>
FPGAs are the subject of my latest column on adaptive systems. This
column appears every two weeks in eChips’ ChipCenter. The current
column appears at the second URL below. Click on the “more” link to see
the entire column. The first URL below is my general site on adaptive
automation.


Best,

Peter.

Peter G. Raeth
Computer Engineer, Specialist in Adaptive Systems
peter_raeth@juno.com
http://www.geocities.com/siliconvalley/lakes/6007
http://www.chipcenter.com/eexpert/praeth/main.html



Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27685
Subject: Re: Routing constraints & A2.1i
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Sat, 02 Dec 2000 22:06:51 +0200
Links: << >>  << T >>  << A >>
mmeraliuk@yahoo.co.uk wrote:

> Does anyone know of a way to prevent Xilinx A2.1i PAR from routing
> through a particular CLB's routing resources?
>
> Cheers,
> matthew.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

I don't know if the tool still uses the routing resource of a definite
area, but it is possible to hinder the placement process of PAR
from using a definite area to place the logic: Use PROHIBIT.
Look at the manuals how to use it efficiently.

By the way, switch to A3.x ASAP, ow you won't get much help
from around!!

Utku

--
I feel better than James Brown.




Article: 27686
Subject: Re: Virtex ROM ques.
From: Neil Franklin <neil@franklin.ch.remove>
Date: 02 Dec 2000 23:08:08 +0100
Links: << >>  << T >>  << A >>
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:

> Phil James-Roxby <phil.james-roxby@xilinx.com> writes:
> > You could use JBits to do this.  On the main Xilinx web site, go to
> > products -> System solutions -> Xilinx Online and there is a little
> > description of JBits.

The page I visited (did search for jbits from search page) was:

http://www.xilinx.com/products/software/jbits/index.htm
JBits SDK


> Sounds nifty.

Is nifty. As far as what I have read in its documentation, since
installing it last wednesday. Now I just need time to use it ...


>It says "JBits will be available over the web in 1Q99."
> But I can't seem to actually find it.  Any hints?

Mail to the address given on the page (JBits@xilinx.com). They then
send you an URL (actually 3 URLs, Windows NT, Solaris, Linux) plus
password. Then download (9MByte), install and have fun.


Greetings from another a.f.c-er. Looks like JBits and an XCV300 are
going to be the base of some historic computer cloning...

--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic

Article: 27687
Subject: Re: glbl
From: Srinivasan Venkataramanan <srini@realchip.com>
Date: Sun, 03 Dec 2000 10:03:31 +0530
Links: << >>  << T >>  << A >>
Hi,
  I haven't used Foundation Series, but I have used the latter one. 


chsw wrote:
> 
> Hello:
>   But,the type of software i use is
> Foundation2.1,after i synthesis the project on PC ,it will creat a "time_sim.v" file.I translate it to Sun Sloaris Workstation .

  What do you actually mean by "translate" - guess you do an FTP or so
(to "transfer" your file from PC to UNIX) - Am I correct?

If so "transfer" also the file named " $XILINX/verilog/src/glbl.v " to
UNIX (and remove Control-M s if reqd) and try what Paulo suggested
i.e.

ncvlog -update $XILINX/verilog/src/glbl.v <testfixture>.v time_sim.v 
ncelab -messages -autosdf testfixture_name glbl 
ncsim -messages testfixture_name 

HTH,
Srini

-- 
Srinivasan Venkataramanan (Srini)
ASIC Design Engineer,
Chennai (Madras), India

Article: 27688
Subject: Re: glbl
From: chsw <chen.songwei@mail.zte.com.cn>
Date: Sat, 2 Dec 2000 23:52:26 -0800
Links: << >>  << T >>  << A >>
Hello:
  what is the "testfixture"?
  I try to do it according to what you said,but the error occrued:
 " ncelab:*W,SDFNCS:Not a compiled SDF file :time_sim.sdf-compiling it.......
   ncelab:*E,CUVMOT(./pos_bench.v,15|25):illegal output  ports specification.
  test_convert my (reop,tenb,rx_err........tx_pa0,
  why? how do i?
  is it right?
  "ncvlog -update /opt/cadence/src/glbl.v /opt/cadence/src/simprims/*.v pos_bench.v
time_sim.v -line -mess
   ncelab pos_bench glbl -autosdf -access+rcw-mess
   ncsim pos_bench -gui -mess &
   Thanks a lot!

Article: 27689
Subject: Issues with Spartan II
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sun, 03 Dec 2000 04:31:22 -0500
Links: << >>  << T >>  << A >>
I am starting a new board design where I wanted to use the SpartanII
FPGAs. But I am not sure if I should continue with these parts or change
to another. According to a January press release, the SpartanII chips
were supposed to be in full production "within the current quarter".
Here it is nearly a year later and they are still not listed as being
readily available at distributors. The latest data sheet (Nov 2, 2000)
is still labeled as "Preliminary". 

The other problem I have is with the high startup current these parts
require. I need to be able to sell these boards for an industrial (-40C
to 85C) temp range. At startup in this range, the four parts on this
board will require 2 amps from the 2.5 volt supply. Otherwise this
supply only needs to be built to handle 1 amp including power to spare.
I have seen several posts here that seem to indicate that the startup
current requirement may be spec'd a little more tightly when these parts
are in fully qualified. 

Does anyone have an idea of when these parts will be fully qualified and
in full production? I have been burned before trying to use parts that
are new and not available. But these parts are "just what the doctor
ordered" other than these two issues. 

I know that Lucent has no plans for product to compete with SpartanII at
the low end. Does anyone know if Altera is introducing a similar low
cost, high density family of parts? 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 27690
Subject: Re: Hey there anybody!!
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 03 Dec 2000 10:07:44 +0000
Links: << >>  << T >>  << A >>


InGenius Engineering wrote:

> Hi there,
>
> My name is Ellen Ann Nichol and I am a recruiter...before you spam me..I am
> not hear to use this posting board to recruit FPGA people. Since I have a
> dire need for FPGA people, I only wanted to know if people could send me
> suggestions on how to recruit you guys.  Call it a survey if you like.  If
> you were looking for a job where would you look? Do you go to certain web
> sites? That sort of thing. Any tips would be greatly appreciated.
>
> ellen@ingeniusengineering.com

Tip #1 :-

Avoid all the usual BS words like ``dynamic'', ``innovative'',
``leading-edge'', etc. etc. These are usually a substitute for not being able
to name the company. If you can't name it just say so.

Just tell us what the job's about I we'll work out whether its ``dynamic'',
``exciting'', etc enough for us.

Tip #2 :-

Don't be coy about the numbers of $$$, £££, YYY, EEE etc.

Tip #3 :-

Remember that if you do try & recruit via the NGs then you're likely to be
talking to some seriously battle-hardened digital designers who really don't
appreciate being talked down to. If you want recent examples of what happens if
you don't follow this rule look up the ``Very Lucrative FPGA jobs'' and ``Long
Island Verilog'' threads on dejanews.



Article: 27691
Subject: Re: Issues with Spartan II
From: Nial Stewart <nials@sqf.hp.com>
Date: Sun, 03 Dec 2000 11:30:44 +0000
Links: << >>  << T >>  << A >>
Rick Collins wrote:
> 
> 
> I know that Lucent has no plans for product to compete with SpartanII at
> the low end. Does anyone know if Altera is introducing a similar low
> cost, high density family of parts?
> 
> --
> 
> Rick "rickman" Collins

Rick,

I haven't seen a data sheet for one, but I believe the Altera Acex
family are targeted at this market.

Might be worth a look.

Nial.

Article: 27692
Subject: Re: Issues with Spartan II
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sun, 03 Dec 2000 18:28:55 GMT
Links: << >>  << T >>  << A >>
On Sun, 03 Dec 2000 04:31:22 -0500, Rick Collins
<spamgoeshere4@yahoo.com> wrote:

>I am starting a new board design where I wanted to use the SpartanII
>FPGAs. But I am not sure if I should continue with these parts or change
>to another. According to a January press release, the SpartanII chips
>were supposed to be in full production "within the current quarter".
>Here it is nearly a year later and they are still not listed as being
>readily available at distributors. The latest data sheet (Nov 2, 2000)
>is still labeled as "Preliminary". 
>
>The other problem I have is with the high startup current these parts
>require. I need to be able to sell these boards for an industrial (-40C
>to 85C) temp range. At startup in this range, the four parts on this
>board will require 2 amps from the 2.5 volt supply. Otherwise this
>supply only needs to be built to handle 1 amp including power to spare.
>I have seen several posts here that seem to indicate that the startup
>current requirement may be spec'd a little more tightly when these parts
>are in fully qualified. 
>
>Does anyone have an idea of when these parts will be fully qualified and
>in full production? I have been burned before trying to use parts that
>are new and not available. But these parts are "just what the doctor
>ordered" other than these two issues. 
>
>I know that Lucent has no plans for product to compete with SpartanII at
>the low end. Does anyone know if Altera is introducing a similar low
>cost, high density family of parts? 

I did a PCI design with Spartan II and had similar issues. Actually
Spartan II is available but lead time is a little bit long. My client
managed to get 5 samples in two weeks and ordered 200 to be delivered
2 months. This was 3 months ago. Now they are going to production and
expecting delivery of more parts. I think just a little patience after
placing your order is needed here.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 27693
Subject: Re: Xilinx Coolrunner going on last time buy?
From: z80@ds2.com (Peter)
Date: Sun, 03 Dec 2000 20:05:11 +0000
Links: << >>  << T >>  << A >>

>It is true that Xilinx has had to shorten the lifecycle of the 'legacy' Philips
>parts due to lack of fab capacity.  As you probably know, Xilinx has strategic
>partnerships with a couple of fabs, but unfortunately not with the fabs where
>these devices are manufactured.  

Which Xilinx knew when they took over the line...

>Hence the end of life notice.  

Which should have been issued the day Xilinx took it over, frankly.

>It has always
>been in the plans to move the newest CoolRunner XPLA3 family to a strategic fab
>partner, and that is in the works now. 

Except there will be no continuity of the PxZ22V10 which is a very
useful and well priced device. Bye to Xilinx - I am designing them out
as I write. Fortunately I have other options.


Peter.
--
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.

Article: 27694
Subject: which I/O pin belongs to each bank
From: gazit@my-deja.com
Date: Sun, 03 Dec 2000 22:24:47 GMT
Links: << >>  << T >>  << A >>
Hi,
I am working on a new design , using XCV400-BG560.
How can I find out (except looking at the Pin-out symbol diagram) which
I/O pin belongs to each of the banks ?
Is there a source for Orcad symbols for Virtex family parts or do I
need to generate my own ?.
Thanks,
Rotem.


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27695
Subject: Re: Hey there anybody!!
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Mon, 04 Dec 2000 02:14:39 GMT
Links: << >>  << T >>  << A >>

"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3A2A1B70.4E87C014@algor.co.uk...
> Tip #2 :-
>
> Don't be coy about the numbers of $$$, £££, YYY, EEE etc.

I wouldn't discuss $$$ on the Internet.  Everyone is in a different
situation and the money will be different based on several factors,
including the actual job and expertise involved.  If you discuss money and
the money is good, expect the lowly types to respond immediately wanting
that rate.  If the money is bad, expect no one to respond.  In general, I
feel that the parties should "feel" each other out before discussing money.
If you throw money on the Internet, expect used car salesmen that surf the
Internet to suddenly change careers and respond.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.




Article: 27696
Subject: Re: Issues with Spartan II
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Sun, 03 Dec 2000 23:53:12 -0500
Links: << >>  << T >>  << A >>
Nial Stewart wrote:
> 
> Rick Collins wrote:
> >
> >
> > I know that Lucent has no plans for product to compete with SpartanII at
> > the low end. Does anyone know if Altera is introducing a similar low
> > cost, high density family of parts?
> >
> > --
> >
> > Rick "rickman" Collins
> 
> Rick,
> 
> I haven't seen a data sheet for one, but I believe the Altera Acex
> family are targeted at this market.
> 
> Might be worth a look.
> 
> Nial.

Thanks Nial,

Yes, I found that today. I have never used Altera parts before, but I
took a look today and found that the Acex family is just what I wanted. 

Altera uses a different approach to compatibility. Rather than put the
different chips in the same package, they also use footprint compatible
FBGAs which allow you to put down the largest footprint you think you
may need. You can then use any of the smaller FBGAs in the same
footprint. I have not checked the pinouts in detail, but they seem to
advertise this pretty loudly. 

The pricing looks good. The Acex chips similar to the SpartanII chips I
was going to use have the same total price. But I will be looking hard
at the startup current issues as well as availabilty. 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 27697
Subject: Re: Issues with Spartan II
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Mon, 04 Dec 2000 00:04:54 -0500
Links: << >>  << T >>  << A >>
Muzaffer Kal wrote:
> 
> On Sun, 03 Dec 2000 04:31:22 -0500, Rick Collins
> <spamgoeshere4@yahoo.com> wrote:
> >Does anyone have an idea of when these parts will be fully qualified and
> >in full production? I have been burned before trying to use parts that
> >are new and not available. But these parts are "just what the doctor
> >ordered" other than these two issues.
> >
> >I know that Lucent has no plans for product to compete with SpartanII at
> >the low end. Does anyone know if Altera is introducing a similar low
> >cost, high density family of parts?
> 
> I did a PCI design with Spartan II and had similar issues. Actually
> Spartan II is available but lead time is a little bit long. My client
> managed to get 5 samples in two weeks and ordered 200 to be delivered
> 2 months. This was 3 months ago. Now they are going to production and
> expecting delivery of more parts. I think just a little patience after
> placing your order is needed here.
> 
> Muzaffer
> 
> FPGA DSP Consulting
> http://www.dspia.com

I can't take a chance with 2 month lead times. When I get an order for
boards, I can't quote a three or four month lead time because I have to
wait 2 months or more for FPGAs. The order will vanish! 

If the chips are being built as production parts, why are November data
sheets still labeled "Preliminary"? 



-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 27698
Subject: Re: Issues with Spartan II
From: Nial Stewart <nials@sqf.hp.com>
Date: Mon, 04 Dec 2000 08:33:52 +0000
Links: << >>  << T >>  << A >>
Rick Collins wrote:
> 
> Nial Stewart wrote:
> >
> > Rick Collins wrote:
> > >
> > >
> > > I know that Lucent has no plans for product to compete with SpartanII at
> > > the low end. Does anyone know if Altera is introducing a similar low
> > > cost, high density family of parts?
> > >
> > > --
> > >
> > > Rick "rickman" Collins
> >
> > Rick,
> >
> > I haven't seen a data sheet for one, but I believe the Altera Acex
> > family are targeted at this market.
> >
> > Might be worth a look.
> >
> > Nial.
> 
> Thanks Nial,
> 
> Yes, I found that today. I have never used Altera parts before, but I
> took a look today and found that the Acex family is just what I wanted.

> The pricing looks good. The Acex chips similar to the SpartanII chips I
> was going to use have the same total price. But I will be looking hard
> at the startup current issues as well as availabilty.


One thing to look out for with Altera devices/tools is unused pins. 

With the Xilinx tools if a pin in unused it is tri-stated, but with
the Altera tools it's arbitrarily connected to an internal net and 
driven out.

It is therefore _not_ a good idea to build a design in incremental
stages incorporating more pins/functionality as you go. You must
define all used pins (in your code and .acf file) right from the 
start then the Altera tools will tri-state them if unused.

I was bitten by this when mainting someone elses design. For some
reason on of the uP address input pins had been commented out of the
code as it wasn't being used for address decoding. As this wasn't
used the tools cnnected it to a net and drove it out, where it
was driving against the uP. This worked for a while, then fell over
and took ages to track down. Uncommenting the unused input fixed the
problem.

Nial.

Article: 27699
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: john_stiekema@my-deja.com
Date: Mon, 04 Dec 2000 08:48:56 GMT
Links: << >>  << T >>  << A >>
I have a similar problem. I would like to change a table in EEPROM and
still have the CRC verify correctly.

It should be possible to provide an additional dummy table with some
"CRC correction bytes", which would bring the CRC back to the original
value, so that the table data could be modified as desired, provided
that the appropriate "correction bytes" are also modified.

Question is, how does one go about determining rules to generate the
correction bytes, for any given table data?

I assume that at least the following information would be required:
- Initialisation CRC (CRC calculated to beginning of table)
- Static bytes between table and dummy table, assuming dummy table does
not directly follow the first table in memory.
- Initial bytes in table, and dummy table

Any ideas, Herman?


In article <3A28514B.7F695805@AerospaceSoftware.com>,
  Herman Oosthuysen <aerosoft@AerospaceSoftware.com> wrote:
> Well, you can run a CRC forwards and reverse.  The reverse is actually
a
> different polynomial.  See DSP Guru for the trick, but basically you
> just take the (order - power) for each term to get the other
> polynomial.  You should be able to use this info to gen a CRC patch -
I
> dunno how though, but I think it would be workable.  If you get
> completely stuck, drop me some mail, I know a few tricks.
>
> Cheers,
>
> Herman
> http://www.AerospaceSoftware.com
>
> Marc Warden wrote:
> >
> > Michael Barr wrote:
> >
> > > 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.
> > >
> > > A ZIP file containing just the source code for the CRC routines is
at:
> > >
> > >         http://www.netrino.com/Connecting/2000-01/crc.zip
> > >
> > > The code is placed into the public domain and may be used for any
purpose
> > > public or private.  There are some limitations in its use (it's
written
> > > in C), but the underlying algorithms are solid and could be ported
to the
> > > assembly language (or hardware) of your choice if necessary.
> > >
> > > Enjoy,
> > >         Michael Barr
> >
> > Hi Michael.
> >
> > Question for you: Have you ever come across a method in a CRC of
removing a
> > byte, word, or long from the block of data, changing it (on purpose)
and
> > putting it back into the block of data (in its same location) and
then
> > modifying the CRC and if the CRC is checked it will check out OK?
> >
> > That is, I don't want to have to modify the data location and then
> > recalculate the CRC on the whole block of data, but would like to
have the
> > CRC verify.
> >
> > The data is code being run in 'real time' and because it was written
for one
> > processor but being run on a new processor (the code is down loaded
into the
> > new processor's address space) and before the data/code is run, it
is patched
> > to address some instruction differences between teh original CPU
target vs.
> > the new one.
> >
> > Right now I'm patching the code/data and have disabled CRC checking
(because
> > I know it will fail and cause the system to halt any further
processing) but
> > I would like to (if possible) re-enable CRC checking (to catch
unententional
> > changes to the code/data) but have the checking insensitive to
intentional
> > changes to a few locations in the code/data.
> >
> > I know I know. No matter how I put it, it sounds goofy...
> >
> > Sincerely,
> >
> >  MarcW. (And it is.)
>


Sent via Deja.com http://www.deja.com/
Before you buy.



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