Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 21800

Article: 21800
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 31 Mar 2000 22:56:32 GMT
Links: << >>  << T >>  << A >>
In article <8c1n4a$1qh$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote:
>This thread is becomming a waste of my time, you very childishly insist
>that X and A should give you exactly what you want, with the OS of YOUR

First off, I don't.  I asked if they did and people told me I didn't want
them to, and I rebutted those claims.  Other people (i.e. Peter Alfke) were
blatantly rude and I unfortunately responded in kind.  Some people told me
of solutions to different problems and I've thanked them but pointed out
that those were not solutions to my problems.

Article: 21801
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: "Delon Levi" <delon.levi@xilinx.com>
Date: Fri, 31 Mar 2000 15:25:54 -0800
Links: << >>  << T >>  << A >>
There have been some very interesting milestones regarding Evolvable
Hardware here at Xilinx.

Evolving on 4KX and Virtex -  Despite the claims that EH could only be done
on XC6200 devices because that was the only chip that you could download
"random" bitstreams to, we have figured out how to do it on 4KX and Virtex
type devices using JBits.  You can still randomly create circuits on these
devices, you just have to be careful about how you randomize the circuit.
Instead of doing mutations directly on the bitstream, you do it on the
chromosome.  By carefully mapping the information on the chromosome to the
bitstream you can guarantee that you never run into contention.

Parasitic Analog Effects -  Adrian Thompson did some ground breaking work to
show that you could evolve a bitstream.  However, because his mutation
changed almost everything, the circuits generated where *highly*
asynchronous.  By carefully mapping the chromosome to the bitstream so that
only synchronous circuits are generated, again by construction, we are able
to generate circuits that display none of the parasitic-analog-temperature
sensitive effects.  Even though the circuit is evolved, it displays all of
the characteristics of a standard FPGA circuit, which is what you would
expect from synchronous design.

100X Faster Convergence -  We have also developed a new evolutionary
algorithm that combines Genetic Algorithms and Simulated Annealing to give
upto 100X faster convergence over a Genetic Algorithm and upto 10X over
Simulated Annealing.

If you'd like to get a copy of the paper published at the 1st NASA/DoD
Workshop on Evolvable Hardware describing the first two milestones plus
some other goodies, send and email to JBits@xilinx.com.  The algorithmic
improvement is described in a paper submitted to the 2nd NASA/DoD Workshop
on Evolvable Hardware.  All of this technology is packaged up into a Java
API called GeneticFPGA (Virtex only).  We will be releasing this toolset in
the June 2000 release of JBits.  If you are interested in getting the
software send email to JBits@xilinx.com.

Patents Pending.

Delon Levi
Xilinx


Article: 21802
Subject: FPGA price vs Size
From: "J.R." <j_robby@hotmail.com>
Date: Sat, 1 Apr 2000 02:51:32 +0100
Links: << >>  << T >>  << A >>
Does anybody know how much does an FPGA chip price vary with the size -i.e.
number of CLBs-  (within the same series)?
Is there an approximate dependence say Linearly?

Cheers.

PS. As you probably have already noticed, I am particularely intereseted in
Xilinx devices (XC4000 and Virtex).


Article: 21803
Subject: Re: tristate /driving a bidirectional port
From: "MK Yap" <mkyap@REMOVE.ieee.org>
Date: Sat, 1 Apr 2000 10:54:40 +0800
Links: << >>  << T >>  << A >>
Hi!

Thanks for the responses!!!
I'm using a state machine to differentiate & ctrl between read & write to
RAM.
& use async for data output.
The code is much neat as there are much less flag lying ard :-)

Rgds
MK

