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 36200

Article: 36200
Subject: Re: Cloning someone else's IP core
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Thu, 01 Nov 2001 19:48:25 GMT
Links: << >>  << T >>  << A >>
In the documentary "Triumph of the Nerds," Robert Cringely retells the
interesting story of how the first PC was cloned by Compaq and this sheds
some light on the legalities of reverse engineering.  IBM had made the PC
with completely off-the-shelf parts with the exception of the BIOS.  IBM
thought this BIOS would keep their architecture from being copied.  Compaq
had a bunch of engineers write a spec on the BIOS ROM which described its
functionality.  Then a group of "virgin" engineers that had never opened an
IBM PC were put in a room for 2 months with the spec (sequestered from the
world) until they created a functionally equivalent BIOS.  All legal.  This
cost $2 million.  Then Compaq made a clone had the best first-year sales in
history.

"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3BD9DF5B.6E989397@flukenetworks.com...
> Kevin Brace wrote:
> >
> > I will like to know what happens when someone designs a compatible IP
> > core of someone else's IP core?
>
> If they write their own source code, I expect it would be ok.
>
> > It looks like already a company called AMI Semiconductor
> > cloned Xilinx's LogiCORE PCI IP core according to this EE Times
> > article.
> > http://www.eetimes.com/story/OEG20010907S0103
>
> The article describes a core netlist conversion where the
> customer didn't own the source code.
> This is a good example of why you want to get the
> source code if you buy a core.
>
> > Here is the actual product page for AMI Semiconductor's Xilinx
> > compatible PCI IP core.
> >
> > http://www.amis.com/trans/xilinx-pci.cfm
> >
> > Despite the fact the AMI Semiconductor cloned Xilinx's PCI IP core, it
> > looks like Xilinx hasn't taken any legal action against AMI
> > Semiconductor.
> > Does that mean that the IP core vendor has no way from stopping
> > someone from cloning their IP cores?
>
> AMI is selling their own source code here.
> This is no different than AMI second-sourcing an IC.
>
>         --Mike Treseler



Article: 36201
Subject: Re: Help with a 1996 XC3064 design!!
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 1 Nov 2001 22:03:38 +0100
Links: << >>  << T >>  << A >>

"Peter" <z80@ds2.com> schrieb im Newsbeitrag
news:5n63utglhcb9tojvc0cicqrn46avdaj862@4ax.com...
> Hello,
>
> In 1996 I designed a complicated pulse generator which used 32
> identical XC3064 modules. There are 32 TQFP packages of these, plus
> one XC3030 for address decoding etc (this is an ISA card).

Hmm, dont know so much about the 3k series in the good old times. But I
think all these 32 3k parts can be combined into 1 or two uptodate parts
(Virtex-E, Virtex-II)

> The 3k series device is now obsolete. I would also not like to risk
> rebuilding this board with some newer XC3064s because I know the more
> recent devices are much faster and some structures don't work anymore,

Nasty asynchronous tricks ?? ;-)

> e.g. shift registers which use local interconnects for the clock line.

Hmm, how many clock nets do you need? Remember the Virtex-II series offers
16 clock nets, even in the smallest part.

> Now the customer wants three more of these very expensive boards!
>
> If I have timing problems, I may have to re-do the design. The design
> was done in Viewlogic 4 (under MS-DOS, a very solid package but I
> cannot run it anymore). I do have printouts of the circuits inside the
> FPGAs.

Schematics?? Hmm, so a easy way would be simply to enter them again into
schematics. Or convert them to HDL, makes them more portable. NOOO, no HDL
vs. schematics struggle here ;-)

> I would appreciate any suggestions.

Hmm, you maybe better check your design against "nasty" asynchronous tricks,
then new fast parts can bite you quite hard.

--
MfG
Falk




Article: 36202
Subject: XC6000
From: "Pedro Alexandre" <pedro_alves.4@netc.pt>
Date: Thu, 1 Nov 2001 21:36:01 -0000
Links: << >>  << T >>  << A >>
Hello

