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 131000

Article: 131000
Subject: Re: Modify POF with new ESB (ROM) content?
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 8 Apr 2008 04:25:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote:
> Antti <Antti.Luk...@googlemail.com> writes:
> > a DATA2MEM (elf to bit file merge) is VERY important for softcore
> > processors in FPGA's, and Altera kinda claims they have NIOS and
> > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their
> > toolchain!!
>
> You can get the same functionality using
>
> quartus_cdb --update_mif
>
> Petter
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

to my knowledge YOU CAN NOT

if Quartus has generated a bit file (programming file)
then this file (without access to the project database)  CAN NOT BE
updated with new memory file, unlike it is possible with xilinx
data2mem tool

Antti





Article: 131001
Subject: OBUF gate delay
From: jamicrotech@gmail.com
Date: Tue, 8 Apr 2008 04:51:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
   I am using virtex4 device for my designs. In timing analysis i
found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
that a way , i can reduce this gate delay by giving some constraints.
ie  is to reduce the gate delay  by tools .



Article: 131002
Subject: NoisII or else.
From: LC <cupidoREMOVE@mail.ua.pt>
Date: Tue, 08 Apr 2008 13:10:28 +0100
Links: << >>  << T >>  << A >>
Hi,

Simple question.

Can I put a NiosII on an FPGA alone, no ROM no DRAM no SRAM
no nothing, Just the FPGA ?

(examples and kits put me on the opposite extreme)

I understand that I would have little ram space etc...
so programs will be small... etc etc...
I just wonder if it is feasible and how to load all from
the config device.

---

OR

is there anything else more appropriate to place inside
an FPGA easy to put working alone. (micro controller I mean).


Luis C.

Article: 131003
Subject: Re: NoisII or else.
From: =?ISO-8859-1?Q?G=F3rski_Adam?=
Date: Tue, 08 Apr 2008 14:26:34 +0200
Links: << >>  << T >>  << A >>
LC pisze:
> Hi,
> 
> Simple question.
> 
> Can I put a NiosII on an FPGA alone, no ROM no DRAM no SRAM
> no nothing, Just the FPGA ?
> 
> (examples and kits put me on the opposite extreme)
> 
> I understand that I would have little ram space etc...
> so programs will be small... etc etc...
> I just wonder if it is feasible and how to load all from
> the config device.
> 
Hi,

Yes, you can work with internal ram only.
Yes you can store program in configuration memory used for FPGA.

I tested.

Adam

Article: 131004
Subject: Re: OBUF gate delay
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Apr 2008 13:41:19 +0100
Links: << >>  << T >>  << A >>

<jamicrotech@gmail.com> wrote in message 
news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com...
> Hi,
>   I am using virtex4 device for my designs. In timing analysis i
> found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
> that a way , i can reduce this gate delay by giving some constraints.
> ie  is to reduce the gate delay  by tools .
>
>

In your .ucf file try something like this:-

NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST;

Or, better still, read the constraints guide.

HTH., Syms.



Article: 131005
Subject: Re: Modify POF with new ESB (ROM) content?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Tue, 08 Apr 2008 14:59:48 +0200
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@googlemail.com> writes:

> On 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote:
>> Antti <Antti.Luk...@googlemail.com> writes:
>> > a DATA2MEM (elf to bit file merge) is VERY important for softcore
>> > processors in FPGA's, and Altera kinda claims they have NIOS and
>> > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their
>> > toolchain!!
>>
>> You can get the same functionality using
>>
>> quartus_cdb --update_mif

> to my knowledge YOU CAN NOT
>
> if Quartus has generated a bit file (programming file)
> then this file (without access to the project database)  CAN NOT BE
> updated with new memory file, unlike it is possible with xilinx
> data2mem tool