Jonas Rangell <jonas.rangell@emw.ericsson.se> wrote in message
news:38E354CC.2A035D69@emw.ericsson.se...
> MK Yap wrote:
> >
> >
>
> [snip]
>
> > I have been struggling with this for quite some time. Is there a good
way
> > for coding bidirection signals so that there is no logic contention?
When to
> > drive the signal & when to tristate it?
>
>
> >   ELSIF (MClk'event AND MClk='0') THEN
> >        RdDone <= '0';
> >        WrtHold <= '0';
> >        RAM_Data <= (OTHERS=>'Z');                --- (1)
>
>
> You have Z-assignments inside a clocked process.
> That is not good. These should be placed in an
> asyncronus process.
>
> Create a clocked process, containing the data to RAM
> and one asyncronus process which will do the data output,
> and handling the tristate.
>
>
>
> Something like this....
>
>
> Process(cp)  -- Clocked Output to port
> Begin
>  if rising_edge(cp) then
>    data_int <= data_to_RAM;
>  end if;
> End Process;
>
> Process(data_int, direction_to_RAM) -- Tristate control
> Begin
>   If direction_to_RAM = '1' Then
>     data_iob <= data_int;
>   Else
>     data_iob <= 'Z';
>   End If;
> End Process;
>
> Process(data_iob) -- Read data from port
> Begin
>   data_in <= data_iob;
> End Process;
>
> process(cp) -- return zero during write, else RAM data
> begin
>  if rising_edge(cp) then
>   if direction_to_RAM='1' then
>    data_from_RAM<='0';
>   else
>    data_from_RAM<=data_in;
>   end if;
>  end if;
> end process;
>
>
>
>
> Well, I have not really checked the code but it looks OK.
> Hope it helps
>
>
> /Jonas


Article: 21804
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 31 Mar 2000 21:59:17 -0500
Links: << >>  << T >>  << A >>
Dave Vanden Bout wrote:
> 
> Rickman wrote:
> 
> > I am not at all familiar with the work of Adrian Thompson or much
> > familiar with Hardware Evolution, but why can't you do the same thing in
> > a simulation rather than to have to work directly with a bitstream and
> > load a part for test?
> >
> > EDIF files can be "randomly" connected and simulated to test the
> > functionality. Your software may crash once in awhile, but it is
> > unlikely to fry the computer.
> >
> 
> Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population.  Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge.  These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked.
> 
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||

I don't know that I have read about Thompson's work in particular, but I
do remember reading about some efforts in genetic programming. The
circuit produced did what it was required, but produced some glitches in
the output and as you say, it used circuitry in very unusual ways. The
end result was that the circuit was not stable over normal variations
such as temp, voltage and process. So in the end depending on "unique"
design features and parasitic effects was a very bad thing. Maybe if the
simulators had been used, then the circuit produced would have been more
stable.


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 21805
Subject: Re: FPGA price vs Size
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 01 Apr 2000 04:48:38 GMT
Links: << >>  << T >>  << A >>
For a mature, high-yielding product family, the die cost is essentially
proportional to die area.
Therefore, the price will, to the first approximation, be proportional to
area, i.e. number of CLBs. But don't forget the BlockRAM on the newer parts.
One 4k-bit BlockRAM occupies the area of six CLBs in Virtex-E.

There are two important additional modifiers:
At the low end, the relatively higher package cost often results in a
disproportionally higher price.
At the high end, especially with a young family, the lower yield of the
biggest chips ( suffering most from the defect density on the wafer) makes
them overproportionally expensive.

So you will see a linear line with an upward excursion both at the low
end and
at the high end. But there may always be special marketing
considerations that
require a deviation from this simple model.

These are no Xilinx secrets, every chip manufacturer faces the same issues.

Peter Alfke
===================================
"J.R." wrote:

> Does anybody know how much does an FPGA chip price vary with the size -i.e.
> number of CLBs-  (within the same series)?
> Is there an approximate dependence say Linearly?
>
> Cheers.
>
> PS. As you probably have already noticed, I am particularely intereseted in
> Xilinx devices (XC4000 and Virtex).
Article: 21806
Subject: Re: FPGA openness
From: "Gary Watson" <gary@nexsan.sex>
Date: Sat, 1 Apr 2000 11:21:18 +0100
Links: << >>  << T >>  << A >>
Zoltan Kocsi <root@127.0.0.1> wrote in message
news:m3snxb25wd.fsf@tade.bendor.com.au...
> Ray Andraka <randraka@ids.net> writes:
>
> > Rickman wrote:
> >
> > > But I think my point is still valid. I doubt that anyone would expect
> > > Xilinx to provide such support. It would be a far reach of the mind
for
> > > a user to expect anyone to support the operation of tools that they
did
> > > not provide. Again, the analogy would be like asking Intel to support
> > > the GNU tools.
> > >
> >
> > Not really, there's a fundamental difference.  When you buy an intel
processor, you
> > know exactly what it's function is and you know the chip works.  With an
FPGA, you
> > have a hardware design in there too, which from what I have seen is more
often than
> > not a poor fit to the FPGA.  That invariably generates the "you say the
chips run at
> > XX MHz, but I can't get my design to run even at XX/10 or 20" calls.
>
> When I buy a microcontroller, its function is not determined. It can be
> turned to a washing machine controller or a television remote control
> or a talking Barbie doll or a pocket calculator or whatever. It depends
> on the exact bit pattern stored in its program memory. Very much like
> an FPGA chip, which can be turned into all sorts of things by varying
> the bit pattern in its program memory.

I was reading through the Xilinx documentation last night, and they make the
comment that the bitstream format "is a closely guarded secret".  The only
reason mentioned for this is to make it harder for people to copy your
bitstream and get away with it.  They suggest copyrighting your bitstream
(and putting a notice of this on the silkscreen on the board) so that if you
find a competitor is using the same FPGA in a similar way, and with a logic
analyzer you find him using the same bitstream, you can sue his butt off.
If Xilinx published the bitstream format, it would be pretty easy for the
competitor to swap some pins around (for example, rotate the design 180
degrees, or swap every third pin pair) and maybe invert a signal or two, in
an attempt to get around the copyright claim.  At a glance, the bitstream
would not appear to be a copy and one might not suspect a theft had taken
place.

The Xilinx docs don't say it, but on smaller parts it would be very
straightforward to take knowledge of the config bits and produce a
schematic.  On larger parts, I imagine that a skilled FPGA designer who has
designed similar parts would be able to reverse-engineer, for example, a
three port PCI bridge design to see how the designer has managed to save a
couple of clock cycles.  Parts with wide data paths and relatively small
control sections would be the easiest to figure out, I reckon.

So now that I've looked into it, I don't have such a problem with Xilinx
keeping the bitstream format confidential, and it's good to see that they
have a logical reason for it (I never believed that it had to do with
product support calls, to be quite honest, no offense to the guy from
Xilinx).

In the same section they talk about an interesting security technique --
load the bitstream during manufacturing, and use a little lithium battery to
keep the configuration loaded when power is off.  This would make
reverse-engineering the chip nearly impossible (cheaper to hire thugs to
break into the competitor and take the design at gunpoint, in fact).  Have
any of you tried this battery backup technique?

--

Gary Watson
gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com





Article: 21807
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: Dave Vanden Bout <devb@xess.com>
Date: Sat, 01 Apr 2000 07:09:45 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------DA6EFAEDCB6E798B82EB9C20
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population.  Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge.  These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked.
> >
> > --
> > || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> > || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> > || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
>
> I don't know that I have read about Thompson's work in particular, but I
> do remember reading about some efforts in genetic programming. The
> circuit produced did what it was required, but produced some glitches in
> the output and as you say, it used circuitry in very unusual ways. The
> end result was that the circuit was not stable over normal variations
> such as temp, voltage and process. So in the end depending on "unique"
> design features and parasitic effects was a very bad thing. Maybe if the
> simulators had been used, then the circuit produced would have been more
> stable.

I agree, but that's not the point.  The original poster explicitly said they wanted to duplicate Thompson's experiment.  I was pointing out why using a simulator would not work for that purpose.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


--------------DA6EFAEDCB6E798B82EB9C20
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;Dave
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;-16464
fn:Dave Vanden Bout
end:vcard

--------------DA6EFAEDCB6E798B82EB9C20--

Article: 21808
Subject: Re: FPGA openness
From: Zoltan Kocsi <root@127.0.0.1>
Date: 01 Apr 2000 22:59:53 +1000
Links: << >>  << T >>  << A >>
galexand@sietch.bloomington.in.us (Greg Alexander) writes:

> First off, I don't.  I asked if they did and people told me I didn't want
> them to, and I rebutted those claims.  Other people (i.e. Peter Alfke) were
> blatantly rude and I unfortunately responded in kind.  Some people told me
> of solutions to different problems and I've thanked them but pointed out
> that those were not solutions to my problems.

I think that was quite a nice summary of the thread.

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 21809
Subject: Re: FPGA openness
From: Zoltan Kocsi <root@127.0.0.1>
Date: 01 Apr 2000 23:11:55 +1000
Links: << >>  << T >>  << A >>
"Gary Watson" <gary@nexsan.sex> writes:

> They suggest copyrighting your bitstream
> (and putting a notice of this on the silkscreen on the board) 

Can you do that ? I mean copyright an arbitrary sequence of bits,
with all the DMCA protection, 70 years after author's death and all ?
What is the minimum length ? 

Thanks,

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 21810
Subject: Re: Adrian Thompson's and GA work on Xilinx
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 01 Apr 2000 08:50:49 -0500
Links: << >>  << T >>  << A >>
Dave Vanden Bout wrote:
> 
> > > Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population.  Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge.  These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked.
> > >
> > > --
> > > || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> > > || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> > > || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
> >
> > I don't know that I have read about Thompson's work in particular, but I
> > do remember reading about some efforts in genetic programming. The
> > circuit produced did what it was required, but produced some glitches in
> > the output and as you say, it used circuitry in very unusual ways. The
> > end result was that the circuit was not stable over normal variations
> > such as temp, voltage and process. So in the end depending on "unique"
> > design features and parasitic effects was a very bad thing. Maybe if the
> > simulators had been used, then the circuit produced would have been more
> > stable.
> 
> I agree, but that's not the point.  The original poster explicitly said they wanted to duplicate Thompson's experiment.  I was pointing out why using a simulator would not work for that purpose.
> 
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||

I understand what the poster was asking. I am asking why anyone would
want to design circuits that can not be used in applications due to
their extreme sensitivity to uncontrolled parameters. 

So what is the value of research that is finding better ways to design
lousey circuits? Is there some reason that this type of circuit is good?
Or are they just a stepping stone to being able to design good circuits?
If so, I would think that they would want to consider finding techniques
to directly design good circuits.

One thought; if you are using evolution in the literal sense, then
couldn't you do your conditioning (testing) in an environment that
varies voltage, temperature and process?


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 21811
Subject: Re: FPGA openness
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 01 Apr 2000 16:45:00 GMT
Links: << >>  << T >>  << A >>

Gary Watson wrote:

> So now that I've looked into it, I don't have such a problem with Xilinx
> keeping the bitstream format confidential, and it's good to see that they
> have a logical reason for it (I never believed that it had to do with
> product support calls, to be quite honest, no offense to the guy from
> Xilinx).
>
> In the same section they talk about an interesting security technique --
> load the bitstream during manufacturing, and use a little lithium battery to
> keep the configuration loaded when power is off.  This would make
> reverse-engineering the chip nearly impossible (cheaper to hire thugs to
> break into the competitor and take the design at gunpoint, in fact).  Have
> any of you tried this battery backup technique?

Gary, what you read has been in the Xilinx data book for more than five years,
and I wrote it.
I always assumed that people would read our data book ( it has an index !), so
I elaborated here on the secondary aspect.

And yes, games and set-top box designs have used the battery method. It was a
bit easier with the older and smaller parts, like XC3000L that had very low
Powerdown current, but that has now also come back with the SpartanXL.

Hope this thread is over, soon.

Greetings
Peter Alfke ( "the guy from Xilinx")

Article: 21812
Subject: Re: FPGA openness
From: Ray Andraka <randraka@ids.net>
Date: Sat, 01 Apr 2000 16:46:06 GMT
Links: << >>  << T >>  << A >>

Yup, it works.  Most commercial customers find it unacceptable however, as the
product is then life limited to the shelf life of the battery.

Gary Watson wrote:

> In the same section they talk about an interesting security technique --
> load the bitstream during manufacturing, and use a little lithium battery to
> keep the configuration loaded when power is off.  This would make
> reverse-engineering the chip nearly impossible (cheaper to hire thugs to
> break into the competitor and take the design at gunpoint, in fact).  Have
> any of you tried this battery backup technique?

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21813
Subject: Re: FPGA openness
From: "Gary Watson" <gary@nexsan.sex>
Date: Sat, 1 Apr 2000 21:09:08 +0100
Links: << >>  << T >>  << A >>
Peter Alfke <palfke@earthlink.net> wrote in message
news:38E627A1.39526DF4@earthlink.net...
>
> Gary Watson wrote:
>
> > So now that I've looked into it, I don't have such a problem with Xilinx
> > keeping the bitstream format confidential, and it's good to see that
they
> > have a logical reason for it (I never believed that it had to do with
> > product support calls, to be quite honest, no offense to the guy from
> > Xilinx).
> >
> > In the same section they talk about an interesting security technique --
> > load the bitstream during manufacturing, and use a little lithium
battery to
> > keep the configuration loaded when power is off.  This would make
> > reverse-engineering the chip nearly impossible (cheaper to hire thugs to
> > break into the competitor and take the design at gunpoint, in fact).
Have
> > any of you tried this battery backup technique?
>
> Gary, what you read has been in the Xilinx data book for more than five
years,
> and I wrote it.
> I always assumed that people would read our data book ( it has an index
!), so
> I elaborated here on the secondary aspect.

Did you get the impression from the postings to this thread that everybody
had read this part of the data book?  Didn't seem that way to me.  Besides,
I've been boycotting you guys for 12 years so I haven't read the docs in the
interim.  The boycott ended two weeks ago, and I'm working on a couple of
new FPGA designs, one based on the 4000 series, and the other will be a
mid-range Virtex-E most likely.  Personally, I haven't the slightest
interest in the bitstream format and as I say, it makes sense that it is
proprietary.  As a matter of fact, you ought to consider some kind of OTP
key for an embedded cipher, so that our bitstreams will not work unless the
key is programmed into the chip.  A less-attractive alternative would be an
embedded serial number which forms a key.

--

Gary Watson
gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com




Article: 21814
Subject: Bitstream Format of Xilinx 4000 and Virtex Available for Download Here!
From: "Gary Watson" <gary@nexsan.sex>
Date: Sat, 1 Apr 2000 21:11:40 +0100
Links: << >>  << T >>  << A >>
Ha ha, April Fool!

((Greetings to Peter Alfke!))

--

Gary Watson
gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com



Article: 21815
Subject: Xilinx Foundation PAR hangs
From: "Greg Bezjak" <bezjak@gate.net>
Date: Sat, 1 Apr 2000 19:38:09 -0500
Links: << >>  << T >>  << A >>
I'm using the of the Xilinx Foundation student edition 1.5 and I can't seem
to complete the first example in "The Practical Xilinx Designer Lab Book"
(tripg_40).

I have entered the design using schematic entry.  I have assigned the I/O
pins using the .UCF file.  The target device is an 4005XLPC84.


The program hangs during implemenation.  Specifically during the Contructive
Placer section of Place&Route.


Lastly,  I am using Windows 98.  Using Deja.com, I have seen that the mapper
hangs under NT, but the fixes from the Xilinx site are NT specific.

My searches of the Xilinx support site seem to match just about EVERY
document or none of them.

Any help would be greatly appreciated.

Greg


Article: 21816
Subject: Re: Is there a Xilink PCI or ISA demo board with external connector?
From: Rozelle Schwarz <schwarz13@home.com>
Date: Sun, 02 Apr 2000 01:00:21 GMT
Links: << >>  << T >>  << A >>
Take a lookm at the APS-X208 board. The ISA BUS board has a socketed 208 pin QFP
which will take FPGAs from a 4005 upto a 4085XLA. The board supports 5v or 3.3v
FPGAs, has SRAM sockets and full windows support code. It also has a 96 pin VME
type connector out the back side of the PC. You can see the board and several
others like it at :

http://www.apsfpga.com



Gary Watson wrote:

> I'm looking for a Xilinx (will settle for Altera) demo board which plugs
> into a ISA or PCI slot, but where all the remaining I/O pins are brought out
> to a connector leading outside the PC chassis.  The board would only need
> the one chip on it, I figure, with the PC bus hooked up directly to the
> FPGA.  Don't think I need any RAM or other glue logic.
>
> If I can't find one, I'm going to make one myself.  Anybody else want one?
> I was going to use a part in the 20,000 to 40,000 gate region, like the 4000
> series.  I'll probably include A/D inputs on all external pins since this
> would improve it for my intended project.
>
> My purpose is twofold: (a) to learn how to use the Xilinx FPGA software, and
> (b) to use this gizmo to test SCSI backplane electronics including Low
> Voltage Differential terminators.   (Parenthetical quesiton -- does anybody
> know of the LVDS I/O pads in the Xilinx are close enough to the SCSI LVD
> specification for crude testing purposes?  SCSI uses an asymmetric variant
> of LVDS.)
>
> --
>
> Gary Watson
> gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
> Nexsan Technologies Ltd.
> Derby DE21 7BF  ENGLAND
> http://www.nexsan.com

Article: 21817
Subject: Viewlogic ViewSim/Vwaves question
From: steve (Steve Rencontre)
Date: Sun, 2 Apr 2000 03:00 +0100 (BST)
Links: << >>  << T >>  << A >>
If I use the ViewSim setmap command to define an additional logic state 
("setmap wh=p" so I can define external pullups), Vwaves will only display 
the simulation in bus format, not as waveforms. I can make ViewTrace 
display waveforms by a simple edit to the viewtrac.cfg file, but I can't 
seem to find any way of getting Vwaves to do it.

Anyone know how?

--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk
Article: 21818
Subject: Re: FPGA openness
From: krw@attglobal.net (Keith R. Williams)
Date: 2 Apr 2000 02:54:20 GMT
Links: << >>  << T >>  << A >>
On Sat, 1 Apr 2000 13:11:55, Zoltan Kocsi <root@127.0.0.1> wrote:

> "Gary Watson" <gary@nexsan.sex> writes:
> 
> > They suggest copyrighting your bitstream
> > (and putting a notice of this on the silkscreen on the board) 
> 
> Can you do that ? I mean copyright an arbitrary sequence of bits,
> with all the DMCA protection, 70 years after author's death and all ?
> What is the minimum length ? 

Sure.  The fact that you've created "art" means it's copyrighted.
 You can *register* a copyright and in fact you must if you wish 
to sue.

Certainly the bitstream fed into an FPGA is no different than a 
microcode ROM in an embedded controller.  Copyright laws 
certainly protect aginst such theft, if you catch the perp before
they've ruined your business, have tons of money to prosecute, 
and hope that they have some assets to go after.  Chances are 
that you won't find a perp stupid enough to fit all three 
catagories.

----
  Keith

Article: 21819
Subject: Re: 82C54
From: Marc Elpel <elpelrm@etxdesign.com>
Date: Sun, 02 Apr 2000 04:06:22 GMT
Links: << >>  << T >>  << A >>
I worked with an 82C54 Verilog design during a previous job.  The design
had been outsourced prior to me hiring on.  Unfortunately, I do not have
the orginal code still available, but I do have this advice:  Look at
costs prior to pursuing this implementaiton.

We found that the FPGA implementation cost of the 82C54 was
significantly higher than just buying a ~$2.00 part and placing it
externally.  We abandoned the development for the lower cost external
hardware.

Marc
-------------

Tomasz Brychcy wrote:
> 
> Hello,
> 
> I am writing a synthesisable model of 82C54 (Intel) and I have many
> questions to the circuit. Intel do not want to reply for these questions
> because the circuit is not supported now for Intel.
> 
> If somebody could help me please about reply
> 
> I will be very thankfull;
> 
> Tomek
> 
> tbrychcy@sensor.ime.pz.zgora.pl

Article: 21820
Subject: RISC/CISC Processor with Reconfigurable Logic
From: Anurag Tiwari <atiwari@cs.wright.edu>
Date: Sat, 1 Apr 2000 23:10:31 -0500
Links: << >>  << T >>  << A >>

Does anyone know pointers for research papers/research efforts proposed
for integrating conventional RISC/CISC Processors with Reconfigurable
logic.

--Anurag 

Article: 21821
Subject: Re: What's so good about antifuse???
From: Assaf Sarfati <assaf@cmt.co.il>
Date: Sun, 02 Apr 2000 09:14:31 +0200
Links: << >>  << T >>  << A >>


fulvs@my-deja.com wrote:
> 
> I'm trying to understand the difference between
> antifuse, SRAM and flash based FPGAs. I have 3
> questions and any comments on any of these would
> be much appreciated.
> 
> 1) Antifuse is purportedly cheaper, lower power,
> higher performance. Why is this? If this is true
> - how much cheaper, lower power etc?
> 
> 2) Other than military/aerospace, what
> applications are antifuse FPGAs used for? Aren't
> SRAM FPGAs much better because they're many times
> reprogrammable?
> 
> 3) Who is the best antifuse vendor?
> 
> Thanks in advance for your help.
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 

