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 29725

Article: 29725
Subject: Re: SRAM fpga cell
From: "Bedrich Pola" <pola@asix.cz>
Date: Tue, 6 Mar 2001 08:16:48 -0800
Links: << >>  << T >>  << A >>
Does Xilinx plan to use the single transistor SRAM? See <www.mosysinc.com> for more info about it.

Article: 29726
Subject: Re: Virtex USB solution
From: "Felix Bertram" <fbertram@gmx.net>
Date: Tue, 6 Mar 2001 18:00:30 +0100
Links: << >>  << T >>  << A >>
Andy,

----- Original Message -----
> > I will probably shock someone somewhere, but I agree with you.  There
> > are some things that are so well entrenched, so ubiquitous, and/or so
> > screwey to implement (perhaps intentionally), that FPGA's are not
> > even a realistic consideration.  The ASIC is just too cheap and easy
> > not to use.

this is true for most cases (so does not shock me). But the moment you
cannot find a chip that is dedicated to your specific application things may
look different, audio could be an example here.

Assume the TUSB3200 did not exist (or is buggy). You would switch to
something different, e.g. an AN2131 (which is truly more expensive). You
would add your audio functionality to it, basically shift registers and
FIFOs. This is the moment you begin thinking about adding an FPGA to your
design. Next you would start to move all your surrounding logic into the
FPGA, as this makes better usage of a component that is already on your
board. The IEC958 output gives you your first $4, which is already about a
third of your Spartan-II. As an 8051 is not too good in moving data around
you wish you could interface your audio FIFO directly to the endpoint. So
one could imagine using a PDIUSBD12, a little bit more FPGA and a standard
8051- if it only had more endpoints... which brings you to your own USB
implementation (as 200/768 slices are only $3.20). And at the same time your
product management approaches you to add some fancy level meters. And
finally you have a pricing that is very competitive to a solution based on
the TUSB3200 again. But you are right- it is not the same lean and mean
very low-cost design it was in the beginning.

Products are distinguished either by features or by pricing. Sometimes you
want a product, that adds a little bit to "what everybody is doing". And
here your off-the-shelf ASIC may create a lot of headaches.

> Methinks it's a case of "if the only tool available is a hammer,
> everything starts to look like a nail."

I think there are two different situations here:
a) Do I use an FPGA or not?
b) Do I add another chip or upgrade to a larger FPGA?

And the latter scenario boils down to the following questions:
i) Do I have the time to invent Intellectual Property?
ii) Can I effort buying Intellectual Property?



Best regards


Felix Bertram
_____
Dipl.-Ing. Felix Bertram
Trenz Electronic
Duenner Kirchweg 77
D - 32257 Buende
Tel.: +49 (0) 5223 41652
Fax.: +49 (0) 5223 48945
Mailto:felix.bertram@trenz-electronic.de
http://www.trenz-electronic.de



Article: 29727
Subject: Re: SRAM fpga cell
From: "Tim Boescke" <t.boescke@tu-no-spam-harburg.de>
Date: Tue, 6 Mar 2001 18:01:49 +0100
Links: << >>  << T >>  << A >>

> Does Xilinx plan to use the single transistor SRAM? See <www.mosysinc.com> for
more info about it.

About about checking out the page byself ?

The mosys 1T sram is dram with a clever refresh scheme. Nothing that could
be used in a FPGA.




Article: 29728
Subject: Re: Full Time - No contractors
From: steve (Steve Rencontre)
Date: Tue, 6 Mar 2001 18:45 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <neYo6.602$lt4.323371@paloalto-snr1.gtei.net>, chilln@gte.net 
(Embedded Head) wrote:

> Company song, hmmm, yes I can see it now......while they're doing their 
> ergo
> exercises
> "Shift to the left, shift to the right"
> "Push down, pop up"
> "Byte, byte, byte"
> 
> Thanks for the idea, see, you consultants really are smart fellers

My fee for suggesting the company song idea is $10,000. How would Sir like 
to pay?

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 29729
Subject: Re: Bad Xilinx bitstream=big bang?
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Tue, 06 Mar 2001 19:43:02 +0000
Links: << >>  << T >>  << A >>
On Mon, 05 Mar 2001 18:06:41 GMT, krw@btv.ibm.com (Keith R. Williams)
wrote:

