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 42575

Article: 42575
Subject: Suspicious code in Verilog model for Xilinx DCM module
From: Stephen Williams <steve@icarus.com>
Date: 28 Apr 2002 02:28:30 GMT
Links: << >>  << T >>  << A >>
I've received reports that the DCM module from the Xilinx unisims
library is not working under Icarus Verilog, and I find in the
module this code to set the lock_period flag:

   if (period < clkin_edge[0] - clkin_edge[1] - 500)
     lock_period <= 0;
   else if (period > clkin_edge[0] - clkin_edge[1] + 500)
     lock_period <= 0;
   else if ((clkin_edge[0] != 1'bx) && (clkin_edge[1] != 1'bx))
     lock_period <= 1;

The "!= 1'bx" expressions in the third if statement are highly
suspicious. Those expressions should, as written, evaluate to
1'bx no matter what the value of clkin_edge[0] or [1], and that
lead to the final if case never being executed. Or at least that
is how I understand it, even when I read the Verilog standard
sideways.

So does this bit of code work for anybody? Does lock_period get
set for anybody who uses the DCM module from the Xilinx unisims
library?

Incidentally, replacing != with !== should fix it. I believe the
author is trying to check that the clkin_edge values are defined.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
steve at picturel.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

abuse@xo.com
uce@ftc.gov


Article: 42576
Subject: Re: SpartanII design considerations...
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 27 Apr 2002 22:02:10 -0500
Links: << >>  << T >>  << A >>
One problem I had a while ago with a Spartan-II datasheet was it didn't
say that Spartan-II IOB tri-state buffers are active low or high.
However, figures in the datasheet show OBUF and IOBUF don't have a
bubble in front of their OE (Output Enable) input, so I assumed that
tri-state buffers are active high.
Assuming that IOB tri-state buffers are active high, I tried to push IOB
FFs into IOBs, but didn't work.
After some investigation of past postings at news:comp.arch.fpga, I saw
some people saying that Virtex IOB tri-state buffers are active low, so
to confirm that, I did a search of Xilinx support page, and there I
finally found a page that said Virtex architecture's IOB tri-state
buffers are active low.
Why isn't such basic information not in the datasheet?
Does Xilinx assume that everyone who use Xilinx devices already know
that?
I didn't know that IOB tri-state buffers are active low because I had
very little experience dealing with FPGAs back then.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Peter Alfke wrote:
> 
> Rick, and others:
> We at Xilinx are very interested in any constructive suggestions how we can
> make our documentation, especially in my case the data sheet, clearer and
> easier to use.
> 
> My present idea ( for future data sheets) is a 3-tier hierarchy
> First a couple of pages of bullets and basic tables, device package
> combinations, and even the ordering info.
> Second about 20 pages with a sequence of terse descriptions of every (every!)
> feature, enough for te "normal" user, with extensive references to the third
> section. This second section act as a guide, preventing anybody from getting
> lost.
> The third section then spends as much space as needed to describe the subject
> in detail. That might be a hundred pages for some features, like
> microprocessors or Multi-Gigabit Transceivers.
> 
> The information is all there, even today. The problem is finding it...
> 
> Peter Alfke, Xilinx Applications
>