Does anyone remember the HOT Works board with the xc6216 (and 2MB SRAM)?
I'm working on that board and I'm implementing a circuit that reads some
portions of memory, acumulate its contents and writes the result to SRAM.
I'm experiencing some problems accessing the on-board SRAM. With a 32 bit
access from the XC6000, some significant bits are wrong. It may be a problem
with the frequency because the circuit worked fine with a step by step user
clock. I've tried to lower the frequency to its minimum value (1MHz/2) by
software (JAVA), and the problem is still there. Does anyone had the same
problem? An internal freq. divider would solve the problem?

thanks,
pedro

--
___________________________________
                    _.._
                  .' .-'`
                 /  /
                 |  |
                 \  \
                  '._'-._
                     ```
                        ,     ,
                        |\---/|
                       /  , , |
                  __.-'|  / \ /
         __ ___.-'        ._O|
      .-'  '        :      _/
     / ,    .        .     |
    :  ;    :        :   _/
    |  |   .'     __:   /
    |  :   /'----'| \  |
    \  |\  |      | /| |
     '.'| /       || \ |
     | /|.'       '.l \\_
     || ||             '-'
     '-''-'




Article: 36203
Subject: Re: Hard macro in xilinx
From: "Bryan" <bryan@srccomp.com>
Date: Thu, 1 Nov 2001 16:28:08 -0700
Links: << >>  << T >>  << A >>
Once you open your design in FPGA editor go and delete the IOB, delete the
net and add the external macro pin to the slice connection or whatever your
component is.  I used hard macros in Lucent Orca 3T all the time.  They work
great, you can even do the routing yourself.  I tried to do a couple for
virtex-II and they wouldn't work because of the builtin VCC and GND
connections in the FPGA.  The macros I tried to build used these and the
mapper didn't like these being in the macro.  I tried not putting them in,
putting them in etc...   Never could get it to work.  Has anyone had luck
making hard macros at all in the Virtex-II parts?

I ended up using RPM macros for my virtex-II design.  I would still like to
use a hard macro for a FIFO I have in my design.  I have 16 of these FIFOs
that all have separate input clocks.  I also have 4 other clocks in my
design.  So my FIFO clocks can not all be on global clock routing.  I would
like to make a hard macro where I hard route these clocks so I can balance
the skew myself.  Easy enough to do if the tools would support hard macros.
I was told by FAE that xilinx would rather see everyone go the way of RPM
macro.  So there was little support from him for getting hard macros to
work.

Bryan


"mbonnici" <mbonnici@r-and-d.de> wrote in message
news:32f57107.0110310650.6ee42b86@posting.google.com...
> I would like to know how to make a hard macro in Xilinx (after place
> and route)
> I open the design_file.ncd in FPGA editor and saves the design as a
> macro. The real problem is to
> change an IOB into a macro external pin.
> Anybody have a solution
> Thanks
> mbonnici



Article: 36204
Subject: Re: Help with a 1996 XC3064 design!!
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 01 Nov 2001 16:38:29 -0800
Links: << >>  << T >>  << A >>
If you want to copy, not chenge, the design, I would just try to buy "good old"
XC3000 devices or XC3000A devices ( bitstream compatible), and expect them to
work. They haven't been sped up that much  :-)
This assumes that the "dirty tricks" are not too dirty.
I know Peter is an experienced designer and knows what he is doing.

I am sure there are parts around. If you cannot find them, I offer help.
e-mail me...

Peter Alfke
=====================================
Falk Brunner wrote:

> "Peter" <z80@ds2.com> schrieb im Newsbeitrag
> news:5n63utglhcb9tojvc0cicqrn46avdaj862@4ax.com...
> > Hello,
> >
> > In 1996 I designed a complicated pulse generator which used 32
> > identical XC3064 modules. There are 32 TQFP packages of these, plus
> > one XC3030 for address decoding etc (this is an ISA card).
>
> Hmm, dont know so much about the 3k series in the good old times. But I
> think all these 32 3k parts can be combined into 1 or two uptodate parts
> (Virtex-E, Virtex-II)
>
> > The 3k series device is now obsolete. I would also not like to risk
> > rebuilding this board with some newer XC3064s because I know the more
> > recent devices are much faster and some structures don't work anymore,
>
> Nasty asynchronous tricks ?? ;-)
>
> > e.g. shift registers which use local interconnects for the clock line.
>
> Hmm, how many clock nets do you need? Remember the Virtex-II series offers
> 16 clock nets, even in the smallest part.
>
> > Now the customer wants three more of these very expensive boards!
> >
> > If I have timing problems, I may have to re-do the design. The design
> > was done in Viewlogic 4 (under MS-DOS, a very solid package but I
> > cannot run it anymore). I do have printouts of the circuits inside the
> > FPGAs.
>
> Schematics?? Hmm, so a easy way would be simply to enter them again into
> schematics. Or convert them to HDL, makes them more portable. NOOO, no HDL
> vs. schematics struggle here ;-)
>
> > I would appreciate any suggestions.
>
> Hmm, you maybe better check your design against "nasty" asynchronous tricks,
> then new fast parts can bite you quite hard.
>
> --
> MfG
> Falk


Article: 36205
Subject: Re: Help with a 1996 XC3064 design!!
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 02 Nov 2001 05:17:16 GMT
Links: << >>  << T >>  << A >>
Peter,
If you worry about excessive speed, you might use XC3000L, which uses 3.3
V for Vcc, and ways was slower.  Pin- and bitstream compatible...

Peter Alfke

Peter wrote:

> Hello,
>
> In 1996 I designed a complicated pulse generator which used 32
> identical XC3064 modules. There are 32 TQFP packages of these, plus
> one XC3030 for address decoding etc (this is an ISA card).
>
> The 3k series device is now obsolete. I would also not like to risk
> rebuilding this board with some newer XC3064s because I know the more
> recent devices are much faster and some structures don't work anymore,
> e.g. shift registers which use local interconnects for the clock line.
>
> Now the customer wants three more of these very expensive boards!
>
> If I have timing problems, I may have to re-do the design. The design
> was done in Viewlogic 4 (under MS-DOS, a very solid package but I
> cannot run it anymore). I do have printouts of the circuits inside the
> FPGAs.
>
> I would appreciate any suggestions.
>
> Peter.
> --
> Return address is invalid to help stop junk mail.
> E-mail replies to zX80@digiYserve.com but remove the X and the Y.
> Please do NOT copy usenet posts to email - it is NOT necessary.


Article: 36206
Subject: Re: XC6000
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 02 Nov 2001 05:22:25 GMT
Links: << >>  << T >>  << A >>
If you have an error at such a low frequency, ( anything below 20 MHz ),
lowering the frequency even more will never cure the problem, since excessive
delay is not the cause.
(Almost fits on a fortune cookie...)

Peter Alfke
==========================
Pedro Alexandre wrote:

> Hello
>
> Does anyone remember the HOT Works board with the xc6216 (and 2MB SRAM)?
> I'm working on that board and I'm implementing a circuit that reads some
> portions of memory, acumulate its contents and writes the result to SRAM.
> I'm experiencing some problems accessing the on-board SRAM. With a 32 bit
> access from the XC6000, some significant bits are wrong. It may be a problem
> with the frequency because the circuit worked fine with a step by step user
> clock. I've tried to lower the frequency to its minimum value (1MHz/2) by
> software (JAVA), and the problem is still there. Does anyone had the same
> problem? An internal freq. divider would solve the problem?
>
> thanks,
> pedro
>
> --
> ___________________________________
>                     _.._
>                   .' .-'`
>                  /  /
>                  |  |
>                  \  \
>                   '._'-._
>                      ```
>                         ,     ,
>                         |\---/|
>                        /  , , |
>                   __.-'|  / \ /
>          __ ___.-'        ._O|
>       .-'  '        :      _/
>      / ,    .        .     |
>     :  ;    :        :   _/
>     |  |   .'     __:   /
>     |  :   /'----'| \  |
>     \  |\  |      | /| |
>      '.'| /       || \ |
>      | /|.'       '.l \\_
>      || ||             '-'
>      '-''-'