If you have lost track of the source/project database (like the OP)
you can not. But for the functional purpose where you run make on you
NIOS software project and merge the generated mif/hex file into a new
sof file without recompiling the project you can. I would disagree
with you calling the former the most important tool for fpga-soc
design. I would say that the latter is much more important.


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 131006
Subject: Re: Modify POF with new ESB (ROM) content?
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 8 Apr 2008 06:01:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 8 Apr., 14:59, Petter Gustad <newsmailco...@gustad.com> wrote:
> Antti <Antti.Luk...@googlemail.com> writes:
> > On 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote:
> >> Antti <Antti.Luk...@googlemail.com> writes:
> >> > a DATA2MEM (elf to bit file merge) is VERY important for softcore
> >> > processors in FPGA's, and Altera kinda claims they have NIOS and
> >> > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their
> >> > toolchain!!
>
> >> You can get the same functionality using
>
> >> quartus_cdb --update_mif
> > to my knowledge YOU CAN NOT
>
> > if Quartus has generated a bit file (programming file)
> > then this file (without access to the project database)  CAN NOT BE
> > updated with new memory file, unlike it is possible with xilinx
> > data2mem tool
>
> If you have lost track of the source/project database (like the OP)
> you can not. But for the functional purpose where you run make on you
> NIOS software project and merge the generated mif/hex file into a new
> sof file without recompiling the project you can. I would disagree
> with you calling the former the most important tool for fpga-soc
> design. I would say that the latter is much more important.
>
> Petter
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

Petter

the all IDEA about the update is that you need 2 files

1) BIT file
2) ELF file

and nothing else.. if based on those 2 files the elf can not be
merged, then this is REALLY BAD!!!

I dont know why Altera isnt understanding that.
Xilinx is doing it for ages

Antti




Article: 131007
Subject: Re: OBUF gate delay
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 08 Apr 2008 06:11:13 -0700
Links: << >>  << T >>  << A >>
jamicrotech@gmail.com wrote:
> Hi,
>    I am using virtex4 device for my designs. In timing analysis i
> found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
> that a way , i can reduce this gate delay by giving some constraints.
> ie  is to reduce the gate delay  by tools .

Are your outputs synchronous with the output registers in the IOB? 
That's step 1.

It sounds like you may have the FAST attribute turned on through I'm not 
as familiar with the V4 as the Spartan families.  Double-check your pin 
report (pad report?) to verify your output has the I/O standard and FAST 
attribute you request.

The next thing most designers consider is a DCM generated clock to 
effectively reduce the clock-to-out time.  Getting onto the chip has 
delays.  Getting off the chip has delays.  There's no getting around the 
delays *but* you can compensate for some of this with the DCM.  If your 
system clock is regular and reasonably jitter free, this is a superb way 
to go.

If your system clock is irregular or subject to strong jitter hits, the 
DCM won't help but it's usable in most board designs.

I'd suggest you dig far enough into any part datasheet before starting a 
design with the part to understand what the I/O timing should be to put 
together a system-level timing budget.  If you have 5 ns periods with 4 
ns clock-to out and 3 ns setup times, you may be starting with a 
non-solution.  Since you already have your design, read up on how to use 
the DCMs and verify that the OBUF timing corresponds to what you would 
expect from the I/O numbers in the data sheet for that speed grade.

If your outputs aren't registered with I/O registers, look into whether 
you can do that without otherwise crippling the design; it's the first 
tool to get good I/O numbers.

- John_H

Article: 131008
Subject: Intel plans to tackle cosmic ray threat
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Apr 2008 14:32:06 +0100
Links: << >>  << T >>  << A >>
Dear All, Austin in particular,
I saw this and thought of you!
Cheers, Syms.
http://news.bbc.co.uk/1/hi/technology/7335322.stm 



Article: 131009
Subject: Re: NoisII or else.
From: LC <cupidoREMOVE@mail.ua.pt>
Date: Tue, 08 Apr 2008 15:07:37 +0100
Links: << >>  << T >>  << A >>
Excellent,

Would it be possible to have a bit more details
on how to, just to ease my learning curve.
Thanks.

Luis C.


Górski Adam wrote:
> Hi,
> 
> Yes, you can work with internal ram only.
> Yes you can store program in configuration memory used for FPGA.
> 
> I tested.
> 
> Adam

Article: 131010
Subject: Re: OBUF gate delay
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Apr 2008 15:25:01 +0100
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:ftfp5l$4go$1@aioe.org...
>
> <jamicrotech@gmail.com> wrote in message 
> news:3234335a-7821-41f1-b69d-fa6dcad78e68@q1g2000prf.googlegroups.com...
>> Hi,
>>   I am using virtex4 device for my designs. In timing analysis i
>> found OBUF in V4 is 3.79ns which is a big obstacle for my design . Is
>> that a way , i can reduce this gate delay by giving some constraints.
>> ie  is to reduce the gate delay  by tools .
>>
>>
>
> In your .ucf file try something like this:-
>
> NET "I_CANT_BE_BOTHERED_TO_RTFM" SLEW=FAST;
>
> Or, better still, read the constraints guide.
>
> HTH., Syms.
>
>
...oh, and changing the drive strength will also affect the output delay. 
This can also be set by a UCF constraint. You've read DS302, right?
HTH., Syms. 