Article: 42577
Subject: Re: SpartanII design considerations...
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 28 Apr 2002 15:41:19 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Nicholas Weaver wrote:
> 
> > I
> >
> > Agreed.  I LOVE that diagram on the XC4K datasheets.  I'd love to see
> > the equivelent for Virtex/Virtex II family parts.
> >
> > It would also be a good "WHoah, there is a lot of routing" picture.
> > :)
> >
> 
> These drawings (and others) were killed because we did not want to call undue
> attention to the internal complexity of the FPGA structure. Especially when
> the main competitor brags about his no-brainer automatic "push-button"
> design.  :-(
> There is a fine line between explaining all the details and exotic
> capabilities, and scaring potential customers off. 

?! Sounds like a line from the marketing dept - ( perhaps they are 
the ones scared of complex documents ).  

 I have not found a real user yet that complained about too much detail, 
and these days, of non-printed manuals there is little cost to more
detail.
 ( there are plenty that grumble about what's not in the data sheets )
 
 The latest CoolRunner is a good example. The docs are so simplistic, I
decided the only way to understand just what would map onto the HW, was
do some test cases, and hope the reports were up to it.

> Unfortunately, the documentation cannot be censored or easily be 
> adapted to the intelligence ( or level of friendliness, patience, 
> and dedication ) of the user.

 I don't know, your idea of 3 tiers sounds pretty good to me.
( way more appealing than any sentance containing the 
words 'scaring potential customers off')
 
-jg

Article: 42578
Subject: static logic vs LUT
From: "crackeur" <crackeur@attbi.com>
Date: Sun, 28 Apr 2002 05:39:02 GMT
Links: << >>  << T >>  << A >>
In static logic, to implement a gigantic OR function, one may instead stack
up multiple layers of OR gates in order to optimize for performance. How
does
LUT work, is it any different? If I want to implement an OR function with
lots of inputs, does LUT do it better, or in otherwords, how does the FPGA
compiler optimize this using LUTs?

Jimmy



Article: 42579
Subject: Re: SpartanII design considerations...
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 28 Apr 2002 05:50:00 GMT
Links: << >>  << T >>  << A >>
It's the old confusion between output enable and tristate, which obviously are the
opposite of each other. But we should, therefore, make it redundantly absolutely
and perfectly clear that active High OE is identical with active Low 3-state ( and
vice versa).
Life is too precious to be wasted on such silly misunderstandings.

Peter Alfke, Xilinx Applications
=============================================
Kevin Brace wrote:

> One problem I had a while ago with a Spartan-II datasheet was it didn't
> say that Spartan-II IOB tri-state buffers are active low or high.
> However, figures in the datasheet show OBUF and IOBUF don't have a
> bubble in front of their OE (Output Enable) input, so I assumed that
> tri-state buffers are active high.
> Assuming that IOB tri-state buffers are active high, I tried to push IOB
> FFs into IOBs, but didn't work.
> After some investigation of past postings at news:comp.arch.fpga, I saw
> some people saying that Virtex IOB tri-state buffers are active low, so
> to confirm that, I did a search of Xilinx support page, and there I
> finally found a page that said Virtex architecture's IOB tri-state
> buffers are active low.
> Why isn't such basic information not in the datasheet?
> Does Xilinx assume that everyone who use Xilinx devices already know
> that?
> I didn't know that IOB tri-state buffers are active low because I had
> very little experience dealing with FPGAs back then.
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)
>
> Peter Alfke wrote:
> >
> > Rick, and others:
> > We at Xilinx are very interested in any constructive suggestions how we can
> > make our documentation, especially in my case the data sheet, clearer and
> > easier to use.
> >
> > My present idea ( for future data sheets) is a 3-tier hierarchy
> > First a couple of pages of bullets and basic tables, device package
> > combinations, and even the ordering info.
> > Second about 20 pages with a sequence of terse descriptions of every (every!)
> > feature, enough for te "normal" user, with extensive references to the third
> > section. This second section act as a guide, preventing anybody from getting
> > lost.
> > The third section then spends as much space as needed to describe the subject
> > in detail. That might be a hundred pages for some features, like
> > microprocessors or Multi-Gigabit Transceivers.
> >
> > The information is all there, even today. The problem is finding it...
> >
> > Peter Alfke, Xilinx Applications
> >


Article: 42580
Subject: Re: static logic vs LUT
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 28 Apr 2002 06:05:44 GMT
Links: << >>  << T >>  << A >>
Any one LUT takes 4 inputs (any function you want).
You can then concatenate LUTs through the carry chain at no extra cost in
area, and about 30 ps additional delay per LUT used.

Peter Alfke, Xilinx Applications
================================
crackeur wrote:

> In static logic, to implement a gigantic OR function, one may instead stack
> up multiple layers of OR gates in order to optimize for performance. How
> does
> LUT work, is it any different? If I want to implement an OR function with
> lots of inputs, does LUT do it better, or in otherwords, how does the FPGA
> compiler optimize this using LUTs?
>
> Jimmy


Article: 42581
Subject: fpga unpackaged dies
From: nurit.eliram@mailandnews.com (Nurit Eliram)
Date: 28 Apr 2002 01:07:12 -0700
Links: << >>  << T >>  << A >>
Hi.
I chack the possibility to produce a module chip that in composed from
1 fpga die + a die of my chip packed together.

Is there any fpga vendor that sell unpackaged (naked) dies ?


Thanks ;
Nurit.

Article: 42582
Subject: Re: uniquifying a synplicity netlist
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 28 Apr 2002 09:53:06 +0100
Links: << >>  << T >>  << A >>


strut911 wrote:

> hi john,
> thanks for the response. the simulator i am using is cadence
> NC-Verilog 3.3. it is a good simulator, and one of the standard
> verilog simulators in the asic industry. the problem is that if you
> compile two modules with the same name within the same design, it will
> exit with an error. i can understand the safety precautions that this
> check implements, but in the asic flow, you can uniquify your netlist
> which would eliminate these problems. Synopsys Design Compiler is
> conducive to a modular type of design flow, but i find increasingly
> that synplicity does not work that way. the main reason i would like
> to create a modular design where i can individually synthesize parts
> is that i would like to floorplan critical areas, and not have to
> touch them ever again. this would be an incredible help to me. i would
> normally sing the praises of synplicity, but i really wish that they
> could implement something like this. either that or maybe i have not
> come across a solution or workaround yet.
> strut911

I do this ``bottom up'' stuff as well at least to the extent that I have
one top level module which instantiates a number of level 2 modules each
of which is synthesised separately. Here's what I do.
It works for ModelSim and there should be some equivalent for NC.

o First I don't normally directly post-synth simulate but use NGDBUILD to
glue all
   the various edif netlists together and then generate a post-NGD
netlist. Only if I find an
   error while simulating this and cannot track it down directly (this is
rare) then ...

o ... I  pre-process each of the .vm post-synth netlists to do these
things

  - Remove the LUT module defintions
  - Change the LUT instantiations to be compatible with the Xilinx unisims
lib. i.e.
     LUT4_WXYZ -> defparam INIT = WXYZ; LUT4 ...
  - Remove all the other module definitions to a separate library. Call it
e.g. synplify_lib or
     some such. [the reason behind this is that the unisims FF models are
IMO a load of rubbish].

o Now compile each of the modified .vm files into a library and also
synplify_lib

o When starting ModelSim I give it a long list of `-L <compiled.vm>' flags
followed by `-L unisims' and
   `-L synplify_lib'.

This gets around the mutliple LUT problem but does not get around the
issue where I'm instantiating some common module in several of the level 2
ones e.g. a FIFO. Unless the common module is synthesised with
"syn_hier=hard" 2 different .vm netlists may contain this FIFO
instantiated under the same name but with different port definitions as
Synplify has optimised across the boundaries.

For ModelSim the trick is to make `-L work' the first library definition
on the startup command line.
What this this tells the simulator is to always use the current library to
satisfy an  instantiation. [I used to use yet another Perl script that
messed around with `uselib]. I think this should work for any Verilog-XL
compatible simulator.

Note that this idea of compiling all the .vm (or modified .vm) files into
separate libs allows mixed RTL/synth simulations; only using the .vm for
the suspect level 2 module.


Article: 42583
Subject: Re: ChipScope ILA, cable requirements
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 28 Apr 2002 10:02:08 +0100
Links: << >>  << T >>  << A >>


Jason Moore wrote:

> Hi Andrew,
> You can use the Parallel Cable for Chipscope.  I use it to demonstrate
> the functionality of the tool and nearly all of my customers use it
> instead of MultiLinx.  It supports the transfer of data in both
> directions PC -> FPGA and FPGA -> PC.  As you said the only difference
> is speed.
>
> Thanks
> Jason
>
>

The parallel-3 cable uses one of the dedicated Centronics printer->PC control lines to return TDO data.


Article: 42584
Subject: Re: SpartanII design considerations...
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sun, 28 Apr 2002 12:00:33 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote

> These drawings (and others) were killed because we did not want to call undue
> attention to the internal complexity of the FPGA structure. Especially when
> the main competitor brags about his no-brainer automatic "push-button"
> design.  :-(

I guess these diagrams were at their most complete in the ORCA data
sheets, and where did it get them :-)   Maybe in an appendix?





Article: 42585
Subject: How can I test a downloaded design?
From: "gianzi" <zisis@mhl.tuc.gr>
Date: Sun, 28 Apr 2002 14:24:22 +0300
Links: << >>  << T >>  << A >>
Hi all,
I have a Virtex xcv1000 laying on a board, and a Multilinx cable.
Can anyone tell me if there is some way to pass test vectors to a downloaded
design through Multilinx and the software provided by ISE 4.1, and also read
the outputs and save them in a file?
I really need any availiable help with this!




Article: 42586
Subject: Where can I get basic knowledge for LFSR and Module-2 theory
From: lyqin@cti.com.cn (Leon Qin)
Date: 28 Apr 2002 05:12:02 -0700
Links: << >>  << T >>  << A >>
thanks

Article: 42587
Subject: Re: SpartanII design considerations...
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 28 Apr 2002 10:40:30 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Nicholas Weaver wrote:
> 
> > I
> >
> > Agreed.  I LOVE that diagram on the XC4K datasheets.  I'd love to see
> > the equivelent for Virtex/Virtex II family parts.
> >
> > It would also be a good "WHoah, there is a lot of routing" picture.
> > :)
> >
> 
> These drawings (and others) were killed because we did not want to call undue
> attention to the internal complexity of the FPGA structure. Especially when
> the main competitor brags about his no-brainer automatic "push-button"
> design.  :-(
> There is a fine line between explaining all the details and exotic
> capabilities, and scaring potential customers off. Unfortunately, the
> documentation cannot be censored or easily be adapted to the intelligence (
> or level of friendliness, patience, and dedication ) of the user.
> 
> Peter Alfke, Xilinx Applications

I understand the concern.  I for one have been scared off from doing my
own routing long ago.  But that does not keep me from using the parts. 
The scary part of the A product is the software.  Not only can't you
manually route the design, you can't even see the routing to know if the
software did a good job.  You get a single number to describe each route
and that is the delay time.  

I don't think seeing a complex routing picture would scare off users,
especially if it is in the third section you described above.  

BTW, I would recommend that the sections be provided both partitioned
and together in a single document.  Perhaps you could have three docs,
one with just section 1, the next with both 1 and 2 and a third document
with all three sections in a single document.  It can be very clumsy to
browse through multiple documents as you have heard about the current
sectioned documents.  This way a user always has a good trade off
between completeness and size.  

-- 

Rick "rickman" Collins

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

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42588
Subject: Re: SpartanII design considerations...
From: emanuel stiebler <emu@ecubics.com>
Date: Sun, 28 Apr 2002 08:52:13 -0600
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Tim wrote
> 
> > One splendid feature of Xilinx data sheets of yore, seemingly now
> > out of favor, was the "differences from previous generation" page.
> > Taking a leaf out of consumer electronics user guides, perhaps this
> > should be "even if you (think) you are an expert, read this" :)
> 
> Thanks, that was my idea, and my doing.
> But for almost ten years, nobody (nobody!) ever expressed any appreciation for
> it.
> Not Marketing, not Sales, and not even the users.  The classical question "who
> cares?"
> Lots of good ideas die when there is no feedback...

Because it sound like a "wishlist" already.
What about a table with all(?) the differences between the chips of one 
family ? So one could see in ONE table the differences (like i/o
standards
in spartan/xl/ii/iie/...) And having the same layout of the table for
different
families (xc4, spartan, virtex) ?

cheers

Article: 42589
Subject: Xilinx
From: "Maciek" <mkazula@elka.pw.edu.pl>
Date: Sun, 28 Apr 2002 17:41:48 +0200
Links: << >>  << T >>  << A >>
    Does anybody know, that Xilinx XC2S-50 and XCS30XL need fan(or cooler).
  Maciek



Article: 42590
Subject: Re: Xilinx
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 28 Apr 2002 16:43:32 GMT
Links: << >>  << T >>  << A >>
The short answer is: These small chips do NOT need a fan or cooler.

The long answer is: There is no fixed power consumption in an FPGA. It all
depends on the design and the clock rate(s). If you run the whole chip as a
gigantic 400 MHz toggling shift register ( which you can do, although it is
meaningless), then you will see high power consumption. Some highly pipelined
big DSP designs can dissipate >10W, and they need some cooling. But they are
in much bigger chips than you have mentioned.

Peter Alfke, Xilinx Applications

Maciek wrote:

>     Does anybody know, that Xilinx XC2S-50 and XCS30XL need fan(or cooler).
>   Maciek


Article: 42591
Subject: Re: Xilinx
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Sun, 28 Apr 2002 17:01:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3CCC26A4.BCCDB647@earthlink.net>,
Peter Alfke  <palfke@earthlink.net> wrote:
>The short answer is: These small chips do NOT need a fan or cooler.
>
>The long answer is: There is no fixed power consumption in an FPGA. It all
>depends on the design and the clock rate(s). If you run the whole chip as a
>gigantic 400 MHz toggling shift register ( which you can do, although it is
>meaningless), then you will see high power consumption. Some highly pipelined
>big DSP designs can dissipate >10W, and they need some cooling. But they are
>in much bigger chips than you have mentioned.

That sounds like a challange:  Can I do a real app on a XC2S-50 which
would require a heatsink? :)

Actually, probably not.  The power estimator suggests that Gb rate
encryption requires only 2.5W (XC2S-100, Rijndael, my design), so
adding in IO to do a gigabit link-level encryption engine and it would
still be fairly low power.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42592
Subject: Re: Controller Initial State
From: "Hristo Stevic" <hristostev@yahoo.com>
Date: Sun, 28 Apr 2002 21:30:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
any input here??



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 42593
Subject: Re: SpartanII design considerations...
From: Ray Andraka <ray@andraka.com>
Date: Sun, 28 Apr 2002 22:32:02 GMT
Links: << >>  << T >>  << A >>
A summary sheet listing the deltas (in detail) from the previous family would
probably make a lot of people happy.

Peter Alfke wrote:

> Rick, and others:
> We at Xilinx are very interested in any constructive suggestions how we can
> make our documentation, especially in my case the data sheet, clearer and
> easier to use.
>
> My present idea ( for future data sheets) is a 3-tier hierarchy
> First a couple of pages of bullets and basic tables, device package
> combinations, and even the ordering info.
> Second about 20 pages with a sequence of terse descriptions of every (every!)
> feature, enough for te "normal" user, with extensive references to the third
> section. This second section act as a guide, preventing anybody from getting
> lost.
> The third section then spends as much space as needed to describe the subject
> in detail. That might be a hundred pages for some features, like
> microprocessors or Multi-Gigabit Transceivers.
>
> The information is all there, even today. The problem is finding it...
>
> Peter Alfke, Xilinx Applications
>
> rickman wrote:
>
> > Hal Murray wrote:
> > >
> > > >Thanks for the post Ray.  But I understand how the DLL works, at least
> > > >at the top level of understanding.  What I don't know is how all the
> > > >clock resources in the chip play together.  Somehow I had gotten the
> > > >impression that the DLLs and the clock buffers could be used separately
> > > >to let you route up to 8 clocks around on the chip.  It would appear
> > > >that I was wrong.
> > >
> > > The data sheets usually describe the clock distribution resources.
> > > I'm sure it's in there now that you know what to look for.
> > >
> > > Whenever I start working with a chip, I usually spend a lot of time
> > > with the FPGA Editor (XACT?) learning the details of the special
> > > routing resources.  That involves iterations of reading the data
> > > sheets, making test cases, seeing what really results...  There
> > > are occasional "Ahh.  That's what that section was telling me."
> > >
> > > Maybe I work/think at too low a level and should just push the big
> > > green button, but I always end up pushing some timing limit.  I'm
> > > not sure how to do that if I don't know what I want the tools to
> > > produce.
> >
> > Yes, that is what I always end up doing.  But it takes a lot of time and
> > if the documentation was more clear, this interaction with the graphic
> > tools would not be required to learn the architechture.  However you
> > always have the need to learn what the HDL tools are doing with your
> > design.  I have never seen a tool that did not need a babysitter.
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

--
--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: 42594
Subject: Re: SpartanII design considerations...
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 28 Apr 2002 23:31:07 GMT
Links: << >>  << T >>  << A >>
Ok. I'll work on it, and post it here to start with.
Peter

Ray Andraka wrote:

> A summary sheet listing the deltas (in detail) from the previous family would
> probably make a lot of people happy.
>


Article: 42595
Subject: FlexLM
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 28 Apr 2002 23:32:56 GMT
Links: << >>  << T >>  << A >>
I would like to know who invented FlexLM.  This product has been in use for
a while with some major EDA vendors, and apparently it is providing a very
good job of protecting the integrity and use of the products that use it.  I
am surprised that in this world of breaking codes, someone hasn't broken the
FlexLM code.  Don't get me wrong.  I am very much in favor of protecting the
intellectual property rights of companies or people who develop and market
products, and I am glad that it hasn't been broken.

I did hear about 3-5 years ago that someone in Hong Kong had broken the code
on FlexLM, but I then heard that this was incorrect.  I salute a product
that has protected EDA products for years and has managed to stay unbroken
for so long.

Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA



Article: 42596
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: Ray Andraka <ray@andraka.com>
Date: Sun, 28 Apr 2002 23:44:29 GMT
Links: << >>  << T >>  << A >>
Reminds me of Poly-Paks.  For those of you who weren't around back then,
Poly-Paks was a company in the 70's that sold cut rate electronics of dubious
origin to hobbyists.  For some, the availability of dirt cheap, albeit not 100%
parts can make the difference between playing with this stuff or just reading
about it.  When I started playing with electronics, about all a newspaper route
would support was the Poly-Paks specials.  Of course in those days, one could
get away with dead-bug construction and still get something working.

Falk Brunner wrote:

> "Johann Glaser" <Johann.Glaser@gmx.at> schrieb im Newsbeitrag
> news:a9q3it$5enur$1@ID-115042.news.dfncis.de...
>
> > Would it be possible to offer medium size and large size parts (like
> > XC2S200, ...) for hobbyists, prototyping (or even production) at a really
> > low price, but with some small errors. E.g. that one or several (of the
> > many available) CLBs are defect.
>
> Come on, the Spartan-II(E)s are really cheap, have a look at
>
> www.nuhorizons.com
>
> even a poor student can afford them. So I really DONT like to play with a
> just partly functioning IC, especially NOT for development. Debugging you
> own mistakes is hard enough..
>
>  --
> MfG
> Falk
>
> P.S. There is no real possibility to get single quantities of the fine
> Xilinx parts in germany (for hobby stuff) :-(

--
--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: 42597
Subject: Re: Price List ?
From: dMon <fragnet@excite.com>
Date: Mon, 29 Apr 2002 00:03:31 GMT
Links: << >>  << T >>  << A >>
Try www.partsminer.com

On Fri, 12 Apr 2002 14:27:04 -0700, Peter Alfke
<peter.alfke@xilinx.com> wrote:

>I tried it, and found it fast and intuitive, but unforyunately almost worthless
>since it does not cover the major distributors.
>Nice try, but no cigar.
>
>Peter Alfke, Xilinx Applications
>==========================
>Petter Gustad wrote:
>
>> Try
>>
>> http://findchips.com/
>>
>> This will search through several of the distributor sites for you.
>>


Article: 42598
Subject: Re: FlexLM
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Mon, 29 Apr 2002 00:47:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <IE%y8.118703$nc.17199086@typhoon.tampabay.rr.com>,
S. Ramirez <sramirez@cfl.rr.com> wrote:
>I would like to know who invented FlexLM.  This product has been in use for
>a while with some major EDA vendors, and apparently it is providing a very
>good job of protecting the integrity and use of the products that use it.  I
>am surprised that in this world of breaking codes, someone hasn't broken the
>FlexLM code.  Don't get me wrong.  I am very much in favor of protecting the
>intellectual property rights of companies or people who develop and market
>products, and I am glad that it hasn't been broken.

Well, partially, not many people actually use such products, so the
incentive to break them is low.

Secondly, the floating liscence scheme is far less intrusive than
others, again, lowers incentive.

Finally, most of the applications which USE FlexLM are expensive cad
tools, where the people buying them are paying for tech support as
much as the tools themselves.



-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42599
Subject: Re: Xilinx Easypath- Selling parts with known defects
From: "Jan Gray" <jsgray@acm.org>
Date: Sun, 28 Apr 2002 17:53:50 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote
> Of course in those days, one could
> get away with dead-bug construction and still get something working.

http://groups.yahoo.com/group/fpga-cpu/message/1111 (!)

Jan Gray, Gray Research LLC






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