Article: 36207
(removed)


Article: 36208
Subject: Re: Synplicity, Xilinx, & unwanted BUFGs
From: Michael Boehnel <boehnel@iti.tu-graz.ac.at>
Date: Fri, 02 Nov 2001 11:23:43 +0100
Links: << >>  << T >>  << A >>
I add a constraint file "projectname.sdc" with the statement

define_global_attribute syn_noclockbuf           -comment {Disable
automatic BUFG/BUFGP insertion}  {1}

to the project. (This prevents Synplify to use BUFGs in general Be sure you
put the BUFGs to the right signals manually!)

Therefore you don't have to modify the source code. You can add this
attribute also with the Synplify's IDE.

Michael


"Jason T. Wright" wrote:

> How does one prohibit Synplify from inferring a global buffer?  I read
> the on-line help, and it mentions using an attribute in the VHDL (or
> verilog) code to FORCE a global buffer, but negating that attribute did
> not stop its insertion.  LeonardoSpectrum and FPGAExpress each has a
> command to stop such an undesired action (or, correspondingly, to force
> such an insertion.)   Left to their own devices, the tools can create
> wonderfully efficient, or wonderfully bloated, results from a user's
> code.  I've seen a little bit of each.
>
> --
> Jason T. Wright
>
> The opinions I express are my own ...
>     unless otherwise indicated!


Article: 36209
Subject: Re: Implementing Filter
From: vt313@comsys.ntu-kpi.kiev.ua
Date: Fri, 02 Nov 2001 13:03:57 +0200
Links: << >>  << T >>  << A >>
The Aldec Active HDL 4.2. has a core generator which
generates VHDL file for any FIR filter for XILINX FPGA.

fre wrote:
> 
> Holla
> Wich different techniques do you know about Implementing FIR/IIR
> Filters
> in Spartan-FPGA (195 CLB). Is there any program to use or VHDL-Code.
> Any Informations specially on Spartan (XILINX-FPGA) will be very
> neccessary.
> thanks for help!

Article: 36210
Subject: Re: Altera Local Routing
From: Ray Andraka <ray@andraka.com>
Date: Fri, 02 Nov 2001 12:53:41 GMT
Links: << >>  << T >>  << A >>
That interleaving is a direct fix for a shortcoming of the 10K
architecture.  The layout of the carry chain (running across the LEs in
a LAB) forces data flow to be from LAB to LAB.  In the older
architectures, this meant getting off the row route, going through a
single register in the LAB, then getting back on the row route structure
to ge to the next register in the design.  For data flow designs, this
makes very inefficient use of the 'global' nature of the routing
resource.  Since there are only 6 row routes for every 8 LE's in a row,
it also led to unneccessary congestion of the row routing resources.
The LAB to LAB direct connect fixes that, permitting faster connections
between registers and avoiding the severe routing congestion in an
arithmetic design (typical of DSP applications).

This added routing makes the Altera 20K (Apex) and Mercury devices much
more usable for DSP applications.  There is still an issue with the
number of inputs when the carry chain is used, which limits you to a 2
input arithmetic function.  The 20K also makes it possible to clear or
load a register without stealing a LUT input, so you can at least do an
accumulator with a load or clear input in one level of logic.

digari wrote:

> Why there is interleaved routing from an LE to adjecent LLIs in
> Mercury and ApexII architectures.
>
> "APEX II devices use an interleaved LAB structure, so that each LAB
> can
> drive two local interconnect areas. Every other LE drives to either
> the left
> or right local interconnect area, alternating by LE."
>
> Can anyone shed some light on the alternate routing structure of LEs
> within a LAB.

--
--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: 36211
Subject: Re: Registered as well as unregistered outputs?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 02 Nov 2001 12:54:57 GMT
Links: << >>  << T >>  << A >>
Depends entirely on your design style.  For highest performance, you'll
generally want to avoid using the unregistered output, but that also
limits your design options.