Any FPGA must have a programmable way to connect between two wires. In
every FPGA there is a very large number of these programmable
connections. Antifuse devices create a physical connection by blowing a
hole through a thin insulating layer between two metal layers; SRAM- and
Flash-based devices use a transistor controlled by a memory bit.

* Size, speed and power-consumption - see data-sheets. Every day someone
releases a newer, faster, better chip. Usually the SRAM-based devices
lead the size race; speed and power are very dependent on your specific
design and tools.

* Antifuse devices can be only programmed once; Flash devices can be
usually programmed about 100 times and SRAM devices can be "programmed"
(actually loaded) any number of times.

* Antifuse device, AFAIK, can't be programmed on-board; this is a major
manufacturing headache, especially with PQFP packages.
Updating/correcting an antifuse device requires desoldering it and than
soldering another chip - VERY hairy.

* SRAM devices require a separate, pretty expensive, ROM chip to hold
their configuration; if your system has a processor, it may be possible
to let the processor program the FPGA. Of course, if the FPGA is
required for system operation (e.g. memory controller or Chip-Select
decoder), you have a classic egg-and-chicken problem.

* Flash devices can usually be programmed on-board, by adding a small
connector (usually 8-20 pins) for an external serial programmer.

* Design security: antifuse devices are supposedly hardest to read-back;
flash devices usually have a security bit which makes reading them
harder; SRAM-based devices are pretty easy to copy - the data-stream is
out there for anyone to see.