>On Mon, 05 Mar 2001 17:31:38 +0000, Brian Drummond
><brian@shapes.demon.co.uk> wrote:
>
>>On 03 Mar 2001 15:44:07 -0800, Eric Smith
>><eric-no-spam-for-me@brouhaha.com> wrote:
>>
>>>Peter Alfke <palfke@earthlink.net> writes:
>>>> The gist is:
>>>> Virtex parts do check for CRC errors, but not for formatting errors. And you
>>>> sent a legitimately CRC-protected file, just the wrong format... Horrendous
>>>> amount of internal contention.
>>>[...]
>>>> Correct. If there were a CRC error, the part would recognize this. But there
>>>> was no CRC error...
>>>
>>>Is there some reason why the part doesn't ALSO recognize that the bitstream
>>>is too short?  I wouldn't think it would expect the CRC until it had filled
>>>all of the RAM cells.
>>>
>>Anything to do with partial reconfiguration maybe?
>>Like, is it possible to generate a _valid_ short bitstream to reprogram
>>part of the device but leaving the remainder unchanged?
>
>Perhaps you've just stepped on another reason the tools don't support
>partial reconfiguration? Two _valid_ short bitstreams may create many
>drivers on the same wire.

Ouch! The Virtex-II device ID feature can't protect against THAT one!
I'm not sure anything can. Except maybe some design rule checker running
on the set of placed/routed NCD files prior to bitfile generation.
Doesn't look like an easy problem.

- Brian


Article: 29730
Subject: US-AZ-Senior ASIC/FPGA Designer - 3+ years experience
From: "Shawn Aker" <shawn_aker@yahoo.com>
Date: Tue, 6 Mar 2001 12:47:09 -0700
Links: << >>  << T >>  << A >>
This is a Senior level position needed. Please send me your resume to be
consider for this Senior Level position in an amazing company with good
benefits.

Senior Engineer

ASIC Design
Education Required:
BS/MS in Electrical or Computer Engineering
3+ years experience
Responsibilities:
Digital Subsystem/ASIC/FPGA detailed logic design
Synthesiable VHDL/Verilog model design
Scripts and utilities development
Provide sales support
Required:
Ability to express logic in synthesizable VHDL or verilog
Firm understanding of the transformation go RTL code into gates
ASIC or FPGA design experience
Understanding of high-speed and sub-micron design issues
Excellent analytical and communication skills
Highly motivated self starter, well organized
Solaris or Windows-NT
Preferred:
BIST
Test complier
Fault Grading
Test generation
Firmware / Assembly
CMDA / TDMA
Digital PLL design
Clock tree Design
DMA design
1394
802.3
FIFO design
Bus interface design
Datapump design
>100k gates
Sub-miron experience
FPGA - Xilina or Altera




Article: 29731
Subject: US-AZ-Principal ASIC Designer - 10+ years experience
From: "Shawn Aker" <shawn_aker@yahoo.com>
Date: Tue, 6 Mar 2001 12:48:41 -0700
Links: << >>  << T >>  << A >>
This is a leading position in which you report to the director of
Engineering for an up and coming company.  You would be
the main player and supervisor for this Phoenix based company.  Please email
me your resume.  If you know someone
interested in this job please forward it on to the right person.  This is an
amazing opportunity.

Principal Engineer ASIC Design

Education:
BS/MS in Electrical or Computer Engineering
10+ years experience

Responsibilities:
Project technical guidance and leadership
Digital system architecture development & partitioning
HW vs. SW partitioning
Digital subsystem/ASIC/FPGA detailed logic design
Synthesizable VHDL/Verilog model design
Scripts and utilities development
Provide sales support
Write proposals
Manage projects on time and budget schedules

Desired Skills:
Ability to express logic in synthesizable VHDL or verilog
Firm understanding of the transformation of RTL code into gates
ASIC or FPGA design experience
Project planning and leadership experience
Understanding of high-speed and sub-micron design issues
Excellent analytical and communication skills
Highly motivated self starter, well organized
Solaris or Windows-NT