nitin wrote:

> Hi...
>
> Can anyone tell me how frequently and where both registered and
> unregistered outputs from an LE are required...?
>
> Ciao,
> nitin.

--
--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: 36212
Subject: Re: Altera Local Routing
From: "Steve Fair" <sfair6@home.com>
Date: Fri, 02 Nov 2001 12:55:46 GMT
Links: << >>  << T >>  << A >>
Digari -

It's all about speed . . .

The interleaving of the labs gives the router more flexibility.  Each lab
has it's own local routes, which is the fastest non-dedicated route (as
opposed to carry or cascade chains).  If all the logic between two flops can
fit into a lab, you will achieve the best performance possible.  If the
logic can't fit into the lab, you go to a megalab route in the apex II
architecture, which adds delay AND uses another routing resource.  By
interleaving the labs, an LE can be connected to many more LE's for making
those fast, local connections.  The area expense isn't that great (a single
line and mux to the next lab's local interconnect), so it's a very efficient
way to increase routing and performance.  Put another way, a lab goes from
having 9 possible local connections to 19 with very little overhead.  With
the further interleaving available (remember the left & right drives), you
can do some pretty deep equations with very small routing delays.

Hope that helps.

Steve

"digari" <digari@dacafe.com> wrote in message
news:e0855517.0111010034.375d9328@posting.google.com...
> Why there is interleaved routing from an LE to adjecent LLIs in
> Mercury and ApexII architectures.
>
> "APEX II devices use an interleaved LAB structure, so that each LAB
> can
> drive two local interconnect areas. Every other LE drives to either
> the left
> or right local interconnect area, alternating by LE."
>
> Can anyone shed some light on the alternate routing structure of LEs
> within a LAB.



Article: 36213
Subject: Re: XC6000
From: Ray Andraka <ray@andraka.com>
Date: Fri, 02 Nov 2001 13:03:06 GMT
Links: << >>  << T >>  << A >>
Depends on the design Peter,  I've seen some pretty horrendous stuff out there.
However, if the static timing analysis is being met, then the problem is not with
excessive delay.  Given the scarce information here, it is hard to tell what the
problem might be.  Could be at static frequencies, the design is just barely
sliding by, but when you operate it at higher frequencies the slightly elevated
chip temperature pushes something over the edge.  Could also be a signals
integrity issue, although I kind of doubt that.  The HOTWORKs boards are put
together pretty well.  Also, check the timing of your bidirectional bus.

As a first guess, I suspect your write pulse edge is too close to one end of the
memory write cycle, probably the address.  A safe design should leave a window of
stable address on either side of the write pulse.  That can be a challenge to
achieve without a clock running faster than the memory access.


Peter Alfke wrote:

> If you have an error at such a low frequency, ( anything below 20 MHz ),
> lowering the frequency even more will never cure the problem, since excessive
> delay is not the cause.
> (Almost fits on a fortune cookie...)
>
> Peter Alfke
> ==========================
> Pedro Alexandre wrote:
>
> > Hello
> >
> > Does anyone remember the HOT Works board with the xc6216 (and 2MB SRAM)?
> > I'm working on that board and I'm implementing a circuit that reads some
> > portions of memory, acumulate its contents and writes the result to SRAM.
> > I'm experiencing some problems accessing the on-board SRAM. With a 32 bit
> > access from the XC6000, some significant bits are wrong. It may be a problem
> > with the frequency because the circuit worked fine with a step by step user
> > clock. I've tried to lower the frequency to its minimum value (1MHz/2) by
> > software (JAVA), and the problem is still there. Does anyone had the same
> > problem? An internal freq. divider would solve the problem?
> >
> > thanks,
> > pedro
> >
> > --
> > ___________________________________
> >                     _.._
> >                   .' .-'`
> >                  /  /
> >                  |  |
> >                  \  \
> >                   '._'-._
> >                      ```
> >                         ,     ,
> >                         |\---/|
> >                        /  , , |
> >                   __.-'|  / \ /
> >          __ ___.-'        ._O|
> >       .-'  '        :      _/
> >      / ,    .        .     |
> >     :  ;    :        :   _/
> >     |  |   .'     __:   /
> >     |  :   /'----'| \  |
> >     \  |\  |      | /| |
> >      '.'| /       || \ |
> >      | /|.'       '.l \\_
> >      || ||             '-'
> >      '-''-'