Article: 131011
Subject: Re: NoisII or else.
From: "David Spencer" <davidmspencer@verizon.net>
Date: Tue, 08 Apr 2008 14:43:00 GMT
Links: << >>  << T >>  << A >>
> Hi,
>
> Yes, you can work with internal ram only.
> Yes you can store program in configuration memory used for FPGA.
>
> I tested.
>
> Adam

Or you can store the program in internal RAM (functioning as ROM) too for a 
fully self-contained system. To make this easier, there is a mechanism to 
update the RAM initialization contents without needing to do a full 
re-synthesis and PAR each time.

If you use SOPC Builder it is trivial to set this up. 



Article: 131012
Subject: Re: NoisII or else.
From: =?ISO-8859-1?Q?G=F3rski_Adam?=
Date: Tue, 08 Apr 2008 16:50:06 +0200
Links: << >>  << T >>  << A >>
- Just run SOPC Builder
- make a system with nios ii , internall ram and for example port i/o.
- generate system
- put generated system into top schematic
- build fpga image
- load to fpga
- run Nios ide
- and have some fun

That's all

Adam


> Would it be possible to have a bit more details
> on how to, just to ease my learning curve.

>> Yes, you can work with internal ram only.
>> Yes you can store program in configuration memory used for FPGA.
>>
>> I tested.



Article: 131013
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: austin <austin@xilinx.com>
Date: Tue, 08 Apr 2008 08:15:02 -0700
Links: << >>  << T >>  << A >>
Symon,

Well, Cypress, Xilinx, IBM, and many others have made it no secret that
neutrons at sea level are causing upsets, and we have done something
about it (and presented the papers, and shown our results).

Intel has also been working very quietly on this, with much less press.

I suggest that if you are not thinking about single event effects, you
should be, and demanding your vendor show you the proof of their design
efforts in this regard.

Virtex 5 is (as of today), 144 FIT/Mb for the config bits, 95%
confidence interval from 100 to 200 FIT/Mb.  This is from our 400
devices located on mountain tops in France (31.029 Giga-bit-years of
test time, 35 events).

Compare this to a 65nm ASSP or ASIC, which is at least 1000 FIT/Mb or
1000 FIT/million gates(!).  Do nothing, and it gets worse.  Do
something, and it gets back to where it should be.  These numbers from
the SELSE II conference a few years back:  the industry numbers are
really a lot worse, but no one will admit it.

There is a reason why Xilinx FPGA devices are finding their way into
many high availability and high reliability applications: we are the
only choice -- there is no competition whatsoever.

Austin

Article: 131014
Subject: Re: Modify POF with new ESB (ROM) content?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Tue, 08 Apr 2008 17:23:05 +0200
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@googlemail.com> writes:

> the all IDEA about the update is that you need 2 files
>
> 1) BIT file
> 2) ELF file
>
> and nothing else.. if based on those 2 files the elf can not be
> merged, then this is REALLY BAD!!!

I can build my project and after that quickly build the hex/mif and
merge it into the sof. Why do you think this is so bad? 


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 131015
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been working on it for at least five years...austin)
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Apr 2008 16:43:36 +0100
Links: << >>  << T >>  << A >>
"austin" <austin@xilinx.com> wrote in message 
news:ftg25m$p2m2@cnn.xsj.xilinx.com...
>
> Intel has also been working very quietly on this, with much less press.
>
Hi Austin,
I wondered what were your thoughts on their patent where "The cosmic ray 
detector [built into the device] is therefore designed to spot when rays 
have caused interference and then tell the chip to repeat the command." ? I 
guess in an FPGA it could trigger a readback to ensure the device was still 
correctly configured and/or issue a user logic reset.
Cheers, Syms.