In summary: I think that flash-based devices offer the best combination
of programmability, security and simple, cheap board design. If your
design will fit into a flash-based device (and they are not very common,
cheap or large), use a flash-based FPGA.

   Regards
   Assaf Sarfati

Article: 21822
Subject: Re: Virtex bitstreams wanted for compression study
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Sun, 02 Apr 2000 09:54:34 GMT
Links: << >>  << T >>  << A >>
On Thu, 30 Mar 2000 16:49:46 GMT, Tim Tyler <tt@cryogen.com> wrote:

>Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> wrote:
>
>: And don't worry, due to the secret nature of the Xilinx bitstreams, I
>: have no practical way of working out what your design does.
>
>Uploading it to a Virtex chip - and then treating its pins as the outputs
>from a black box - could give you a practical method of determining the
>function ;-)

I was just about to flame this when I saw the ;-) that I'd missed
earlier.
I had been very careful to say that it was not practical, rather than
impossible.

So far only Ray Andraka has been kind enough to send anything.

Come on guys, I'm sure several of you have Virtex files just sitting
around, blocking the view of the TV.  Send them to me!  Please.

Allan.

Article: 21823
Subject: Re: Bitstream Format of Xilinx 4000 and Virtex Available for Download
From: Eric GAUDET <egaudet@exoffice.com>
Date: Sun, 02 Apr 2000 11:08:56 +0000
Links: << >>  << T >>  << A >>
A I can see, I'm not the only one looking for such informations. More
seriously, is there any sram based for which these infos are available ?

Gary Watson wrote:
> 
> Ha ha, April Fool!
> 
> ((Greetings to Peter Alfke!))
> 
> --
> 
> Gary Watson
> gary@nexsan.sex  (Change dot sex to dot com to reply!!!)
> Nexsan Technologies Ltd.
> Derby DE21 7BF  ENGLAND
> http://www.nexsan.com
Article: 21824
Subject: Re: RISC/CISC Processor with Reconfigurable Logic
From: Jamil Khatib <khatib@ieee.org>
Date: Sun, 02 Apr 2000 13:55:49 +0200
Links: << >>  << T >>  << A >>
may be my page helps you
http://www.geocities.com/SiliconValley/Pines/6639/fpga

for more information feel free to ask

Jamil Khatib
OpenIP Organization

Anurag Tiwari wrote:

> Does anyone know pointers for research papers/research efforts proposed
> for integrating conventional RISC/CISC Processors with Reconfigurable
> logic.
>
> --Anurag



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search