Preferred:
BIST
Test complier
Fault Grading
Test generation
Firmware / Assembly
CMDA / TDMA
Digital PLL design
Clock tree Design
DMA design
1394
802.3
FIFO design
Bus interface design
Datapump design
>100k gates
Sub-miron experience
FPGA - Xilina or Altera

Required tool experience
Synopses design Complier
VHDL simulation (Modelsim, Speedwave) or
Verilog simulation (Chronologic, Cadence)

Preferred:
C++,Perl, TCL/tk, Logic Analyzers,ICE, DSO, Performace Analyers,
Viewlog, Mentor Graphics




Article: 29732
Subject: Again Spartan II power
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Tue, 06 Mar 2001 21:50:10 +0100
Links: << >>  << T >>  << A >>
Please dont cry folks ;-)

I ran through the preveous thread and have still some questions.
We have a hot-swapable card and to prevent big surge currents we have to
use a very slow powerup ramp (250ms are planned).
Is this a problem for the Spartan II?? The powersupply can delviver far
more than 500mA but not that fast as required in the datasheet (50ms).
Another question is about the Vcoo and Vcint timing relation.
How critical is it (Vcoo must be above 1V when Vcint crosses 1.6V (POR)
).

-- 
MFG
Falk

Article: 29733
Subject: Is there any Virtex-II Evaluation Board?
From: "Juan M. Rivas" <jmrivas@media.mit.edu>
Date: Tue, 06 Mar 2001 17:17:33 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------153262FA8A8693E02C0790D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just wondering....


Thanks all!

attn. Juan
--------------153262FA8A8693E02C0790D6
Content-Type: text/x-vcard; charset=us-ascii;
 name="jmrivas.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Juan M. Rivas
Content-Disposition: attachment;
 filename="jmrivas.vcf"

begin:vcard 
n:Rivas;Juan M.
tel;home:(617)255-1268
tel;work:(617) 253-5097
x-mozilla-html:FALSE
org:Media Lab, M.I.T.;Object Based Media
version:2.1
email;internet:jmrivas@media.mit.edu
title:Research Assistant
adr;quoted-printable:;;20 Ames Street=0D=0A;Cambridge;Massachusetts;02139;U.S.A.
fn:Juan M. Rivas
end:vcard

--------------153262FA8A8693E02C0790D6--


Article: 29734
Subject: Re: Parallel Port EPP
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 07 Mar 2001 11:47:18 +1300
Links: << >>  << T >>  << A >>
Marc Battyani wrote:
> 
> "Marc Reinert" <reinert@tu-harburg.de> wrote
> 
> > I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel
> > port (EPP-mode) of my PC.
> >
> > Is it a good style to react direct on the edges of the port signals (e.
> > g. adress/data strobes) or would it be better to use a fast PLD-Clock to
> > sample the port and then to evaluate the signals in a clocked logic?
> 
> I've done this in a Spartan device. You should synchronize the inputs to an
> internal clock and 2 flip-flops. (See the ongoing thread on Metastability).
> Then just use a state machine.
> 
> It works well but I coudn't make the EPP going faster than 750Kb/s under W2K
> (Dell I5000e PIII 700).

 We did a Parallel Port CPLD, and found similar speeds.
Certainly the std PC mode is limited to about 1uS per transaction, but 
we found that most EPP/ECP modes were also limited. 
 Mid last year we were told there were true PCI-ECP ( not
PCIpatch-ISA-ECP) 
comming 'real soon' that would offer a more usable speed, of 
some MegaBytes/Sec

 Has anyone seen these, or got a better speed spec for PC-parallel IO ?

-jg

