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 65400

Article: 65400
Subject: Re: Image sensor?
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Tue, 27 Jan 2004 18:55:18 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Tue, 27 Jan 2004 11:18:07 -0500) it happened bob
<kmart@nospam.com> wrote in <gb3d105893fkahc14d6eh0veh62frit83g@4ax.com>:

>Hi I want to make a project that uses an image sensor (any perhaps a
>low power cmos from Micron or Kodak) connected to a FPGA (or CPLD).
>with the apropriate VHDL or Veralog code.
>
>Has anyone done this who would be willing to share there hardware
>and/or software designs to get me started?
>Or is there any examples on the web that I can explore?
>
>Martin
>mart NO inb SPAM AT magma DOT ca
>
>Remove the NO  SPAM and put no spaces.  Also replace the AT for @ and
>the
>DOT for .   
>
>or post replies
>
>Thanks
Somebody in Spain did a VHDL version of my mcam soft, uses the Creative
webcam II look for document: Sistemacapturaimagenfin.pdf
This webcam uses a 8052 processor to talk to the sensor itself.
So the fpga talks to the 8052.
The sensor is 4 bits bus with serial control, but I no longer have the
datasheet.
It is in Spanish.
This sensor is likely superceded by better ones.
http://www.home.zonnet.nl/panteltje/mcam/ for my C version.
The VHDL version will learn you how to emulate a PC parport....
I think, given the datasheet of the sensor, it is pretty straight forward.
Talking directly to the sensor eliminates such protocols as par port / usb,
whatever.
But you may still need that to send the data anywhere else...
JP

Article: 65401
Subject: Re: Avnet Virtex-II Pro Development Kit Help
From: AirJosh69@hotmail.com (AJ)
Date: 27 Jan 2004 10:55:43 -0800
Links: << >>  << T >>  << A >>
Clark,

Thanks for the information. I recently got the board and have been
playing with it. I agree with you that it was easy to get there demos
up and running, but I must say I am a litte confused when trying to
modify them.

For example I have the 2VP7 Pro chip and was looking at the PLB
external memory example. This code/data is in the I&D BRAM and thus
has limited space. I would like to modify the code to run in SRAM
which starts at 0x00000000 in their example. I was able to find the
start address location to modify, but how can you specific the data
location in memory? I would like the code to run in IBRAM and the data
to reside in SDRAM (or is it possible to use both DBRAM and SDRAM for
your data). Also do you or anyone else have any example programs
outside the ones they give you to help weed through some of these
issues.

Any help would be greatly appreciated.

AJ

"Clark Pope" <cepope@mindspring.com> wrote in message news:<KwXNb.10087$q4.8777@newsread3.news.atl.earthlink.net>...
> I have an Avnet board. It comes with evaluation versions of EDK and ISE. It
> comes with a compact flash card containing several demo .bit files. By
> default it boots into Linux but you can make it boot any one of several
> sample designs. It had everything I need and ran out of the box in about 10
> minutes.
> 
> The one bad thing is that all of the documentation comes on CDs. I ended up
> printing about 500 pages of material so I could leaf to info easily. Also,
> it would be nice if they posted the documents to the web.
> 
> "AJ" <AirJosh69@hotmail.com> wrote in message
> news:af0645be.0401160818.150fc01a@posting.google.com...
> > Hello FPGA users,
> >
> > I am thinking about purchasing the Avnet Virtex-II ProT Development
> > Kit and would like to find out if anyone is using it or has used it
> > recently. I want to make sure I am not missing anything. It seems like
> > it comes with all the tools, but I find it difficult to get a
> > straight/consistant answer sometimes from Avnet. My confusion lies in
> > the PowerPC tools and startup. I want to make sure that the board and
> > tools (ISE 6.1 Foundation and EDK) are sufficient to get going. I
> > don't need an RTOS for my project so I just want to be able to run my
> > code on the PowerPC either from external RAM or internal BRAM.
> >
> > Confusion is about the BOOT up process and wether I will have to write
> > alot of system level code. Can someone help me out or point me to a
> > document that might clear up my concerns.
> >
> > I would love to talk with someone that is currently using this
> > product. Please e-mail me.
> >
> > Thanks in advance,
> > AJ

Article: 65402
(removed)


Article: 65403
Subject: Re: Timing model for MultiTrack interconnects in Stratix?
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 27 Jan 2004 12:10:17 -0800
Links: << >>  << T >>  << A >>
Thanks, Paul, for the detailed answer. Very much appreciated.

If I understand the handbook correctly, each LAB can drive an R4 to
its left or right. But I haven't found out how many signals in total
can be driven on the various MultiTracks (ie. how wide are they?).

Also, does Altera have training courses that describe the architecture
to this level of detail? I understand most people are not concerned or
interested in it, so it may not be practical to have seminars on it.

-- Pete


"Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<g3kRb.52563$iLV.46589@twister01.bloor.is.net.cable.rogers.com>...
> Hi Peter,
> 
> The delay of the interconnect is both easy and complicated to give you.  The
> quick answer is yes, we know the average delay of these resources (see
> unofficial table below).  I'll enquire as to why we don't have delays or
> delay ranges specified in the data sheet.
> 
> The long answer is that the delay of a given resource in Quartus will vary
> due to a variety of reasons.
> - # of active fanouts along the line (usually 1-2, but could be high
> depending on route)
> - # of inactive loads long the wire (doesn't vary too much)
> - # of partially active loads -- these can happen when a two-stage mux has
> multiple 1st stage inputs turned on due to sharing of configuration RAM
> bits.
> - Distance traveled.  If you travel only four units along an R24 wire, you
> won't get the full RC delay due to resistive shielding of down-stream
> capacitance.
> - Edge rate of incoming signal.  This in turn is affected by the resource
> used previously -- a R24 -> R4 could have different edge rate than R4 -> R4.
> It will also be affected by that resource's loading.
> - Blocks passed.  An R4 wire that passes over four LABs will be different in
> length (physically) than an R4 that crosses an M4K block + three LABs.
> Also, a C4 wire next to a clock spine may have slightly greater loading than
> one between two LABs.
> - Exact wire used.  Two different R4 wires that appear identical in all
> these ways can have different timing due to what metal layer they are routed
> on or due to physical proximity to other wires being different.
> - Rising/falling transition.  Delay can vary depending on whether the input
> is a rising or falling transition.
> 
> Quartus will give you the right answer to routing delay.  All these factors
> do is make it a little more difficult to predict the precise delay you will
> see in advance of timing analysis.  The allocation of delay to a particular
> resource in a full routing path is somewhat arbitrary and depends on
> measurement points and how we choose to bin the delay.
> 
> The following data was extracted from the critical paths of a large number
> of typical user designs, and thus is representative of the types of paths
> that tend to occur on the critical path.  It is not the maximum nor minimum
> delay you will see on this type of resource.
> 
> Stratix -5 Routing Delays (Mux + Buffer + Wire):
> 
> R4           303 ps
> R8           373 ps
> R24          503 ps
> C4           467 ps
> C8           650 ps
> C16          525 ps
> LAB Line     463 ps
> LE Output   231 ps
> Local Line   353 ps
> 
> Regards,
> 
> Paul Leventis
> Altera Corp.

Article: 65404
Subject: Re: Which Environment for Xilinx Design?
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Tue, 27 Jan 2004 12:13:42 -0800
Links: << >>  << T >>  << A >>

Hi,

I set up and maintain a lab at San Jose State University.

> 1. Which operating system supplies the best performance
>    environment for Xilinx development?  I read that the
>    supplied ModelSim II XE works only on PCs, not on
>    Solaris or Linux. So would you prefer a PC, because
>    of the included simulation environment?

I have a strong preference for Windows 2000.  Yes, the
availability of CAD tools is decent but beyond that, your
university probably has a site license for other Microsoft
products, like Word and Powerpoint.  If you install these,
the lab is also good for writing reports, etc.

Originally, the department was maintaining the lab, but
every week another machine would get corrupted because
students treat lab equipment like their personal property.
We had all kind of viruses, porn, broken iSE installs.
It got to the point where I had 6 functional machines
out of 16, and it impacted my ability to teach the class.
Also, I felt it left a bad impression on students, I want
their first use of Xilinx FPGAs to be positive.

Over one summer, I configured all 16 machines in the lab
identically (W2K, MS office, Acrobat, Xilinx iSE, etc...)
and then installed DriveShield, which you can read about:
http://www.centuriontech.com

This "restores" the disk to how I left it each time the
power is cycled.  The lab has been up and running, bullet
proof, for two years now.  The initial setup was some work
but it has really paid off.  I highly recommend DriveShield!

> 3. Which Download Cable would you recommend? Does the
>    Parallel Cable only work with a PC (I read that somewhere)?
>    Or would you prefer the Multilinx Cable? (If so, why?)

Don't use any cables.  They are easy to break and easy to
steal.  Instead, buy prototyping boards that have this
function integrated.  You can get boards like this from
Digilent, http://www.digilentinc.com All that is required
is a standard parallel cable (comes with the board).

Eric

Article: 65405
Subject: Re: FPGA Config Readback while run, gotchas etc
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 28 Jan 2004 10:01:39 +1300
Links: << >>  << T >>  << A >>

  This was an interesting topic, so I've tagged it with a better title 
than 'Spirit on Mars...' for later searchers
-jg

Austin Lesea wrote:

> Ray,
> 
> Excellent summary of the operation.  All perfectly correct.
> 
> V2P QPRO is still in progress, as we were "in the beam" at LANSCE just 
> last week.  So far, so good.
> 
> Austin
> 
> Ray Andraka wrote:
> 
>> Austin,
>>
>> I don't think I said it corrupted the contents.  I thought I said it 
>> corrupted the user
>> read of the contents.  The point is, you can't read the BRAM while the 
>> user circuit is
>> running without messing up the user function.  You either need to stop 
>> the clock, or the
>> user circuit has to somehow know it can't expect good data from the 
>> BRAM and deal with it
>> accordingly.  One work around would be to use ECC and spread the read 
>> word width over
>> multiple BRAMs situated in different columns.  Again, the designer has 
>> to be aware that
>> this behavior happens during readback.  I don't think this particular 
>> one was documented
>> when we were looking at it, even though it was apparently an 
>> intentional behavior.
>>
>> In the case of CLBRAM or SRL16's, one must be even more careful, 
>> because there, a readback
>> at the wrong time can actually corrupt the contents rather than just 
>> the read value.  I
>> believe that one is a problem if the user circuit is changing the lut 
>> content (eg clocking
>> with WE='1') while a readback of that cell is occuring.  That one 
>> seemed like it was not an
>> intentional behavior, and I've yet to see it documented anywhere.  
>> I've had two customers
>> run into this one, fortunately with the second one as soon as they 
>> told me that they were
>> doing readback, I knew what the problem was.
>>
>> Keep up the good work.  BTW, what is the latest on availability dates 
>> for the QPRO version
>> (space qual'd) virtexII?  I've got a project right now where a V2 
>> would save a bunch of
>> headache, but it has to be real relatively soon in order to make the 
>> launch schedule.  I
>> can use which ever one comes out first.  The design is currently 
>> slated for a pair of
>> V1000's, only because of the internal memory requirements.  75% of the 
>> logic in the V1000
>> prototype is SRL16's used as a delay buffer because we used up the BRAMs.
>>
>>
>> Austin Lesea wrote:
>>
>>
>>> Ray,
>>>
>>> I was correct (still correct).  Readback does not corrupt BRAM contents.
>>>  But the config logic does take over the control of BRAM, so the user
>>> may not see what they expect while you are reading back (takes total
>>> control of ports A and B).
>>>
>>> I agree that readback has not been comprehensively described, and that
>>> is something that we are working on, since reading back is now becoming
>>> so useful and interesting.
>>>
>>> Austin
>>>
>>> Ray Andraka wrote:
>>>
>>>> Thanks,  I appreciate it.  It would be helpful to have a 
>>>> comprehensive readback
>>>> appnote that detailed all of the gotchas, both the ones that are by 
>>>> design and the
>>>> 'ah-shits'.  I know we stumbled on one or two during some of the 
>>>> radiation testing
>>>> experiments.  In any event, I haven't seen anything that documents 
>>>> it as a complete
>>>> package.  Readback induced problems can be subtle, and I imagine 
>>>> could be a nightmare
>>>> to diagnose without the nice patterns we were testing with.  It 
>>>> would be very
>>>> beneficial to have all the data available to anyone who is 
>>>> attempting it.  I'm once
>>>> again running into a "if you show me the documentation, I'll believe 
>>>> you"' situations
>>>> once again.
>>>>
>>>> Austin Lesea wrote:
>>>>
>>>>
>>>>
>>>>> Ray,
>>>>>
>>>>> As we all know, I am certainly not perfect, so I could be wrong 
>>>>> here.  I
>>>>> am checking.  I was pretty confident that changing the address while
>>>>> trying to read hte LUTs affected the contents as they have to share
>>>>> circuitry, but the BRAM is a two port plus the config access, or 
>>>>> really
>>>>> a three port memory as the addressing of the config is independent.
>>>>>
>>>>> I will post as soon as I know for sure....
>>>>>
>>>>> Austin
>>>>>
>>>>> Ray Andraka wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Austin,
>>>>>>
>>>>>> Are you sure this is true for BRAM?  As I understood it, the 
>>>>>> readback logic for
>>>>>> the BRAM in virtex is shared with part of the operational logic 
>>>>>> and you will
>>>>>> corrupt a user read if readback is performed on a BRAM while a 
>>>>>> user read is also
>>>>>> happening, ie, you need to either shut down the clock or have the 
>>>>>> user circuit
>>>>>> ignore read data.  I'm hoping this was not conveyed to me 
>>>>>> properly, but my
>>>>>> source was rather emphatic (source was involved with the radiation 
>>>>>> testing at
>>>>>> LANL).
>>>>>>
>>>>>> Austin Lesea wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> If that BRAM was storing constants/lookup info (read only), then
>>>>>>>> I can see a need to verify the table is actually still correct ?
>>>>>>>
>>>>>>>
>>>>>>> If BRAM or LUTRAM is storing constants, then you may include it 
>>>>>>> in the
>>>>>>> readback verify.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -jg
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> --Ray Andraka, P.E.
>>>>>> President, the Andraka Consulting Group, Inc.
>>>>>> 401/884-7930     Fax 401/884-7950
>>>>>> email ray@andraka.com
>>>>>> http://www.andraka.com
>>>>>>
>>>>>> "They that give up essential liberty to obtain a little
>>>>>> temporary safety deserve neither liberty nor safety."
>>>>>>                                         -Benjamin Franklin, 1759
>>>>>>
>>>>>>
>>>>
>>>>
>>>> -- 
>>>> --Ray Andraka, P.E.
>>>> President, the Andraka Consulting Group, Inc.
>>>> 401/884-7930     Fax 401/884-7950
>>>> email ray@andraka.com
>>>> http://www.andraka.com
>>>>
>>>> "They that give up essential liberty to obtain a little
>>>>  temporary safety deserve neither liberty nor safety."
>>>>                                          -Benjamin Franklin, 1759
>>>>
>>>>
>>
>>
>> -- 
>> --Ray Andraka, P.E.
>> President, the Andraka Consulting Group, Inc.
>> 401/884-7930     Fax 401/884-7950
>> email ray@andraka.com
>> http://www.andraka.com
>>
>>  "They that give up essential liberty to obtain a little
>>   temporary safety deserve neither liberty nor safety."
>>                                           -Benjamin Franklin, 1759
>>
>>
> 


Article: 65406
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Ralph Malph <noone@yahoo.com>
Date: Tue, 27 Jan 2004 17:08:43 -0500
Links: << >>  << T >>  << A >>
Wow Austin, you really should cut down on the caffeine!!!



Austin Lesea wrote:
> 
> Thomas,
> 
> You need to contact one of our FAEs!
> 
> See below,
> 
> Austin
> 
> Thomas Stanka wrote:
> 
> > Hi,
> >
> > Austin Lesea <austin@xilinx.com> wrote:
> >
> >>radioactive after spending so much time in the beam.  Oh, and none of
> >>them ever suffer any damage -- they power on and meet all specs after
> >>hundred and hundreds of rads.
> >
> >
> > What about 100 krad? I'm just curios. In our company we have problems
> > to use devices without qualification for at least 30krad.
> 
> Better than 100Krad.  Ask for the FAE for radiation test results.
> 
> >
> >
> >>>Analysis
> >>
> >>This is a standard procedure, and we are the ONLY company that actually
> >>KNOWS how our parts are affected by cosmic neutron showers, alpha
> >>particles, etc in REAL applications from sea level to 60,000 feet (I
> >>can't talk about the programs we have for mil/aerospace until you sign
> >>an NDA).
> >
> >
> > This seems a bit too overconfident.
> > Actually I didn't know your effort, but I know the effort Actel is
> > doing for its devices. And they prove very sufficient analyses beside
> > the analyses spacecompanies are doing with Actel Fpgas for themself.
> 
> No, it is not.  Some competitors are spreading information that is
> patently false, and misleading (there, I said it).  They compare us with
> commercial SRAM, which is false and misleading, as we are not commercial
> SRAM, have nothing to do with commercial SRAM, and do not use commercial
> SRAM technology or cells.  We use our own design cmos configuration
> latches, which are shown to be 20X to 100X more robust for the same
> technology.  As for their own tests, they only talk about their fuses,
> and not their logic, or flip flops.  How fair is that?  With a part that
> is one tenth the size of ours.  Tens times smaller, is also ten times
> fewer upsets.
> 
> How to lie with numbers.
> 
> >
> >
> >>Competitors
> >>
> >>Other companies out there are in a state of "blissful ignorance" and
> >>when (not if) they start to have customers complain of failures, they
> >>will be saying, "gee, we don't see anything (because we can't), must be
> >>something you are doing."  Why can't they see anything when a customer
> >>complains?
> >
> >
> > I'm shure you wouldn't tell names, but did you _ever_ tried the
> > hotline of another fpga vendor? Tell us a bit about your experience.
> > I'm very satisfied the way Actel is reacting on complaints.
> >
> 
> OK, let us try it:  Competitors?  What is your cross section for logic?
>   Cross section for flip flops?  Cross section for config bits, RAM?  Go
> ahead, let us all know your data.  Ours is very simple, you can not
> upset our logic or flip flops as they are so heavily loaded.  And the
> rest of our data is in the power point MAPLD presentation that RK has so
> kindly provided the link to.

Article: 65407
Subject: Re: building macros for Virtex-II with FPGA editor...
From: bret.wade@xilinx.com (Bret Wade)
Date: 27 Jan 2004 15:48:27 -0800
Links: << >>  << T >>  << A >>
simon <ssteineg@ee.ethz.ch> wrote in message news:<4016b07a$1@pfaff2.ethz.ch>...
> Hello,
> Is anyone out there experienced in building macros. As soon as my macros 
> contain external pins I cannot reopen them in "FPGA Editor". "FPGA 
> Editor" crashes displaying the following message:
> 
> FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start 
> property read <0xfffcacc>. Process will terminate. To resolve this 
> error, please consult the Answers Databas and other online resources at 
> http://support.xilinx.com. If you need further assistance, please open a 
> Webcase by clicking on the "WebCase" link at http://support.xilinx.com
> 
> I'm a student, so I am not allowed to open a webcase...
> 
> Regards
> Simon

Hello Simon,

I have found a known problem that appears to be a good match for your
problem. This problem only occurs when more than one save operation is
performed per FPGA Editor session. Try defining all of your external
pins at once without intermediate saves. If there are too many of them
for that to be practical, I suggest that you close the editor after
saves before continuing.

BTW, if you are using our current tools, you may want to consider
using RPM Macros combined with Directed Routing constraints instead of
Hard Macros. It depends on what you are trying to accomplish with the
macro.

Regards,
Bret

Article: 65408
Subject: Re: Image sensor? (GPL code)
From: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Date: Wed, 28 Jan 2004 00:32:04 GMT
Links: << >>  << T >>  << A >>
bob wrote:

> Hi I want to make a project that uses an image sensor (any perhaps a
> low power cmos from Micron or Kodak) connected to a FPGA (or CPLD).
> with the apropriate VHDL or Veralog code.
> 
> Has anyone done this who would be willing to share there hardware
> and/or software designs to get me started?
> Or is there any examples on the web that I can explore?
> 

I think this directly connects with a CMOS sensor (figure 3)

Article (from Xcell Journal)
        http://www.xilinx.com/publications/xcellonline/xcell_46/xc_freesw46.htm
        (get the pdf with pictures at page bottom)

Alternative location:
        http://www.linuxdevices.com/articles/AT6411901280.html

"FPGA Code

 Most of the system functionality is implemented in the Xilinx Spartan-IIE
FPGA. The code is written in Verilog HDL and is available for download at
my Elphel website under the GNU/GPL (general public license) license. It is
designed around a four-channel SDRAM controller that uses embedded block
RAM modules as "ping-pong" buffers to provide quasi-simultaneous block
access for the following data sources and receivers: 

Image data from the sensor, either processed or raw, one- or two-bytes per
pixel, arranged as 256 (128) pixel lines 
Calibration data to the FPN elimination module prepared by software in
advance, 128x16-bit blocks 
Data to the JPEG compressor, arranged as square blocks of 16x16 bytes 
CPU access to the SDRAM (normally used to read raw sensor data and write
back the calibration data for the FPN elimination). The JPEG encoder uses
two-thirds of the FPGA resources, as shown in Figure 3. The encoder
consists of the chain of the processing modules, some of which use block
RAM for data buffering and table storage:
 - Bayer-to-YCbCr converter
 - 8x8 DCT based on the Xilinx XAP610, modified to provide
block-asynchronous operation and to increase dynamic range
 - Quantizator and zigzag encoder
 - RLL encoder
 - Huffman encoder
 - Bit stuffer."

http://www.elphel.com/

-- 
Roger Larsson
Skellefteċ
Sweden

Article: 65409
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 27 Jan 2004 17:04:05 -0800
Links: << >>  << T >>  << A >>
Ralph,

Would you believe I drink decaf?  Hard to imagine.

Austin



Ralph Malph wrote:
> Wow Austin, you really should cut down on the caffeine!!!
> 
> 
> 
> Austin Lesea wrote:
> 
>>Thomas,
>>
>>You need to contact one of our FAEs!
>>
>>See below,
>>
>>Austin
>>
>>Thomas Stanka wrote:
>>
>>
>>>Hi,
>>>
>>>Austin Lesea <austin@xilinx.com> wrote:
>>>
>>>
>>>>radioactive after spending so much time in the beam.  Oh, and none of
>>>>them ever suffer any damage -- they power on and meet all specs after
>>>>hundred and hundreds of rads.
>>>
>>>
>>>What about 100 krad? I'm just curios. In our company we have problems
>>>to use devices without qualification for at least 30krad.
>>
>>Better than 100Krad.  Ask for the FAE for radiation test results.
>>
>>
>>>
>>>>>Analysis
>>>>
>>>>This is a standard procedure, and we are the ONLY company that actually
>>>>KNOWS how our parts are affected by cosmic neutron showers, alpha
>>>>particles, etc in REAL applications from sea level to 60,000 feet (I
>>>>can't talk about the programs we have for mil/aerospace until you sign
>>>>an NDA).
>>>
>>>
>>>This seems a bit too overconfident.
>>>Actually I didn't know your effort, but I know the effort Actel is
>>>doing for its devices. And they prove very sufficient analyses beside
>>>the analyses spacecompanies are doing with Actel Fpgas for themself.
>>
>>No, it is not.  Some competitors are spreading information that is
>>patently false, and misleading (there, I said it).  They compare us with
>>commercial SRAM, which is false and misleading, as we are not commercial
>>SRAM, have nothing to do with commercial SRAM, and do not use commercial
>>SRAM technology or cells.  We use our own design cmos configuration
>>latches, which are shown to be 20X to 100X more robust for the same
>>technology.  As for their own tests, they only talk about their fuses,
>>and not their logic, or flip flops.  How fair is that?  With a part that
>>is one tenth the size of ours.  Tens times smaller, is also ten times
>>fewer upsets.
>>
>>How to lie with numbers.
>>
>>
>>>
>>>>Competitors
>>>>
>>>>Other companies out there are in a state of "blissful ignorance" and
>>>>when (not if) they start to have customers complain of failures, they
>>>>will be saying, "gee, we don't see anything (because we can't), must be
>>>>something you are doing."  Why can't they see anything when a customer
>>>>complains?
>>>
>>>
>>>I'm shure you wouldn't tell names, but did you _ever_ tried the
>>>hotline of another fpga vendor? Tell us a bit about your experience.
>>>I'm very satisfied the way Actel is reacting on complaints.
>>>
>>
>>OK, let us try it:  Competitors?  What is your cross section for logic?
>>  Cross section for flip flops?  Cross section for config bits, RAM?  Go
>>ahead, let us all know your data.  Ours is very simple, you can not
>>upset our logic or flip flops as they are so heavily loaded.  And the
>>rest of our data is in the power point MAPLD presentation that RK has so
>>kindly provided the link to.


Article: 65410
Subject: modular design routing returns 1 unrouted net GLOBAL_PSEUDO/CLK
From: nachikap@yahoo.com (Nachiket Kapre)
Date: 27 Jan 2004 18:35:08 -0800
Links: << >>  << T >>  << A >>
Whiel running modular design i get a single error at the end of active
module implementation phase => Unrouted net GLOBAL_PSEUDO/CLK. The
thing abt. this net is that it is inserted by the mapper alongwith a
bunch of other signals that help the router route the inter-module
signals properly. This CLK is what goes to the intermodule signal
registers that map is inferring automatically at the boundary of the
module. So this signal is not really a part of my design. And clearly
there are plently of empty areas around it as is evident when viewing
it in FPGA editor.

Any pointers?

regards,
nachiket.

Article: 65411
Subject: Re: Timing model for MultiTrack interconnects in Stratix?
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Wed, 28 Jan 2004 04:37:46 GMT
Links: << >>  << T >>  << A >>
Hi Peter,

> If I understand the handbook correctly, each LAB can drive an R4 to
> its left or right. But I haven't found out how many signals in total
> can be driven on the various MultiTracks (ie. how wide are they?).

The "cross-section" of the routing channel in Stratix is 160 R4 wires, 48 R8
wires, 80 C4 wires, 32 C8 wires, 24 R24 wires, and 16 R16 wires.

Each LE can drive C4/C8 wires in the channels to the left and right of the
LE, as well as R4/R8 wires that start "above and to the left" and "above and
to the right" of the LE.  Of course, this is all very fuzzy since this is a
logical, not a physical, representation of things.  But basically it means
that you can get from an LE to another LE that is up to four or eight LABs
away (not including the first one) in either direction in a single hop.  You
get onto the R24/C16 wires from R4 wires, and they can drive R24/C16/R4/C4
wires to eventually get to other blocks.  On top of this, there are paths
that take you from an LE output to the LAB line of adjacent labs, bypassing
the routing.

Things are little trickier near the DSP, M4K, and MRAM blocks.  For the DSP
and M4K blocks, basically pretend there are two LABs worth of routing that
are accessable by the DSP/M4K block, minus the vertical channel.

BTW, another way to see the routing that was used (rather than using Chip
Editor) is to back-annotate  your fitting, including the routing.  This will
produce a file named <design>.rcf in your project directory that contains
the routing.

You can also create your own routing constraints, with wild-carding, by
editing the RCF file.  See the QUIP documentation
(http://www.altera.com/education/univ/quip/quip-overview.html) for more
information on the RCF file format.

> Also, does Altera have training courses that describe the architecture
> to this level of detail? I understand most people are not concerned or
> interested in it, so it may not be practical to have seminars on it.

Looking at our web site, "Fundamental Design Techniques for Stratix Devices"
looks like it could cover this material, but probably not in too much more
detail.  I'd contact Altera Customer Training (custrain@altera.com) for help
in determining if an appropriate training session exists.

My guess is that knowing the routing architecture to this level of detail
isn't too handy to the typical end user.  The router is quite good at
optimizing things, though it is good to know how far you can go before you
must add additional routing hops, especially when floorplanning a design
manually via LogicLock.

I believe that there is a way in the Timing Closure floorplan view to see a
histogram of the delays from a source LE to destination LEs -- it tells you
where you can reach in what amount of delay.  But I don't recall how to get
to this feature as I don't actually get to use Quartus too much myself.
Looking at this view can give you a good intuition on the directional bias
(speed-wise) of the routing architecture as well as where things should be
placed relative to one another for maximum speed.

Regards,

Paul Leventis
Altera Corp.



Article: 65412
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Ralph Malph <noone@yahoo.com>
Date: Tue, 27 Jan 2004 23:46:38 -0500
Links: << >>  << T >>  << A >>
Yes it is hard to believe sometimes... ;)


Austin Lesea wrote:
> 
> Ralph,
> 
> Would you believe I drink decaf?  Hard to imagine.
> 
> Austin
> 
> Ralph Malph wrote:
> > Wow Austin, you really should cut down on the caffeine!!!
> >
> >
> >
> > Austin Lesea wrote:
> >
> >>Thomas,
> >>
> >>You need to contact one of our FAEs!
> >>
> >>See below,
> >>
> >>Austin
> >>
> >>Thomas Stanka wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>Austin Lesea <austin@xilinx.com> wrote:
> >>>
> >>>
> >>>>radioactive after spending so much time in the beam.  Oh, and none of
> >>>>them ever suffer any damage -- they power on and meet all specs after
> >>>>hundred and hundreds of rads.
> >>>
> >>>
> >>>What about 100 krad? I'm just curios. In our company we have problems
> >>>to use devices without qualification for at least 30krad.
> >>
> >>Better than 100Krad.  Ask for the FAE for radiation test results.
> >>
> >>
> >>>
> >>>>>Analysis
> >>>>
> >>>>This is a standard procedure, and we are the ONLY company that actually
> >>>>KNOWS how our parts are affected by cosmic neutron showers, alpha
> >>>>particles, etc in REAL applications from sea level to 60,000 feet (I
> >>>>can't talk about the programs we have for mil/aerospace until you sign
> >>>>an NDA).
> >>>
> >>>
> >>>This seems a bit too overconfident.
> >>>Actually I didn't know your effort, but I know the effort Actel is
> >>>doing for its devices. And they prove very sufficient analyses beside
> >>>the analyses spacecompanies are doing with Actel Fpgas for themself.
> >>
> >>No, it is not.  Some competitors are spreading information that is
> >>patently false, and misleading (there, I said it).  They compare us with
> >>commercial SRAM, which is false and misleading, as we are not commercial
> >>SRAM, have nothing to do with commercial SRAM, and do not use commercial
> >>SRAM technology or cells.  We use our own design cmos configuration
> >>latches, which are shown to be 20X to 100X more robust for the same
> >>technology.  As for their own tests, they only talk about their fuses,
> >>and not their logic, or flip flops.  How fair is that?  With a part that
> >>is one tenth the size of ours.  Tens times smaller, is also ten times
> >>fewer upsets.
> >>
> >>How to lie with numbers.
> >>
> >>
> >>>
> >>>>Competitors
> >>>>
> >>>>Other companies out there are in a state of "blissful ignorance" and
> >>>>when (not if) they start to have customers complain of failures, they
> >>>>will be saying, "gee, we don't see anything (because we can't), must be
> >>>>something you are doing."  Why can't they see anything when a customer
> >>>>complains?
> >>>
> >>>
> >>>I'm shure you wouldn't tell names, but did you _ever_ tried the
> >>>hotline of another fpga vendor? Tell us a bit about your experience.
> >>>I'm very satisfied the way Actel is reacting on complaints.
> >>>
> >>
> >>OK, let us try it:  Competitors?  What is your cross section for logic?
> >>  Cross section for flip flops?  Cross section for config bits, RAM?  Go
> >>ahead, let us all know your data.  Ours is very simple, you can not
> >>upset our logic or flip flops as they are so heavily loaded.  And the
> >>rest of our data is in the power point MAPLD presentation that RK has so
> >>kindly provided the link to.

Article: 65413
Subject: Re: Spirit on Mars, upsets on Earth -- does your vendor know? How?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 28 Jan 2004 08:44:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ralph Malph <noone@yahoo.com> wrote:
: Yes it is hard to believe sometimes... ;)