--
--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: 36214
Subject: Re: Implementing Filter
From: "Ken" <aeu96186@yahoo.co.uk>
Date: Fri, 2 Nov 2001 13:12:20 -0000
Links: << >>  << T >>  << A >>

How does it perform in terms of area efficiency compared to Xilinx CORE
Generator?

Ken

<vt313@comsys.ntu-kpi.kiev.ua> wrote in message
news:3BE27D9D.D8CCFED5@comsys.ntu-kpi.kiev.ua...
> The Aldec Active HDL 4.2. has a core generator which
> generates VHDL file for any FIR filter for XILINX FPGA.
>
> fre wrote:
> >
> > Holla
> > Wich different techniques do you know about Implementing FIR/IIR
> > Filters
> > in Spartan-FPGA (195 CLB). Is there any program to use or VHDL-Code.
> > Any Informations specially on Spartan (XILINX-FPGA) will be very
> > neccessary.
> > thanks for help!



Article: 36215
Subject: Re: Cloning someone else's IP core
From: Kolja Sulimma <kolja@sulimma.de>
Date: Fri, 02 Nov 2001 15:04:11 +0100
Links: << >>  << T >>  << A >>
>
> > I found that most constraints violations were false paths.
> > For a PCI slave only TRDY and the output enable generation is a real problem.
>
>         Yes, in my design too, TRDY# is a problem, but the worst TRDY#
> path isn't any slower than the worst AD[31:0] path right now.

In my case all the AD[31:0] setup time violations were related to parity generation.
But as I do not perform parity checking, the setup time violations can be ignored.

This still leave the clock to out violations. Not for the parity logic, but for some other parts of the
interface.

Kolja Sulimma


Article: 36216
Subject: Re: Field Programmable Logic in energy poor environments
From: Kolja Sulimma <kolja@sulimma.de>
Date: Fri, 02 Nov 2001 15:17:13 +0100
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> Kolja Sulimma wrote:
>
> > <snip>. You do not need fast transistors in your configuration memory.
>
> True, except in the LUT-RAM, where speed matters

OK. That's less than 5% in case of a XC2S200.

> > As you are using an SOI technology for Virtex-II
>
> Xilinx does *NOT* use SOI in any of its products

Sorry. My fault. I though I read this somewhere.

> > you could easily use a
> > higher
> > threshold voltage for your configuration SRAM transistors as for your CLB
> > logic transistors. (Hmmm. You probably do allready.)
>
> If we (and our customers) were willing to accept higher cost, or lower
> performance, or a more restricted applications area ( market niche), or all
> three together, we could do various things to reduce power. But that is not a
> realistic assumption.

You could also see it the other way round:
By using dynamix multi threshold technologies you can  have a configuration bit per
CLB to use a threshold voltage for your critical path that would be unacceptable low
for your whole chip but significantly speeds up the circuit.

Kolja Sulimma


Article: 36217
Subject: Re: High level synthesis will never work well :)
From: Iwo.mergler@soton.sc.philips.com
Date: Fri, 02 Nov 2001 15:02:23 +0000
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> Falk Brunner wrote:
> 
> > I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP.
> 
> Aw, c'mon.  You're talking about what happens when you use Visual C++ to
> write a WINDOWS version of "Hello, World."
> 
> Write a short hello.cpp for your linux box, that runs on the command
> line, and tell me how big it is.

Here we go...

	#include <iostream.h>

	int main(void)
	{
		cout << "Hello World.\n";
	}

c++ -o hello++ hello.cpp; strip hello++