Article: 131016
Subject: Re: Modify POF with new ESB (ROM) content?
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 8 Apr 2008 08:47:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 8 Apr., 17:23, Petter Gustad <newsmailco...@gustad.com> wrote:
> Antti <Antti.Luk...@googlemail.com> writes:
> > the all IDEA about the update is that you need 2 files
>
> > 1) BIT file
> > 2) ELF file
>
> > and nothing else.. if based on those 2 files the elf can not be
> > merged, then this is REALLY BAD!!!
>
> I can build my project and after that quickly build the hex/mif and
> merge it into the sof. Why do you think this is so bad?
>
> Petter
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

quit simple

if you want to deliver a BITFILE only and allow the client to
change the software but not the FPGA bit file itself.

this is VERY simple with Xilinx tools
and IMPOSSIBLE with Altera tools

.

How many times that needs to be explained?

there is not even need to have all tools installed for bitstream
update
only the C compiler and merge tool

Antti

Article: 131017
Subject: Re: Avalon Bus <-> Wishbone Bus
From: ghelbig@lycos.com
Date: Tue, 8 Apr 2008 08:51:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 7, 8:15 pm, benn <benn...@hotmail.com> wrote:
> I'm pretty new to fpgas, but theres an i2c core on opencores.org that
> I'd like to use in my Altera project.   I understand Wishbone is a
> subset of Avalon, but what is involved in bridging these two together?
>
> I'm assuming its not too trivial since I could buy an IP bridge that
> does it from Men Micro, but what exactly is involved if I were to try
> tackling this myself?
>
> Thanks!

It's not that tough.  And a number of people have already done it, and
published their work.

Get familiar with niosforum and nioswiki.  The answers are out there.

G.

Article: 131018
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: austin <austin@xilinx.com>
Date: Tue, 08 Apr 2008 08:56:18 -0700
Links: << >>  << T >>  << A >>
Symon,

Well, that employee should be fired:  that is the stupidest thing I have
ever read.

It isn't even science -- detecting neutrons! Pure BS!  A neutron is an
uncharged particle, that goes through 10 meters of concrete before it
gets stopped.  Detecting one is just......stupid.....idiotic.....

(breathe in, breathe out.)

Their PR folks are probably going nuts on this one!

Was that April 1 dateline?

Anyway, Intel is pretty savvy, and they are not standing still.  If you
use their parts, you need to request their Soft Error Effects roadshow.

It is only given under NDA, so although I know it exists, and I suspect
I know what is in it, I have never seen it.

I have seen IBM's "show" and they certainly have their act together.  As
do we.  IBM's "show" is under NDA, however, so I can't say anything
about its contents.

Our roadshow is available by request from your local friendly FAE, and
it is no NDA is required (why would we hide we are the best?).

Remember:  per the JEDEC89A standard, there are three ways to
characterize soft error effects.  Be sure to ask which ones were used,
and their degree of confidence.

If they won't share this with you (under NDA), then they are hiding
something, something very very bad.

Austin

Article: 131019
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: austin <austin@xilinx.com>
Date: Tue, 08 Apr 2008 08:58:36 -0700
Links: << >>  << T >>  << A >>
Symon,

First of all, there is no such thing as a single particle detector.

Secondly, detecting the current spike (from a strike) requires a very
complex circuit, itself subject to spikes (I know, we designed them for
the USAF...)

Thirdly, Intel has done far more than this, and deserved a better PR.

Perhaps they should fire the PR firm?

Austin

Symon wrote:
> "austin" <austin@xilinx.com> wrote in message 
> news:ftg25m$p2m2@cnn.xsj.xilinx.com...
>> Intel has also been working very quietly on this, with much less press.
>>
> Hi Austin,
> I wondered what were your thoughts on their patent where "The cosmic ray 
> detector [built into the device] is therefore designed to spot when rays 
> have caused interference and then tell the chip to repeat the command." ? I 
> guess in an FPGA it could trigger a readback to ensure the device was still 
> correctly configured and/or issue a user logic reset.
> Cheers, Syms.
> 
> 

Article: 131020
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: austin <austin@xilinx.com>
Date: Tue, 08 Apr 2008 09:07:28 -0700
Links: << >>  << T >>  << A >>
And,

Yes, in S3A, S3AN, S3D, V4, V5 we are able to either reconfigure on
detection of an upset, notify the user (and they decide what to do), or
in V4 and V5, correct the flipped bit without having to reconfigure (or
even go to the config flash/prom).

Basically, in our road show, it is detailed how the user needs to decide
what to do, and at what levels, in order to meet their availability and
reliability numbers.