Ralph,

is it really needed to full quote 90 lines of nearly unrelated text. This
only fills up the archives  with redundancy and makes them hard to search.

<Posted, as no valid mailing address is given>

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 65414
Subject: Re: building macros for Virtex-II with FPGA editor...
From: simon <ssteineg@ee.ethz.ch>
Date: Wed, 28 Jan 2004 10:07:40 +0100
Links: << >>  << T >>  << A >>
Hello Bret,
I just read some xilinx documents about RPMs and Directed routing. I'm 
not quite sure if these are useful in my case. I'm working on a 
dynamically partial reconfigurable design and I want to model 
communication lines across reconfigurable modules as hard macros. I 
assume that this will prevent (or rather minimize) discontinuation of 
the signal flow when the module is reconfigured.

Regards,
Simon

Bret Wade wrote:

> simon <ssteineg@ee.ethz.ch> wrote in message news:<4016b07a$1@pfaff2.ethz.ch>...
> 
>>Hello,
>>Is anyone out there experienced in building macros. As soon as my macros 
>>contain external pins I cannot reopen them in "FPGA Editor". "FPGA 
>>Editor" crashes displaying the following message:
>>
>>FATAL_ERROR:Ncd:basncmacrodef.c:1470:1.31 - Mangled nmc file start 
>>property read <0xfffcacc>. Process will terminate. To resolve this 
>>error, please consult the Answers Databas and other online resources at 
>>http://support.xilinx.com. If you need further assistance, please open a 
>>Webcase by clicking on the "WebCase" link at http://support.xilinx.com
>>
>>I'm a student, so I am not allowed to open a webcase...
>>
>>Regards
>>Simon
> 
> 
> Hello Simon,
> 
> I have found a known problem that appears to be a good match for your
> problem. This problem only occurs when more than one save operation is
> performed per FPGA Editor session. Try defining all of your external
> pins at once without intermediate saves. If there are too many of them
> for that to be practical, I suggest that you close the editor after
> saves before continuing.
> 
> BTW, if you are using our current tools, you may want to consider
> using RPM Macros combined with Directed Routing constraints instead of
> Hard Macros. It depends on what you are trying to accomplish with the
> macro.
> 
> Regards,
> Bret