-rwxr-xr-x    1 mergler  users        3516 Nov  2 14:59 hello++

 < 3.5 KB


	#include <stdio.h>

	int main(void)
	{
		printf("Hello World.\n");
	}

gcc -o hello hello.c; strip hello

-rwxr-xr-x    1 mergler  users        3016 Nov  2 15:00 hello

< 3 KB

Iwo

Article: 36218
Subject: Re: Implementing Filter
From: "Matthias" <scheerer@uni-mannheim.de>
Date: Fri, 2 Nov 2001 16:13:35 +0100
Links: << >>  << T >>  << A >>
Hi,

how about the "XILINX Application Notes" at
http://support.xilinx.com/support/searchtd.htm ?

Matthias

"fre" <emi.fre@caramail.com> schrieb im Newsbeitrag
news:e25942b.0110310732.1b8c8b59@posting.google.com...
> Holla
> Wich different techniques do you know about Implementing FIR/IIR
> Filters
> in Spartan-FPGA (195 CLB). Is there any program to use or VHDL-Code.
> Any Informations specially on Spartan (XILINX-FPGA) will be very
> neccessary.
> thanks for help!



Article: 36219
Subject: Re: High level synthesis will never work well :)
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 02 Nov 2001 17:06:47 +0100
Links: << >>  << T >>  << A >>
Iwo.mergler@soton.sc.philips.com writes:

> Andy Peters wrote:
> > 
> > Falk Brunner wrote:
> > 
> > > I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP.
> > 
> > Aw, c'mon.  You're talking about what happens when you use Visual C++ to
> > write a WINDOWS version of "Hello, World."
> > 
> > Write a short hello.cpp for your linux box, that runs on the command
> > line, and tell me how big it is.
> 
> Here we go...
> 
> 	#include <iostream.h>
> 
> 	int main(void)
> 	{
> 		cout << "Hello World.\n";
> 	}
> 
> c++ -o hello++ hello.cpp; strip hello++
> 
> -rwxr-xr-x    1 mergler  users        3516 Nov  2 14:59 hello++
> 
>  < 3.5 KB
> 
> 
> 	#include <stdio.h>
> 
> 	int main(void)
> 	{
> 		printf("Hello World.\n");
> 	}
> 
> gcc -o hello hello.c; strip hello
> 
> -rwxr-xr-x    1 mergler  users        3016 Nov  2 15:00 hello
> 
> < 3 KB

You're cheating. If you do a "file hello" you will see that it's
dynamically linked. Most of the code resides in libraries which are
linked in at run time. Try to add a -static to your compile command
line and check the size of the executable then...

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 36220
Subject: Re: Synplicity, Xilinx, & unwanted BUFGs
From: husby_d@yahoo.com (Don Husby)
Date: 2 Nov 2001 08:13:39 -0800
Links: << >>  << T >>  << A >>
Alan Nishioka <alann@accom.com> wrote in message news:<3BE19F86.FB23D80F@accom.com>...
> "Jason T. Wright" wrote:
> 
> > How does one prohibit Synplify from inferring a global buffer?
> 
> In synplify, using verilog, the directive to not use a global buffer is:
> /* synthesis syn_noclockbuf=1 */

But:  you have to attach it to the module.  It doesn't always work
if you attach it to the signal name.

module(  etc  ) /* synthesis syn_noclockbuf=1 */;

Probably the same is true for VHDL- attach it to the entity or
architecture.

Article: 36221
Subject: Re: Cheap programming of XC2018?
From: edick@hotmail.com (Richard Erlacher)
Date: Fri, 02 Nov 2001 16:56:30 GMT
Links: << >>  << T >>  << A >>
If you can find a copy of the old (published by MMI) version of XACT,
you can bypass the need for a dongle in about an hour of fiddling with
Turbo Debugger, if you're clever and patient.  Once you've found the
branch that it takes when it's happy with the dongle, you simply patch
it using Norton's NU.EXE.

Finding the old software is more difficult than patching it.