Article: 29735
Subject: Re: School project
From: "OCR Bee" <info@expervision.com>
Date: Tue, 6 Mar 2001 14:49:59 -0800
Links: << >>  << T >>  << A >>
Hi,
ExperVision uses alogrithms to achieve recognition, and you can try a demo
at www.expervision.com
Good Luck
"Magali Oudard" <Magali.Oudard@ms.alcatel.fr> wrote in message
news:3AA4BFEA.28DC200D@ms.alcatel.fr...
> Hello everybody,
>
> my friend has to realize the implementation of an OCR algorithm in
> schematics or VHDL,
> with fondation or any other FPGA software.
>
> As a student he is in internship in the USA, and does not have easy
> access (beside work) to computer and internet.
>
> If somebody could give him (us) some clue for him to get started ?
> apparently a demo version of software is enough, but here are the
> questions :
>     1. Where can he download a free demo version of a good software ?
>     2. Where can he find a description of an OCR algorithm ?
>     3. Where can he find good documentation to program in VHDL ?
>
>
> Thank to evryone !
>
>
> (more detail description of the subject :
>         Make under fondation or other software for FPGA a development of
> a simulation in schematics or VHDL for the following problem :
>         OCR algorithm for one character on a matrix, dimensions from
> 10*10 to 500*500 points)
>



Article: 29736
Subject: More detailed Spartan II CLB drawings?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 06 Mar 2001 15:44:27 -0800
Links: << >>  << T >>  << A >>
Is there any document that gives more detailed logic drawings of
the Spartan II CLBs?  The description and diagram in the data sheet
are sort of, well, spartan.

I'm trying to figure out whether I can do certain things like
simultaneously route the carry out both to the carry-in of the CLB above
*and* to the GRM or to the CLB on the right.  Figure 3 in the data sheet
shows a slice, but it has big unexplained blocks like "Carray and Control
Logic".  Also, the possible routing choices for signals are not obvious.

The text talks about the F5 and F6 multipliexers, but they don't appear
in the drawing at all.

These details aren't considered proprietary trade secrets, are they?
That would make it hard for me to figure out how to best design for
this part.

Article: 29737
Subject: Re: More detailed Spartan II CLB drawings?
From: Chris Dunlap <cdunlap@xilinx.com>
Date: Tue, 06 Mar 2001 17:24:48 -0700
Links: << >>  << T >>  << A >>
You can always look in FPGA editor.  Nothing can be left out there.  If its
routed or routable, its there.

Chris

Eric Smith wrote:

> Is there any document that gives more detailed logic drawings of
> the Spartan II CLBs?  The description and diagram in the data sheet
> are sort of, well, spartan.
>
> I'm trying to figure out whether I can do certain things like
> simultaneously route the carry out both to the carry-in of the CLB above
> *and* to the GRM or to the CLB on the right.  Figure 3 in the data sheet
> shows a slice, but it has big unexplained blocks like "Carray and Control
> Logic".  Also, the possible routing choices for signals are not obvious.
>
> The text talks about the F5 and F6 multipliexers, but they don't appear
> in the drawing at all.
>
> These details aren't considered proprietary trade secrets, are they?
> That would make it hard for me to figure out how to best design for
> this part.


Article: 29738
Subject: Re: Virtex USB solution
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Tue, 06 Mar 2001 17:51:57 -0700
Links: << >>  << T >>  << A >>
Felix Bertram wrote:
> 
> Andy,
> 
> ----- Original Message -----
> > > I will probably shock someone somewhere, but I agree with you.  There
> > > are some things that are so well entrenched, so ubiquitous, and/or so
> > > screwey to implement (perhaps intentionally), that FPGA's are not
> > > even a realistic consideration.  The ASIC is just too cheap and easy
> > > not to use.
> 
> this is true for most cases (so does not shock me). But the moment you
> cannot find a chip that is dedicated to your specific application things may
> look different, audio could be an example here.
> 
> Assume the TUSB3200 did not exist (or is buggy). You would switch to
> something different, e.g. an AN2131 (which is truly more expensive). You
> would add your audio functionality to it, basically shift registers and
> FIFOs. This is the moment you begin thinking about adding an FPGA to your
> design. Next you would start to move all your surrounding logic into the
> FPGA, as this makes better usage of a component that is already on your
> board. The IEC958 output gives you your first $4, which is already about a
> third of your Spartan-II. As an 8051 is not too good in moving data around
> you wish you could interface your audio FIFO directly to the endpoint. So
> one could imagine using a PDIUSBD12, a little bit more FPGA and a standard
> 8051- if it only had more endpoints... which brings you to your own USB
> implementation (as 200/768 slices are only $3.20). And at the same time your
> product management approaches you to add some fancy level meters. And
> finally you have a pricing that is very competitive to a solution based on
> the TUSB3200 again. But you are right- it is not the same lean and mean
> very low-cost design it was in the beginning.
> 
> Products are distinguished either by features or by pricing. Sometimes you
> want a product, that adds a little bit to "what everybody is doing". And
> here your off-the-shelf ASIC may create a lot of headaches.
> 
> > Methinks it's a case of "if the only tool available is a hammer,
> > everything starts to look like a nail."
> 
> I think there are two different situations here:
> a) Do I use an FPGA or not?
> b) Do I add another chip or upgrade to a larger FPGA?
> 
> And the latter scenario boils down to the following questions:
> i) Do I have the time to invent Intellectual Property?
> ii) Can I effort buying Intellectual Property?