Article: 65415
Subject: ISE6.1 : using virtex 800
From: "Dave Pedlow" <dave.pedlow@dsl.pipex.com>
Date: Wed, 28 Jan 2004 03:25:03 -0800
Links: << >>  << T >>  << A >>
I'm trying to create a bit file for a virtex xcv800 using ISE 6.1 but I can't select the virtex family. can I download it of the xilinx site somewhere? 
thanks 
DAve 


Article: 65416
Subject: Asking about FPGA-SPARTAN error in synthizer
From: haythamazmi@hotmail.com (H.Azmi)
Date: 28 Jan 2004 05:50:09 -0800
Links: << >>  << T >>  << A >>
what can cause this error :
ERROR: a gnd net is driven by primitive gate(s) --  NET: GND0 
???

Article: 65417
(removed)


Article: 65418
Subject: Re: Image sensor?
From: bob <kmart@nospam.com>
Date: Wed, 28 Jan 2004 11:07:45 -0500
Links: << >>  << T >>  << A >>
Thanks to bad its in spanish. your software looks interesting.

On Tue, 27 Jan 2004 18:55:18 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (Tue, 27 Jan 2004 11:18:07 -0500) it happened bob
><kmart@nospam.com> wrote in <gb3d105893fkahc14d6eh0veh62frit83g@4ax.com>:
>
>>Hi I want to make a project that uses an image sensor (any perhaps a
>>low power cmos from Micron or Kodak) connected to a FPGA (or CPLD).
>>with the apropriate VHDL or Veralog code.
>>
>>Has anyone done this who would be willing to share there hardware
>>and/or software designs to get me started?
>>Or is there any examples on the web that I can explore?
>>
>>Martin
>>mart NO inb SPAM AT magma DOT ca
>>
>>Remove the NO  SPAM and put no spaces.  Also replace the AT for @ and
>>the
>>DOT for .   
>>
>>or post replies
>>
>>Thanks
>Somebody in Spain did a VHDL version of my mcam soft, uses the Creative
>webcam II look for document: Sistemacapturaimagenfin.pdf
>This webcam uses a 8052 processor to talk to the sensor itself.
>So the fpga talks to the 8052.
>The sensor is 4 bits bus with serial control, but I no longer have the
>datasheet.
>It is in Spanish.
>This sensor is likely superceded by better ones.
>http://www.home.zonnet.nl/panteltje/mcam/ for my C version.
>The VHDL version will learn you how to emulate a PC parport....
>I think, given the datasheet of the sensor, it is pretty straight forward.
>Talking directly to the sensor eliminates such protocols as par port / usb,
>whatever.
>But you may still need that to send the data anywhere else...
>JP