Mitigation is part hardware, part system architecture, and part
software.  Depending on what you are doing, and how long you can
tolerate being "off-line" there are different solutions.

They are:
-just reconfigure, start fresh
-just fix the bit flip, continue on (as a flip does nothing 90% of the
time, and seldom causes anything to 'crash')
-fix the bit flip and reset or go back to a check point/known states
-use dual redundancy, and check for agreement (if a fault is not
tolerated - like in banking, accounting) repeat if no agreement
-use full triple modular redundancy (when it must be correct, and 100%
available), also scrub to fix bits that may flip so flips are not
allowed to accumulate

All methods are used by our customers, and they all work.  We have
reference designs and support for these models.  And they can be tested
by reconfiguring to flip bits while operating. One heck of a lot cheaper
than using a proton beam, or neutron beam .... and more complete (we
have folks who flip each bit, one by one, and prove their system meets
its requirements).

Austin

Article: 131021
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been working on it for at least five years...austin)
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 Apr 2008 17:48:47 +0100
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message 
news:ftg4j2$pop1@cnn.xsj.xilinx.com...
> Symon,
>
> Well, that employee should be fired:  that is the stupidest thing I have
> ever read.
>
> It isn't even science -- detecting neutrons! Pure BS!  A neutron is an
> uncharged particle, that goes through 10 meters of concrete before it
> gets stopped.  Detecting one is just......stupid.....idiotic.....
>
Austin,
Are you talking about the link I posted? I didn't see any reference to 
neutrons, am I missing something? Also, if what you say is true, that 
neutrons whizz through 10 meters of concrete, aren't you gonna be incredibly 
unlucky to get a direct neutron hit on a 45nm transistor? (BTW., A cursory 
web search would suggest some kind of boron based detector, which kinda 
makes sense as boron is used to absorb thermal neutrons in nuclear reactors. 
http://en.wikipedia.org/wiki/Neutron_detection)
My rudimentary knowledge of cosmic rays is that they are not neutrons but 
mainly protons (and a few alpha and beta particles). I would expect them to 
be more detectable.
Whatever, I'm confused now...
Cheers, Syms. 



Article: 131022
Subject: Re: Modify POF with new ESB (ROM) content?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Tue, 08 Apr 2008 18:52:20 +0200
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@googlemail.com> writes:

> if you want to deliver a BITFILE only and allow the client to
> change the software but not the FPGA bit file itself.

The client will still need the SDK and FPGA tools from the vendor. 

Or do you look at the bit-file as a method of protecting your HDL code
from your customer?


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 131023
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: austin <austin@xilinx.com>
Date: Tue, 08 Apr 2008 10:16:52 -0700
Links: << >>  << T >>  << A >>
At sea level,

93% of particles from the cosmic ray shower are neutrons, and 7% are
protons (see JEDEC89A).

There are 12.9 per square cm, every hour, passing through everything
(for New York City, up to 25X more on mountain tops, 300X at 40K feet,
less at the equator, 10X at the poles...).

There are also electrons, muons, pions, and a host of more exotic stuff,
but hose either don' matter (do not affect anything), or they are
absorbed quickly, or decay (even a lone neutron decays in 11 minutes!).

So, like I said, that is the dumbest PR I have read.  It gets the first
prize for ignorance about soft error effects.

Some Real Science:

http://www.xilinx.com/support/documentation/white_papers/wp286.pdf

Austin

Article: 131024
Subject: Re: Modify POF with new ESB (ROM) content?
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 8 Apr 2008 10:18:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 8 Apr., 18:52, Petter Gustad <newsmailco...@gustad.com> wrote:
> Antti <Antti.Luk...@googlemail.com> writes:
> > if you want to deliver a BITFILE only and allow the client to
> > change the software but not the FPGA bit file itself.
>
> The client will still need the SDK and FPGA tools from the vendor.
>
> Or do you look at the bit-file as a method of protecting your HDL code
> from your customer?
>
> Petter
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

good god... how can it be that you dont understand...

the ELF to BIT merge is much simpler than the cdb_mif update

this is the reason why XILINX is doing it that way.
this is how ALL FPGA vendors should do it, at least all FPGA VENDORS
that offer soft-core solutions.

sure its my opinion, but I am sure i am not the only one, who would
like to see

DATA2BIT tools (aka elf to programming file merge) for other FPGAs
too, not only for Xilinx.

Antti



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