Dick


On Thu, 25 Oct 2001 20:21:04 GMT, Ray Andraka <ray@andraka.com> wrote:

>I know of no source for the old sw.  You might find someone with a used copy,
>but you'll have to make sure you get the dongle, and a valid license file.
>I'm pretty sure the license files from back then did not expire, but you
>might check to make sure.  I'm not sure what use these parts would be now:
>They are feature poor compared with new devices, consume considerably more
>power, are orphaned from both tools ans support points of view, and will
>likely not teach you much as far as using modern FPGAs go.  It may cost you
>less to pick up an eval board with a current device on it, when you consider
>the time and effort of finding and then getting tools to run for these old
>parts.  It is also worth noting that the software for the 2000 series is DOS
>based.  IIRC, the 2000 series was dropped from the tools about the same time
>the windows (3.1) version of XACT came out.  XACT did not work very well
>under win95.  You will probably have to resurrect an old operating system,
>and perhaps even an old machine (I suspect the new machines may be too fast
>to work the dongle properly, that was a problem with some faster machines
>back then) jsut to get the software up an running.  Sounds like an awful lot
>of effort for a very questionable return to me.
>
>Peter Heitzer wrote:
>
>> Hello folks,
>> I have a few Xilinx XC2018 chips (5V version) and wonder if there was
>> a cheap way of programming those chips.
>> I know that the XC2000 series is now obsolete an no newer software
>> supports it. But perhaps there is some old software for free download
>> in the net.
>>
>> Thanks in advance,
>> Peter
>>
>> --
>> Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857
>> mail Peter.Heitzer@rz.uni-regensburg.de
>
>--
>--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: 36222
Subject: Re: GAL compiler
From: edick@hotmail.com (Richard Erlacher)
Date: Fri, 02 Nov 2001 16:57:51 GMT
Links: << >>  << T >>  << A >>
Lattice gives away their Design Expert software for Windows.  It will
do the job, and WAY more, and therefore may solve more difficult
problems later on.

Dick

On Thu, 25 Oct 2001 22:01:27 +0200, Bertram Geiger <bgeiger@aon.at>
wrote:

>
>> could anybody say me where to find a simple free GAL (especially 16V8)
>> compiler for MS-DOS?
>> 
>search for "easyAbel", might be its still somewhere around on the web or
>ask on the university
>Its simple and works fine up to 22v10
>
>Greetings,  Bertram
>-- 
>Bertram Geiger,  bgeiger@aon.at
>HTL Bulme Graz-Goesting - AUSTRIA


Article: 36223
Subject: Open configuration bitstreams
From: Patrick Maheral <pmaheral@AAI.ca>
Date: Fri, 02 Nov 2001 12:50:41 -0500
Links: << >>  << T >>  << A >>
Greetings,

I am searching for a SRAM based FPGA or similar device (must have
unlimited
reprogram cycles) that has a well documented configuration bitstream.  I

have used general search engines (eg. Google) and dug through
manufacturer's
websites (eg. Xilinx, Altera, Atmel, etc.), but couldn't find
documentation
that related the resources to the actual bits.

I have worked with the Xilinx 6200 series (now discontinued and in
extremely
short supply) which had complete, open documentation of the bitsteam.
Does
anyone know of another FPGA  with available (preferably open, ie. no NDA

required) configuration bitstream documentation.

Any pointer would be appreciated.

Thanks,

Patrick Maheral



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 36224
Subject: Re: Open configuration bitstreams
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 2 Nov 2001 17:58:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3BE2DCF1.3E7E12D3@AAI.ca>,
Patrick Maheral  <pmaheral@AAI.ca> wrote:

>Does anyone know of another FPGA with available (preferably open,
>ie. no NDA required) configuration bitstream documentation.

>Any pointer would be appreciated.

Xilinx Virtex:

Jbits provides an API to directly edit the configuration bitfiles.

Appnote, "Virtex Series Configuration Architecture User's Guide"
http://www.xilinx.com/xapp/xapp151.pdf

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



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