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 35650

Article: 35650
Subject: Re: PWM Signal in VHDL ?
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Fri, 12 Oct 2001 15:44:19 +0100
Links: << >>  << T >>  << A >>
In article <3BC6EA86.82FC088B@andraka.com>, Ray Andraka
<ray@andraka.com> writes
>A comparator is relatively slow, and uses nearly as many LUTs as a
>counter.  For FPGAs, a better solution is to use two counters: a frame
>counter to set the period (constant) and a second duty cycle counter.  The
>TC on the frame counter loads the duty cycle counter and sets an RS
>flip-flop.  The TC on the duty cycle counter (a downcounter) resets the RS
>flip-flop.  The TC is the carry out on both counters, so uses no additional
>logic.  If both counters are downcounters, you can program the period as
>well as the duty cycle.

There is another approach.  No comparator, no counter.  Needs an adder
with a carry-in and carry-out, but that's no big deal.  Its internal
register is one bit wider than the PWM demand input.  The really
interesting thing about this implementation is that it minimises the
low-frequency components in the PWM output waveform, thus making
output filtering a bit easier.

It has two other neat features that make it better than standard PWM
for many applications.  FIrst-off, the output updates immediately
when you change the demand input - you don't have to wait for a 
complete PWM cycle to elapse.  Second, you get the full range of
demand:  for a 4-bit input, 0000 would give permanently-off and
1111 would give permanently-on.

Try it in simulation, with a reasonably small (4-bit?) input...
Think Bresenham's algorithm, first-order delta-sigma, binary
rate multiplier.....

---------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity PWM is
  port (
    clk, rst: in std_logic;
    D: in std_logic_vector;
    Q: out std_logic
  );
end;