Article: 65419
Subject: Partial Reconfig Spartan 2 - Bus Macros, which one?
From: tau14@sussex.ac.uk (Ian)
Date: 28 Jan 2004 08:11:21 -0800
Links: << >>  << T >>  << A >>
XAPP290 says references to Vitex also apply to Spartan 2 devices,
therefore partial reconfig should be possible, right? er yeah.

So, I assume one should use bm_4b.mnc (bus macro for Virtex) for cross
module communication as in a Virtex design. However, when running
initial budgeting (ngdbuild -modular initial <design_name>) I get the
following error:

ERROR:PhysSimExpander:68 - Macro "D:\Work\partialbuild/bm_4b.nmc" is
not
   compatible with the target architecture. This macro cannot be
automatically
   retargeted because it was created with part v50bg256-4, which is no
longer
   valid.

So, am I using the wrong bus macro, do I have to generate my own one?
(I have never used/built a macro before!!)

I would be most gratefull for any help. Thanks in advance :)

Ian.

Article: 65420
Subject: Re: Asking about FPGA-SPARTAN error in synthizer
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 28 Jan 2004 16:18:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
H.Azmi <haythamazmi@hotmail.com> wrote:
: what can cause this error :
: ERROR: a gnd net is driven by primitive gate(s) --  NET: GND0 