Felix,

I see your points.  In this case, since the TI part *does* exist (I'm
still waiting for my eval board, so "bugginess" is TBD), it makes a lot
more sense to go with that rather than roll my own into an FPGA.  Why? 
Because it does all of the hard stuff.  You mention the audio stuff --
that's what this part does.  It has digital audio CODEC ports (and the
clock generation!) on board, the audio ports are on endpoints.  The only
programming required is to set up source and destination for the
endpoints.  As data comes in from the PC, it's DMAed right out to the
audio interface -- no programming or overhead required.

If this part didn't exist, I'd use the Philips part, with built-in ADC
and DAC.

Believe me, I prefer to do FPGA designs.  But using this type of part
makes a whole lot more sense than trying to implement USB in an FPGA.  I
have the product concept nailed down, and I think the TUSB3200 is the
way to go.

-a

Article: 29739
Subject: Re: Actel's FPGA : A54SX32A
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Wed, 07 Mar 2001 01:06:38 GMT
Links: << >>  << T >>  << A >>
"Timothy R. Sloper" <trs@mpinet.net> wrote in message
news:TZ_o6.473$gF.156955@news2.aus1.giganews.com...
> Simon,
>
>     One feature Actel has in their antifuse parts that no SRAM parts have
to
> my knowledge is the ability to look at ANY node in the design during
normal
> system operation. This is done via Silicon Explorer. There is absolutely
no
> need to bring signals out to unused pins. As for the BGA/OTP relationship
> you described (chasing interconnect problems)... does that potential
problem
> not apply to any other technology implemented in a BGA? Xilinx would be as
> difficult, if not more diffcult, to chase down interconnect problems when
> using BGAs than any of the Actel antifuse parts.
>
> Also, the ProASIC (used to be Gatefield) parts are fully functional and
have
> in fact been shipping to select customers for quite some time. The delay
in
> delivery had nothing to do with function... yield has been the issue.
> ProASIC will be hitting distributors very soon (not just marketing BS).
>
> Tim

Tim,
     Apart from what Ray Andraka told you above, there is the problem of
OTP/BGA parts being used with sockets.  As the designs get bigger
functionally and with more balls, there is a tendacy not to get everything
right the first time.  Therefore, one will most likely have to take the part
off the board and replace it before one gets it right.  This is a pain in
the rear with BGA parts.  If one uses BGA sockets, then one will more likely
have more interconnect problems than with PQFP sockets.  If one doesn't have
BGA sockets, then one will have to remove and replace.  This can really wear
a board down.  My wife removes and replaces BGA parts for a living as part
of her work, and she says that the boards cannot handle too many cycles of
this activity.
     I feel is that Actel does have very good silicon, and Actel OTP parts
have their place in this world.  But for most designs, I do not feel that
OTP is a good idea.  If you don't believe me, then dig up some marketing
data and look at the FPGA market pie in terms of sales dollars or even
number of parts shipping.  You will find that OTP parts are a small slice of
that pie.  If you have that information, perhaps you can share it with us.
     I think that if Actel can get the ProASIC to market and it turns out to