architecture distributed_pulses of PWM is

  signal acc: unsigned (D'LENGTH downto 0); -- one bit bigger than D

begin

  Q <= acc(D'LENGTH);   -- the carry bit provides PWM output

  process (clk, rst)
  begin
    if rst = '1' then
      acc <= (others => '0');
    elsif rising_edge(clk) then
      acc <= ('0' & acc(D'LENGTH-1 downto 0))  -- all but the carry
             + unsigned(D)                     -- input demand
             + acc(D'LENGTH downto D'LENGTH);  -- the carry bit
    end if;
  end process;

end;
---------------------------------------------------------

-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 35651
Subject: Re: High level synthesis will never work well :)
From: brimdavis@aol.com (Brian Davis)
Date: 12 Oct 2001 08:03:25 -0700
Links: << >>  << T >>  << A >>
Don Husby wrote:
> 
> You'd think a simple 56-bit counter would be no
> problem.  The code below should synthesize to
> 1 logic level using 56 LUTs, 56 FFs and a carry chain.
> Instead, Synplicity adds an extra 57 LUTs and an extra
> level of logic.
>

 What Synplify version/ FPGA / target frequency are you using?

   I've seen results like this before, where Synplify seems to
 "try too hard" to hit a speed target, replacing a simpler 
 implementation with a more complex one as you pass a certain
 frequency constraint, particularly when long carry chains are
 involved.

 Taking your counter code:

   `define CNT_MSB 55

   module Cnt56(K, CE, R, Out);
     input         K, CE, R;
     output [`CNT_MSB:0] Out;
     reg    [`CNT_MSB:0] Q;

     assign Out= Q;

     always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;

   endmodule


 And tweaking counter size/target frequency, gives:

               Synplify      Synplify
   CNT_MSB     Frequency     LUT count
  __________________________________________
     55          77           57
     55          78          110

     31          95           33
     31          96           46
     31         122           46
     31         123           83

 when using Synplify 6.2.4 & XCV600E-6.
 
   Below a certain target frequency, it does hit about 1-LUT per
 bit, albeit without using the sync. reset.

   You could probably fake Synplify out by putting a dummy
 frequency or multicycle constraint on the counter, then nuke 
 it from the .ncf file before running the back-end tools.


Brian

Article: 35652
Subject: Reassemble a BGA560 device
From: Juergen Otterbach <juergen.otterbach@t-online.de>
Date: Fri, 12 Oct 2001 21:05:13 +0200
Links: << >>  << T >>  << A >>
Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------93029E34D87DBD6AD60FC94C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hallo usergroup,
in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
device.
For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
(means to take of the 1000E and resolder the 2000E).

Has anybody experience on that? Is it possible and what company inside
Germany can do that job?
It is clear to us that this is a risk.

Thanks in advance.
Juergen Otterbach

--------------93029E34D87DBD6AD60FC94C
Content-Type: text/x-vcard; charset=us-ascii;
 name="juergen.otterbach.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Juergen Otterbach
Content-Disposition: attachment;
 filename="juergen.otterbach.vcf"

begin:vcard 
n:;Juergen Otterbach
x-mozilla-html:FALSE
version:2.1
email;internet:juergen.otterbach@t-online.de
x-mozilla-cpt:;65535
fn:Juergen Otterbach
end:vcard

--------------93029E34D87DBD6AD60FC94C--


Article: 35653
Subject: Re: High level synthesis will never work well :)
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 12 Oct 2001 21:13:46 +0200
Links: << >>  << T >>  << A >>
Andrew Brown schrieb:
> 
> You can't be seriously saying "Hello World" is an appropriate use of C++

No.

> But VHDL is a very structured language which should make larger designs

Yes.

> easier. (lets not start he VHDL/verilog war here).

;-)

-- 
MFG
Falk


Article: 35654
Subject: Re: High level synthesis will never work well :)
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Fri, 12 Oct 2001 21:23:48 +0200
Links: << >>  << T >>  << A >>
Well, the companies seem to focus on patents.
The list of patents shown on the Altera MaxPlus2 splash screen
is rather long. Assuming a lousy patent lawyer costs 3 times more
than a decent engineer, it is obvious that there a few reources
left 
to write a useable tool.
Then on the other hand the market for those kind of software is
not 
that big. 

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com

Don Husby wrote:
> 
>
> 
> Which brings me to my point:
>   High level, abstract synthesis will never work well.  I realize
> this is an extreme statement, but if today's synthesizers can't
> do better than a factor of 2 for really simple code, it's
> hard to imagine a synthesizer in the near future that can
> compile complex code efficiently.

Article: 35655
Subject: Re: future Xilinx products wish list ...
From: z80@ds2.com (Peter)
Date: Fri, 12 Oct 2001 20:24:13 +0100
Links: << >>  << T >>  << A >>

The one wish I had regarding these parts was the CLK input to have a
schmitt trigger on it.

I have designed several complicated waveform generators, each
containing 32 or 64 FPGAs (XC3k and XC4k devices). I had enormous
problems distributing the config clock around these boards, which were
IBM PC full-size with devices both sides. Loads of decoupling, 6
layers (incl. VCC and GND planes), very careful tracking, you name it.

The config clock input is extremely sensitive to risetime. Too slow,
it won't work, too fast and it cannot be distributed to many devices.
I vaguely recall that it has to be faster than 20ns, and driving it
from a 74HC output was too slow.


Article: 35656
Subject: Re: Reassemble a BGA560 device
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Fri, 12 Oct 2001 21:27:30 +0200
Links: << >>  << T >>  << A >>
BGAs are soldered in vapor phase at 220++ degrees.
You're expecting a robot in there to lift your component off ?
Hard to imagine.
However unsoldering everything should be simple - insert it 
upside down and let gravity work for you.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com




Juergen Otterbach wrote:
> 
> Hallo usergroup,
> in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
> device.
> For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
> (means to take of the 1000E and resolder the 2000E).
> 
> Has anybody experience on that? Is it possible and what company inside
> Germany can do that job?
> It is clear to us that this is a risk.
> 
> Thanks in advance.
> Juergen Otterbach

Article: 35657
Subject: Re: Reassemble a BGA560 device
From: "Ben" <seabybs@hotmail.com>
Date: Fri, 12 Oct 2001 21:06:21 +0100
Links: << >>  << T >>  << A >>
Forget it unless you've got all the necessary kit (robotics etc). BGA's are
a nightmare to remove, and even worse to replace - very unreliable. Not too
sure if there are many companies willing/able to do this kind of work, but
if there are it won't be cheap.
Would it not be better to get some kind of adapter board made up?

"Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message
news:3BC74422.710CB0E6@dplanet.ch...
> BGAs are soldered in vapor phase at 220++ degrees.
> You're expecting a robot in there to lift your component off ?
> Hard to imagine.
> However unsoldering everything should be simple - insert it
> upside down and let gravity work for you.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
>
>
>
>
> Juergen Otterbach wrote:
> >
> > Hallo usergroup,
> > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
> > device.
> > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
> > (means to take of the 1000E and resolder the 2000E).
> >
> > Has anybody experience on that? Is it possible and what company inside
> > Germany can do that job?
> > It is clear to us that this is a risk.
> >
> > Thanks in advance.
> > Juergen Otterbach



Article: 35658
Subject: Re: future Xilinx products wish list ...
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 12 Oct 2001 16:20:08 -0400
Links: << >>  << T >>  << A >>
I would think that a built-in crystal oscillator port would be a great
option.  Also, I personally would like to see real LVPECL (i.e.suitable
for single ended LVPECL inputs) with real LVPECL levels.  Also packages
with pins (SMT pins are OK but not those ball grid arrays) for those who
are using FPGA's as a short production run (read PROTOTYPE) device.

Theron Hicks


Article: 35659
Subject: Re: High level synthesis will never work well :)
From: husby_d@yahoo.com (Don Husby)
Date: 12 Oct 2001 13:29:55 -0700
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3BC6E69A.23A907BF@andraka.com>...
> Right.  Did you also have an explicit global reset?

No.  I've given up trying to use GSR, except for post-PAR
simulations.

Although GSR is a completely different issue, it seems
to me that it would almost be trivial to implement it
using the syntax for variable initialization.  VHDL allows
a signal (register) to be initialized when declared.  Verilog
has the "initial" construct.  It should be fairly easy to
infer GSR from these, and it would make simulation agree
with synthesis.

Article: 35660
Subject: Re: Lattice discontinues all smaller MACH circuits and other devices
From: Gerald Coe <gerry@devantech.demon.co.uk>
Date: Fri, 12 Oct 2001 21:32:28 +0100
Links: << >>  << T >>  << A >>
Hello 

This is a concern to me,
Can you provide an on-line reference to this document?

Regards,
Gerry.

In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt
<martp@hotmail.com> writes
>Hello,
>as I read in comp.arch.embedded most i186 and i486 derivates build by
>AMI are discontinued.
>Now we got an announcement that this is the case also for a great
>bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is
>intended to be closed).
>The list of devices in the PDF document spans 8 pages and contains
>PALCE  PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx
>devices!
>
>Last order is 31 dec 2001 and last delivery 31 dec 2002!!!!
>
>I have posted this using another mail server a day ago, but I havent
>seen it up to now.
>I apologize if this message is reaching you twice.
>
>Perhaps we are the only ones around using this old-fashioned
>programmable devices....
>
>
>BTW: On http://www.latticesemi.com/products/mature/index.cfm 
>you cannot read  **anything** about this up to now (12 oct 2001, 11:20
>UT)

-- 
Regards, Gerry
www.robot-electronics.co.uk

Article: 35661
Subject: Re: Small FPGA proto boards
From: johnjakson@earthlink.net (John Jakson)
Date: 12 Oct 2001 13:59:29 -0700
Links: << >>  << T >>  << A >>
Arthur Sharp wrote
>I'm after a small (credit card size or not a lot larger) FPGA
prototype

Ray Andraka <ray@andraka.com> wrote in message news:<3BC6EADF.19E7A24C@andraka.com>...
>> Annapolis Micro has one too(PCMCIA).  Hold onto your wallet though.

What form factor are you looking for exactly?, the Nallatech PCI
boards can carry Dime modules that you can design for.

Insite also has some low cost PCI/Dime compatible boards but PCI
license is an issue. I think they have a $350 board (-PCI core), with
PCI core in the Spartan2 200.

I saw Annapolis Micro at Embedded Show in Boston, they reminded me
that though the idea of compact card form is neat, the PCMCIA Laptop
standard simply can not provide the juice needed to do anything really
cool. The card is normally a virtex 300 I think it is available for
$1k but you can't fill it with high speed logic & get enough juice
from the socket. Although much bigger parts could replace the 300,
still not enough juice. Any PCMCIA design would have to be slow.

Also there was and maybe are DIMM type cards around but not available.
Nuron was doing these but seems to have disappered (and was extremely
expensive anyway). Also I think PSU (Penn State I think) has a
project, it was posted here 2 months or so ago (Aug 16) but they told
me no commercial plans. I would think DIMM modules would also have the
same power issues as PCMCIA.

Looks like most of the smaller boards (XESS etc) are for tiny Spartans
etc.

There are also PC104 boards (APS I think) that have virtex 800 

Just some ideas

John Jakson

Article: 35662
Subject: Re: Timing constraints for unrelated clocks?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 12 Oct 2001 14:01:16 -0700
Links: << >>  << T >>  << A >>
Consider adding a two flop Clk2 synchronizer
on the output of your Reg1.
Then you can just check static timing
on Clk2 and ignore Clk1.

 --Mike Treseler

Article: 35663
Subject: Re: High level synthesis will never work well :)
From: Ken McElvain <ken@synplicity.com>
Date: Fri, 12 Oct 2001 14:29:14 -0700
Links: << >>  << T >>  << A >>
We are here...

We do appreciate getting small examples that demonstrate potential
improvements.  In general there is no need to go to the effort
to produce the structural form.  All we need is a short description
of what we missed - "You should have used the synch reset instead of
building it in logic in front of the flip-flop".

We have a large queue of improvements sorted by a function of how
common they are, how much gain we are likely to get and how hard they
are to implement.  This doesn't mean that you shouldn't bother to tell 
us about your desired improvement.  Even if we already have it in our
queue, you are bumping our notion of how common the problem is.

The best way to send us such a test case is via email at

support@synplicity.com

Please put both "QOR" and the target FPGA in the subject to
help us route it.  The FPGA synthesis development team is pretty large.

Thanks,
Ken McElvain, CTO


Andrew Brown wrote:

> I think synplify and all other vendors should have a simple process for
> improving synthesis aldorithms.  If we can provide them with source - the
> output from their tool and a 'structural' source which is a 'better'
> implementation, they should ensure future versions of their tool can
> optomise the design.  Granted this is complicated by design requirements
> such as GSR and other resets in this case - but if we supply simplified
> example code they should beable to improve their engine.  To be fair to
> them - it's damn hard to imagine situations your engine isn't good at off
> the top of your head so you can improve it.
> 
> Anyone from synplify out there???
> 
> A.
> 
> 
> 


Article: 35664
Subject: Re: Reassemble a BGA560 device
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 12 Oct 2001 14:31:30 -0700
Links: << >>  << T >>  << A >>
Juergen Otterbach wrote:
> 
> Hallo usergroup,
> in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
> device.
> For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
> (means to take of the 1000E and resolder the 2000E).

Removing and replacing a BGA device is not
a problem for any manufacturing facility
with a BGA rework station. 

Of course, you have to throw the old part away.

Without the proper equipment and skills
however, you may well destroy the board.



      --Mike Treseler

Article: 35665
Subject: Re: future Xilinx products wish list ...
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Fri, 12 Oct 2001 14:38:41 -0700
Links: << >>  << T >>  << A >>
Yes to all of those - I would love to see the Virtex programmable termination
feature (I forget the marketing name) enhanced to support - WITHOUT
external resistive dividers - LVDS and PECL I/O, and to support programmable
DIFFERENTIAL termination as well. Well, I can wish, can't I?

For prototypes, and for some types of production, I would be content with being
able to buy BGAs from Xilinx or via distros pre-soldered to BGA-socket/adapter
thingies such as http://www.mill-max.com/products/bga/bga.htm rather than having
to deal with getting this done myself. This would be an optional service that
could simplify things for a lot of people, I think.

To solve the slow global reset problem, how about circuitry on each clock buffer that
could disable it during reset, then synchronously re-enable it N clocks after
end of reset, where N is programmable (0 for no delay), up to some reasonable maximum
sufficient to accomodate the reset recovery time and max clock rate. Or some simpler
scheme that would accomplish the same thing.

Theron Hicks wrote:
> 
> I would think that a built-in crystal oscillator port would be a great
> option.  Also, I personally would like to see real LVPECL (i.e.suitable
> for single ended LVPECL inputs) with real LVPECL levels.  Also packages
> with pins (SMT pins are OK but not those ball grid arrays) for those who
> are using FPGA's as a short production run (read PROTOTYPE) device.
> 
> Theron Hicks

-- 
Tom Burgess
Digital Engineer
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Article: 35666
Subject: how do I avoid glitches in this design?
From: "Johan Ditmar" <johan.ditmar@nospamceloxica.com>
Date: Fri, 12 Oct 2001 23:33:07 +0100
Links: << >>  << T >>  << A >>
Hello there,

The past few days I have been trying to come up with a way to describe a
generic pulse generator in Verilog (or VHDL) using shift registers. What I
would like it to do is to take an arbitrary pulsetrain as a parameter (for
example "100110") and then generate this pulse train repeatedly from an
incoming clock signal. However, each bit in the pulse train corresponds to
half an incoming clockcycle! I came up with the following scheme to do this:

I implement two rotating shift registers (A and B) of three bits wide, one
that is sensitive to the positive clock edge and one on the negative. I
initialise one with the even bits of the pulse train ("101") and one with
the odd ("010") and I let them run on the incoming clock.

Then I generate a signal from the incoming clock, which simply follows this
clock (using two flip flops, one positive and one negative edge sensitive),
and I use this signal to either choose the output of shift register A or
shift register B and this is then the output of the whole circuit.

However, the output of this circuit is going to be used as a clock which
feeds other circuits, so it should be glitch free. This is not always the
case in my present design (I think). Is there some way to make my design
glitch free? As the output changes on both positive and negative clock edge,
I can´t put a simple register on the output :-( And I prefer not to use
PLL´s or DLL´s (which may be used to generate the double clock frequency to
make everything sensitive to the positive clock edge only).

Any help is greatly appreciated!

Regards,

Johan Ditmar




Article: 35667
Subject: Re: Lattice discontinues all smaller MACH circuits and other devices
From: rstevew@deeptht.armory.com (Richard Steven Walz)
Date: 12 Oct 2001 22:43:24 GMT
Links: << >>  << T >>  << A >>
In article <99e2931.0110120320.49cf9aba@posting.google.com>,
M. Praekelt <martp@hotmail.com> wrote:
>Hello,
>as I read in comp.arch.embedded most i186 and i486 derivates build by
>AMI are discontinued.
>Now we got an announcement that this is the case also for a great
>bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is
>intended to be closed).
>The list of devices in the PDF document spans 8 pages and contains
>PALCE  PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx
>devices!
>
>Last order is 31 dec 2001 and last delivery 31 dec 2002!!!!
>
>I have posted this using another mail server a day ago, but I havent
>seen it up to now.
>I apologize if this message is reaching you twice.
>
>Perhaps we are the only ones around using this old-fashioned
>programmable devices....
>
>
>BTW: On http://www.latticesemi.com/products/mature/index.cfm 
>you cannot read  **anything** about this up to now (12 oct 2001, 11:20
>UT)
-----------------------------------
Read the URL you posted:
--
Lattice says:
"The product families on this page have been classified as
"Mature" as they have been superceded by product
families which utilize our more advanced process
technologies required to meet the design needs of
today's system logic designers.

Unless a Mature Family has been formally upgraded via
our Product Change Notification procedure (highlighted
with an *), Lattice will continue to support all existing
business for these Mature products.

There are no near-term plans to obsolete any of these Mature product families.
Designers working on new designs are strongly encouraged to evaluate the
alternative product families listed in the "Use for New Designs" column."
--
-Steve
-- 
-Steve Walz  rstevew@armory.com   ftp://ftp.armory.com/pub/user/rstevew
-Electronics Site!! 1000 Files/50 Dirs!! http://www.armory.com/~rstevew
Europe Naples, Italy: ftp://ftp.unina.it/pub/electronics/ftp.armory.com


Article: 35668
Subject: Re: Reassemble a BGA560 device
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Sat, 13 Oct 2001 01:46:20 +0100
Links: << >>  << T >>  << A >>

"Mike Treseler" <mike.treseler@flukenetworks.com> wrote
> Juergen Otterbach wrote:
> >
> > Hallo usergroup,
> > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
> > device.
> > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
> > (means to take of the 1000E and resolder the 2000E).
>
> Removing and replacing a BGA device is not
> a problem for any manufacturing facility
> with a BGA rework station.
>
> Of course, you have to throw the old part away.

AFAIK you can 're-ball' the old part.  Though this may not be worth
the trouble - how much are 1000Es these days?






Article: 35669
Subject: Re: future Xilinx products wish list ...
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Sat, 13 Oct 2001 02:02:45 +0100
Links: << >>  << T >>  << A >>
Another point of view...

I disagree on the dual-use of pins.  Please put ALL the config, etc,
pins on the VCCAUX supply. I.E. on non-banked balls.  I guess we could
also have an option to connect some of these to the logic matrix.  The
V2 lineup is so much better than the 4K/Virtex arrangements, but it is
still annoying to have config spread between VCCAUX and whatever
voltages banks 4 and 5 are set at.

Maybe the long term plan is to configure/readback the big stuff
via JTAG only - the details of ROM handling can be farmed out to a
PAL.


"Eric" <erv_NO_SPAM@sympatico.ca> wrote in message
news:3BC1CA87.BD87F36E@sympatico.ca...
> Hi,
>
> Talking about pins that could be used for user IO after configuration, there
is :
>
> - M0 M1 M2 : According to the data sheet (Spartan II, page 13), the state
> of these pins is only required to be valid on the Low to High transition of
INIT
> (not very clear, would seem more logical if they had a setup time).
> No matter the exact timing, they obviously are only required at a precise
point
> during configuration and are useless except at that time.
> After configuration, I see no reason why they could not be used as IO.
>
> - HSWAP_EN (Virtex II)
> Same as M0 .. M2
>
> - CCLK : Obviously, it have no function after configuration is complete, and
in most
> apps, I end up connecting it to another IO pin (when configuration is bit
banged by a
> processor, CCLK is usually connected to some kind of address decoding, and it
is
> used after configuration as a "Chip Select" input).
> Here too, I can't see any reason for not using it as an IO
>
> - TDI TDO TMS TCK
> In previous series (at least Spartan), these could be used as IO if the
boundary scan
> function was not required. I miss these 4 pins (even if I screwed up once with
them
> and could not properly configure the chip because of random data being fed to
them).
> With proper care, they are great as IO too.
>
> - DONE.
> Here too, as Rob Finch said, I can't see why it's not a user IO after
configuration.
>
> - PROGRAM.
>
> Obviously, this pin can't be used as an input, but it could be used as an Open
drain output.
> Hiz : Well, does nothing ...
> Low : If properly latched / delayed /cleared, can be used to trigger self
reconfiguration.
> This self reset can be used to restart without using external logic when a
faulty condition
> is detected (or whenever the designer want to reboot the device).
>
> ------
>
> Also, as Geoffrey G. Rochat stated, I miss both HDC and LDC pins too.
>
> Another pin that might be very useful (if Master Parallel mode goes back)
would be a "TDC"
> pin that would toggle during configuration.
> Here's how it would work :
> Initially, it would be a high impedance (or high level) pin, but if the
configuration fail,
> it would go to "0" and start toggling each time the configuration fails.
>
> The use would be to connect it to an address pin of the configuration ROM in
systems that
> require the FPGA to start even in case of a failed configuration download.
>
> That way, the FPGA would attempt to start from the potentially corrupted
configuration
> data, detect the bad CRC and restart from the original "fail-safe"
configuration.
>
> This fail-safe mode is needed as soon as a potentially unreliable update must
be made
> (such as remote/modem update), at the expense of a doubled configuration rom
size.
>
> In applications that don't need the functions, it's very rare not to be able
to find
> any pin in the design that can be either pulled high, or low, or toggled
during
> configuration with no adverse effect.
>
> ------
>
> These changes would help mostly with low pin count packages where these ten
user IO pins
> could certainly be put to good use, and since this is all programmable, it
would all be
> backward compatible (except HDC / LDC) for users who don't need them.
>
> Also, not loosing pins used for configuration would allow for even more
configuration options
> without loosing more user pins (and/or increasing the number of Power/GND
pairs without
> decreasing the useable pin count).
>
> Éric.
>
> ---------------------------------
>
> Rob Finch wrote:
>
> > I agree with the original poster's comments.
> >
> > Also, it would be nice if the 'done' signal were available to a user
> > programmable pin in addition to it's regular pin. (Perhaps it could be
> > tri-state isolated from the user pin after configuration). That way, it
> > could be used in address decoding for an eprom shared between configuration
> > bits and microprocessor code. Might save some external gates.
> >
> > Rob
> > http://www.birdcomputer.ca/
>



Article: 35670
Subject: Re: Block RAMs
From: R Allen <allen822@snet.net>
Date: Sat, 13 Oct 2001 01:08:13 GMT
Links: << >>  << T >>  << A >>
The 18k Block RAM matches up with the 18 x 18 multipliers... so if in
filtering algorithms (MAC) functions are more efficient if the RAM matches
the multipliers.  This, of course is only for the Virtex II product
family.  In the Virtex, Virtex E, Virtex EM and Spartan II (soon Spartan
IIe) products the Block RAM size is 4k (and there are no multipliers in
these families.  Those are my thoughts.

sma

Gautam wrote:

> Xilinx uses 18K Block RAMs in its FPGAs & Altera uses 4K Block RAMs.
> What are the advantages & disadvantages of each of them from the Users
> perspective?


Article: 35671
Subject: Re: High level synthesis will never work well :)
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Sat, 13 Oct 2001 01:17:54 GMT
Links: << >>  << T >>  << A >>
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.

-andy

Article: 35672
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Sat, 13 Oct 2001 01:26:34 GMT
Links: << >>  << T >>  << A >>
Jeff Cunningham wrote:
> 
> Austin Franklin <austin@dar87kroom.com> wrote in message
> news:ts7f3mcvi2r3e5@corp.supernews.com...
> > I know this is "controversial" but this kind of crap just really "irks"
> > me...
> 
> Indeed.
> 
> If I recall correctly, I saw something like this when installing the xilinx
> free tools - was it the XST synthesis tool; or maybe it was the free version
> of ModelSim? Though what I remember is that the prohibition was on
> "publishing" any benchmark results, as in posting to usenet; I can't see how
> emailing results to one person would even be in violation of that assinine
> license clause.

Uh oh!  The person who posted Synplify's results for that 56-bit counter
problem is in line for an ass-whooping!

-a

Article: 35673
Subject: How do you program Xilinx XC18V00?
From: Alan Nishioka <alann@accom.com>
Date: Fri, 12 Oct 2001 18:43:22 -0700
Links: << >>  << T >>  << A >>
Is there any documentation on how to program a Xilinx XC18V00
configuration prom?

I don't want to use SVF (or I would need multiple copies of the
bitstream in my code.  One to program the XC18V00 and one to program the
FPGA)

JDrive is not written with porting in mind.  (not even the comments are
portable)

I already have code to drive JTAG.  It should just be a matter of
sending the right command and then sending the data.

I have already read XAPP053.

Is the XC18V00 programming algorithm documented anywhere?

Alan Nishioka
alann@accom.com



Article: 35674
Subject: Re: Lattice discontinues all smaller MACH circuits and other devices
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 13 Oct 2001 15:27:40 +1300
Links: << >>  << T >>  << A >>
Gerald Coe wrote:
> 
> Hello
> 
> This is a concern to me,
> Can you provide an on-line reference to this document?

Lattice have just modified the links, and added these two

http://www.latticesemi.com/lit/docs/pcns/010a_01.pdf

http://www.latticesemi.com/lit/docs/appnotes/cpld/tn1007.pdf

This details the affected devices, including those that will require 
PCB redesigns.

-jg

> In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt
> <martp@hotmail.com> writes
> >Hello,
> >as I read in comp.arch.embedded most i186 and i486 derivates build by
> >AMD are discontinued.
> >Now we got an announcement that this is the case also for a great
> >bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is
> >intended to be closed).
> >The list of devices in the PDF document spans 8 pages and contains
> >PALCE  PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx
> >devices!
> >
> >Last order is 31 dec 2001 and last delivery 31 dec 2002!!!!
> >
> >I have posted this using another mail server a day ago, but I havent
> >seen it up to now.
> >I apologize if this message is reaching you twice.
> >
> >Perhaps we are the only ones around using this old-fashioned
> >programmable devices....
> >
> >
> >BTW: On http://www.latticesemi.com/products/mature/index.cfm
> >you cannot read  **anything** about this up to now (12 oct 2001, 11:20
> >UT)
> 
> --
> Regards, Gerry
> www.robot-electronics.co.uk



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