You overwhelm us with information.

Do you do schematic capture for your design?
I guess you connected some gate output to ground.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 65421
Subject: Re: Which Environment for Xilinx Design?
From: PO Laprise <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca>
Date: Wed, 28 Jan 2004 17:23:21 GMT
Links: << >>  << T >>  << A >>
As a recent student, and having strong preferences toward the *NIX and 
open source philosophies, I feel the need to counter-balance some of the 
points made:

Eric Crabill wrote:
>>1. Which operating system supplies the best performance
>>   environment for Xilinx development?  I read that the
>>   supplied ModelSim II XE works only on PCs, not on
>>   Solaris or Linux. So would you prefer a PC, because
>>   of the included simulation environment?
> 
> 
> I have a strong preference for Windows 2000.  Yes, the
> availability of CAD tools is decent but beyond that, your
> university probably has a site license for other Microsoft
> products, like Word and Powerpoint.  If you install these,
> the lab is also good for writing reports, etc.

The OpenOffice suite is more than good enough for 99% of users, is free, 
and is multi-platform.  And anyway, everyone in University should be 
learning LaTeX :).  And anyway, you don't need as performant a machine 
for writing reports as for synthesis and simulation, so unless you have 
computers to spare, it might not be a good idea to encourage people to 
write reports on these machines (we have separate labs for general 
purpose use).
As to CAD tools, ISE 6.1 is available for Linux, Solaris, and Windows. 
I would recommend that you not limit your students to Modelsim XE, but 
instead get a site license.  Mentor Graphics has a University Program 
that will provide you with rebates on these.  Using FlexLM, the licenses 
will be available from anywhere on the network (independant of the 
machine's OS), which allows more flexibility.  Using this setup, we have 
Modelsim SE running on both Windows 2000 and RedHat boxes.  An added 
bonus to *NIX boxes is that the programs can be run remotely, meaning 
that the computers can be shared by different groups simultaneously.  I 
also always appreciated not having to physically go to the lab just to 
run that one simulation that I had forgotten to run during my lab period...

> Originally, the department was maintaining the lab, but
> every week another machine would get corrupted because
> students treat lab equipment like their personal property.
> We had all kind of viruses, porn, broken iSE installs.
> It got to the point where I had 6 functional machines
> out of 16, and it impacted my ability to teach the class.
> Also, I felt it left a bad impression on students, I want
> their first use of Xilinx FPGAs to be positive.

It sounds as if users had admin privileges!  Most of these problems 
would be avoided by students having their own network drive space and 
only having write access to "scratch" space on local drives (and of 
course, no privilieges whatsoever when it comes to installing and 
modifying programs).  Admittedly, this can be done as easily with 
Windows as *NIX, what's hard is finding a good sysadmin to handle it all.

-- 
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --


Article: 65422
Subject: Re: ISE6.1 : using virtex 800
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Wed, 28 Jan 2004 13:12:16 -0500
Links: << >>  << T >>  << A >>
On Wed, 28 Jan 2004 03:25:03 -0800, Dave Pedlow wrote:

> I'm trying to create a bit file for a virtex xcv800 using ISE 6.1 but I can't select the virtex family. can I download it of the xilinx site somewhere? 
> thanks 
> DAve

Virtex is included in the 6.1 release. Did you install the virtex family
when you did the install?.


Article: 65423
Subject: Re: building macros for Virtex-II with FPGA editor...
From: bret.wade@xilinx.com (Bret Wade)
Date: 28 Jan 2004 10:33:08 -0800
Links: << >>  << T >>  << A >>
simon <ssteineg@ee.ethz.ch> wrote in message news:<40177bdc$1@pfaff2.ethz.ch>...
> Hello Bret,
> I just read some xilinx documents about RPMs and Directed routing. I'm 
> not quite sure if these are useful in my case. I'm working on a 
> dynamically partial reconfigurable design and I want to model 
> communication lines across reconfigurable modules as hard macros. I 
> assume that this will prevent (or rather minimize) discontinuation of 
> the signal flow when the module is reconfigured.
> 
> Regards,
> Simon

Hello Simon,

I don't see why Directed Routing constraints couldn't replace the
functionality of the Bus Macro in the partial reconfig flow, but since
the penalty for not doing exactly the right thing is higher there, I
recommend staying with the documented hard macro flow. If you do try
the Directed Routing method, pay attention to the section in the .par
file that tells you if all the DIRT constraints were successfull.

Regards,
Bret

Article: 65424
Subject: Flip-Chip Package Substrate Solder Issue
From: banktrade2002@yahoo.com (Emile)
Date: 28 Jan 2004 11:32:42 -0800
Links: << >>  << T >>  << A >>
My Xilinx distributor shipped an affected lot to us and we are now in
a line-down situation.  We've been told that lead-time is 10 weeks. 
I'm looking for 50 XC2V6000-4BF957C from an unaffected lot.  Thanks.



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