be a good product, you will be a lot busier helping engineers out with that
product than with OTP product.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA




Article: 29740
Subject: Re: Full Time - No contractors
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Wed, 07 Mar 2001 01:09:53 GMT
Links: << >>  << T >>  << A >>

"Embedded Head" <chilln@gte.net> wrote in message
news:neYo6.602$lt4.323371@paloalto-snr1.gtei.net...
> Company song, hmmm, yes I can see it now......while they're doing their
ergo
> exercises
> "Shift to the left, shift to the right"
> "Push down, pop up"
> "Byte, byte, byte"
>
> Thanks for the idea, see, you consultants really are smart fellers

Embedded Head,
     Maybe you can adopt the company song called "Bad Company" by Bad
Company.  :)
Simon Ramirez, Smart Arss Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 29741
Subject: Re: Bad Xilinx bitstream=big bang?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 06 Mar 2001 19:19:40 -0800
Links: << >>  << T >>  << A >>
All,

When using the new Virtex II Internal Configuration Access Port (ICAP), one has to
also use the tools properly with the logic floorplanner, nailing down the separate
regions, and IO intefaces between the separate regions to be reconfigured.

We are on the "cutting edge" of providing the tools, the hardware, and the
methodologies, so this certainly isn't a smooth and easy process (yet).

The basic features are there (ICAP, floorplanner, etc).

There must be first the floor planning, and the identification of reconfigurable
regions (some systems architecture must go it first).

This is an exciting feature that has the universities all asking the right questions,
and hopefully ready to provide some answers to today's problems in reconfigurable
computing.

Austin

Brian Drummond wrote:

> On Mon, 05 Mar 2001 18:06:41 GMT, krw@btv.ibm.com (Keith R. Williams)
> wrote:
>
> >On Mon, 05 Mar 2001 17:31:38 +0000, Brian Drummond
> ><brian@shapes.demon.co.uk> wrote:
> >
> >>On 03 Mar 2001 15:44:07 -0800, Eric Smith
> >><eric-no-spam-for-me@brouhaha.com> wrote:
> >>
> >>>Peter Alfke <palfke@earthlink.net> writes:
> >>>> The gist is:
> >>>> Virtex parts do check for CRC errors, but not for formatting errors. And you
> >>>> sent a legitimately CRC-protected file, just the wrong format... Horrendous
> >>>> amount of internal contention.
> >>>[...]
> >>>> Correct. If there were a CRC error, the part would recognize this. But there
> >>>> was no CRC error...
> >>>
> >>>Is there some reason why the part doesn't ALSO recognize that the bitstream
> >>>is too short?  I wouldn't think it would expect the CRC until it had filled
> >>>all of the RAM cells.
> >>>
> >>Anything to do with partial reconfiguration maybe?
> >>Like, is it possible to generate a _valid_ short bitstream to reprogram
> >>part of the device but leaving the remainder unchanged?
> >
> >Perhaps you've just stepped on another reason the tools don't support
> >partial reconfiguration? Two _valid_ short bitstreams may create many
> >drivers on the same wire.
>
> Ouch! The Virtex-II device ID feature can't protect against THAT one!
> I'm not sure anything can. Except maybe some design rule checker running
> on the set of placed/routed NCD files prior to bitfile generation.
> Doesn't look like an easy problem.
>
> - Brian


Article: 29742
Subject: Re: Again Spartan II power
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 06 Mar 2001 19:28:22 -0800
Links: << >>  << T >>  << A >>
Falk,

We do not test every single part for any power on ramp exceeding 50 ms.

We have done characterization which shows you may have problems with ramps
longer than 100 ms because you can not keep the voltage generally increasing
through the critical power on trip point (POR).

Spartan II has no Vccint vs. Vcco sequence issues (either can be before the
other, and outputs remain tristate, and no current results on the Vcco).

Virtex E MUST have Vccint before Vcco to operate properly.  This is not true
of Virtex, or Spartan II.

I would work closely with your Xilinx FAE to characterize your application
to be sure you will have a reliable design across all corners.

We are in the midst of a respecification of Spartan II right now.

I have heard: longer ramps, current vs ramp rate, sequence issues,
non-linear ramps, and current vs device size all requested.

Have I missed anything?????

Thank you,

Austin

Falk Brunner wrote:

> Please dont cry folks ;-)
>
> I ran through the preveous thread and have still some questions.
> We have a hot-swapable card and to prevent big surge currents we have to
> use a very slow powerup ramp (250ms are planned).
> Is this a problem for the Spartan II?? The powersupply can delviver far
> more than 500mA but not that fast as required in the datasheet (50ms).
> Another question is about the Vcoo and Vcint timing relation.
> How critical is it (Vcoo must be above 1V when Vcint crosses 1.6V (POR)
> ).
>
> --
> MFG
> Falk


Article: 29743
Subject: Re: Is there any Virtex-II Evaluation Board?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 06 Mar 2001 19:29:08 -0800
Links: << >>  << T >>  << A >>
Juan,

Yes.  Contact me at austin@xilinx.com.

Austin

"Juan M. Rivas" wrote:

> Just wondering....
>
> Thanks all!
>
> attn. Juan


Article: 29744
Subject: Re: Bad Xilinx bitstream=big bang?
From: alfred fuchs <alfred.fuchs@siemens.at>
Date: Wed, 07 Mar 2001 12:19:55 +0100
Links: << >>  << T >>  << A >>
In October 1999 at the EXUS in Paris we made Xilinx aware of that self-destruct
feature of the Virtex series.
A second participant confirmed the phenomenon immediately.
Xilinx confirmed it about a week later.

Apparently they did not find a workaround.

Is anyone aware of a warning issued by Xilinx?

Alfred Fuchs
Siemens PSE PRO LMS







Peter (and Austin and Phil),

Here is my take (*please* correct me where I'm mistaken):

It sounds like there are two weaknesses in (at least)
some of the Xilinx device families that can lead to
catastrophic failures:

1.  Devices don't check the programming data stream
for a "match" of target device.  Thus, you can try to
program a Virtex 600E device with a Virtex 400E
configuration data stream, and the configuration data
will be accepted.

This "hole" allows the designer to make a mistake, and be
burned by it.  The workaround is, simply, to make sure that
your configuration files were compiled for the correct target
device; you screw up at your own peril.

2.  More ominous is that drivers for internal
multi-source busses are not disabled (tri-stated, if
you will) before and during the configuration and powerup
sequence, when the internal state of the device cannot be
controlled or specified by the designer.  I'm not sure there
is *any* workaround to this, short of a re-design of the FPGA die.

We need to understand the breadth of this problem (if the above
assessments are basically correct): which device families are
affected (afflicted), etc. etc.

I'm not posting this to cause alarm, but to distill the
issues at hand as clearly as possible, and avoid any FUD.

Rather than get excited, it would be good for all concerned
to await Xilinx's response which, if history is a guide, will be
an honest and open discussion of the facts, and which will provide
essential guidance to the design community.

Bob Elkind, eteam@aracnet.com


Article: 29745
Subject: Re: Parallel Port EPP
From: Marc Reinert <reinert@tu-harburg.de>
Date: Wed, 07 Mar 2001 12:32:52 +0100
Links: << >>  << T >>  << A >>
How should I use the two FF's to synchronize the strobes?

Here is my idea how it could work:

              |          |
Data  --/---->| Data Reg |---/--------------------> DATA
        8     |          |   8
CLK   -----------^

                        +------------|&|----------> CE
                        |             |
              |     |---+--->|     |  |
Strobe ------>| FF1 |        | FF2 |  |
              |     |        |     |O-+
CLK -------------^--------------^

I'll sample the strobe and data signals with the same clock. The strobe signal
is shifted through two FF's in series.
These two FF's generate the CE  (FF1 AND NOT FF2, rising edge) signal for the
outgoing data.

Is this what You mean?

V R wrote:

> I just started a nice long thread on exactly this subject. I think the
> unanimous opinion is to use *two* D-flip-flops hooked in series. For the
> EPP interface, since you have two strobes, you will have two sets of these
> dual flip-flops to synchronize with.
>
> Use a system clock to synchronize your incoming nAddressActive and
> nAddress Strobe through the dual flip-flops(one set of FFs per strobe); it
> helps a lot to use this same clock for your statemachine, so do that if
> possible.
>
> My design had one statemachine (with two states I think) to recognize the
> four-phase portion of the EPP interface, and then other statemachines to
> act on the data.
>
> Good luck!
> VR.
> (the above e-mail address is invalid).

I've no idea what's wrong with my email: reinert@tu-harburg.de

--
Marc




Article: 29746
Subject: Re: Netlis : Webpack Vs Foundation
From: Srinivasan Venkataramanan <srini@realchip.com>
Date: Wed, 07 Mar 2001 17:58:37 +0530
Links: << >>  << T >>  << A >>
Hi Thirumurgan,
	I haven't used Foundation series, but your problem seems to be more
general. If I understand you well, you have a Verilog netlist (from
Webpack) - right? (or EDIF may be). If so the issue of "compatibility"
SHOULD not arise as these are STANDARDS (though some tools may not
support full standard). When you say "lot of warnings" - can you
elaborate on that? What are they? Perhaps it says

"module DFF not found" etc.?  If so you will need to specify the
library file name to Foundation series tool (Check out their
documentation).

HTH,
Srini

thirumurugan wrote:
> 
> Sir,
>      Can netlist generated from Webpack ISE be loaded in Foundation Series 2.1 simulator. Is the netlist compatible. Iam synthesysing VHDL designs in Webpack and when i load the netlist in Foundation series simulator i am getting lot of warnings. should i make any settings in the environment settings.help me please.
> thanks in advance,stm.

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

Article: 29747
Subject: Re: ROM-based FSM implementation
From: Srinivasan Venkataramanan <srini@realchip.com>
Date: Wed, 07 Mar 2001 18:09:29 +0530
Links: << >>  << T >>  << A >>
Hi Balaji,
	

Balaji Krishnapuram wrote:
> 
<SNIP>

> 
> I use a library(BITLIB) which came along with my textbook("Digital system
> design using VHDL" by Charles Roth) to define bit, bit_vector etc instead of
> using the IEEE std_logic etc.
> 

  Strange, why would you need this BITLIB? - are you sure it is to
"define" bit & bit_vector data types? AFAIK they are already defined
in the STANDARD package (in STD library) - which is by default visible
to all VHDL code. Infact if you try defining your own bit, bit_vector
etc. this will cause ambiguity to a  VHDL compliant
simulator/synthesis.

So please check the BITLIB package and make sure you are using it
properly.
From a quick look at your code, you have a function "vec2int" which is
probably defined in this BITLIB. Again if you want to learn better
VHDL try using

IEEE.numeric_bit.all

package instead (then use to_integer(bit_vec) function)

HTH,
Srini


> Hope it helps:)
> 
> Balaji
> 

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

Article: 29748
Subject: Re: Programming a CPLD
From: "A. dhermies" <a.dhermies@esiee.fr>
Date: Wed, 7 Mar 2001 04:43:05 -0800
Links: << >>  << T >>  << A >>
I

i used the x-checker with xc9572PC44
and ..it doesn't work well.
JTAG is not good! (The IDcode is wrong!)
But the xchecker was good with a virtex...

I used my home made // cable, and it was the same... Even with a new chip!

Can the PC be the cause of this problem?

I don't think I have done mistakes on the board, and electric signals are visible on logic analyser...
Can someboy help me?
thank you.

Article: 29749
Subject: Re: Is there any Virtex-II Evaluation Board?
From: Jakab Tanko <jtanko@ics-ltd.com>
Date: Wed, 07 Mar 2001 13:31:36 GMT
Links: << >>  << T >>  << A >>
Juan,

There was a post in this newsgroup a few days back, I think
P.Alfke from Xilinx was saying that they made hundreds of
eval boards with the smallest (xc2v40) virtexII part for
their FAE's. Talking to one of these FAE's looks like a good idea!

jakab

Juan M. Rivas wrote:

> Just wondering....
> 
> 
> Thanks all!
> 
> attn. Juan
> 




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