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 47425

Article: 47425
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 25 Sep 2002 07:37:42 -0700
Links: << >>  << T >>  << A >>
Jack,

Some parts come out quickly, others less so.  Most of that is driven by market forces (where are the orders coming from?).

If you want a 2V1500, you can use the 2V2000 (or 2V3000) until the 2V1500 is ready. I am sure that our sales partners would arrange something
to make it worth your while.

Part of our success is having a wide range of parts that overlap in package and IO so that customers can optimize their choice of part once
they get into production.

The announcement of the agreement with IBM, the licensing of the Mindspeed serdes, the 405PPC(tm IBM), etc. all make for good press.  The
rollout of the Virtex II Pro to the first beta customers happened roughly 12 weeks before the silicon was due to fab out.  That way folks
could start designing in the product.  The rollout of the technology makes it seem like the parts were announced, but that is linked to the
first datasheet that gets posted, not when we talk about .13u core technology (1/31/02 date on datasheet, ES parts shipped in March, 2002).

To announce a product 6 months before it gets here is just fine.  If you can deliver.  I do congratulate Altera on their delivery of Stratix,
which was on time, and maybe a little bit ahead of time for the first sample.  Good work.  Sometimes it all comes together.

Now comes the hard part:  all of the family members that follow.

I intend to be accurate, and fair (and use facts).  As for defensive?  Absolutely.  Part of a good defense is a good offense, as well.  And
introducing Virtex II Pro and then extending the family to some 10 devices sounds pretty good to me (2Vp2 to 2VP100).

Austin


Jack wrote:

> Sounds like you're being defensive, Austin.  Announcing product before
> it is available?  Xilinx does this all the time.  When did you first
> start talking about Virtex-II Pro?  I think I saw articles about two
> years ago.  I don't think this is a bad thing, necessarily. It is nice
> to know what is coming in advance; design cycles are shorter in FPGAs
> but they still aren't instantaneous.
>
> However, what about the 2V1500 I was told would be available by June
> (2001)?  I think it just came out this August (2002).  This is a
> little more design time than was necessary, don't you think?
> -Especially if you were counting on that June'01 delivery.  I believe
> this was also the case with the 2V2000.
>
> http://www.xilinx.com/prs_rls/vtx2ship.htm
> "The first members of the Virtex-II family... are sampling now with
> the rest the family sampling by mid 2001."
>
> Jack
>
> Austin Lesea wrote:
> > I will reiterate something Peter has said once before:  Altera has announced that they will have (note use of the future tense) .......


Article: 47426
Subject: Re: FPGA fail when Electrostatic discharge Occurs
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Sep 2002 15:00:10 GMT
Links: << >>  << T >>  << A >>
ESD mitigation can be a difficult science.  An ESD discharge to the board can
cause power supply spikes or dips, transients on clock or other critical signals
and so on.  Often it can be hard to identify the exact mechanism that is causing
the
disruption, and may be easier to protect the entry point better.  You might
consider
contacting someone who specializes in it such as Mike Violette of Washington
Laboratories, Ltd in Gaithersburg Md.

Jim Granville wrote:

> Jeremie WEBER wrote:
> >
> > >  You need to determine if this is Config stream corruption, or
> > > Logic-state engine corruption - it sounds like the latter.
> >
> > No, it is the logic state. All state machine are not a problem because all
> > states are checked and it always come back to a known state. But I use a ram
> > block wher all my datas are stored and this one seems to be corrupted.
> > A reset ( of my design, not of the chip itself ) could make the system
> > working but it not occurs.
>
> If you do not have a manual reset, I would add one, to confirm the
> system can re-init ( ie FPGA config latches, and logic state engines
> are all intact )
>
> >
> > > The design needs to have recovery schemes for this.
> >
> > Any advice on it ?
>
> If you are confidant your state engines recover, then once data
> corruption
> occurs, you will need to 're-init', rather like a uC WDOG.
>
> Of course, recognising the data is corrupt is not trivial in itself :)
>
> In a FPGA, if you have RAM to spare, you could try parity, or Error
> Correcting storage.
> ECC can flag a fix, so you can track errors under test.
>
> If the data is corrupted outside the ECC realm ( eg at 'instant of read'
> )
> then you cannot so easily error detect.
>
> > >  As ESD levels ramp, there will be a range where corruption occurs,
> > > but damage does not. Ramp it more, and damage starts...
> >
> > Honestly, the Spartan IIE is quite robust to ESD. Our test has been made
> > with 5kV ESD and with a kind of home made ESD Generator ( a piezzo gas
> > lighter ;-) ) wich seems to be higher than 5kV because the board does not
> > crash anymore at 5kV and crash with our home made ESD Generator !
>
>  This is quite an aggressive ESD test, so it's no surprise to see
> some effect.
>  The ESD ratings on chips are damage only, no-one promises
> to keep the device operational as well :)
>
> - jg

--
--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: 47427
Subject: Re: PCB Design for Altera FPGA
From: kayrock66@yahoo.com (Jay)
Date: 25 Sep 2002 08:16:32 -0700
Links: << >>  << T >>  << A >>
Using power planes is just a rule of thumb; its the EASIEST way of
guaranteeing a low impedance supply path.  But depending on the size
of your design, the number of outputs you switch at once, and other
things, isn't not entirely necessary.

On a 2 layer board you can do a copper pour of ground after you route
it, while its not as good as full plane its better than just routes. 
You can route your supply pins with wide traces, and before routing
anything else, bypass every supply pin as close to the pin as you can.
 Use an on board supply.

If your design fits on an 8000 family part, then your talking about a
really tiny design, so it will be a small part in any family.

Regards

Jarmo <jarmoma@REMTHIS.mail.student.oulu.fi> wrote in message news:<Pine.GSO.4.44.0209251113310.11071-100000@paju.oulu.fi>...
> Hey
> 
> I want to make Printed Circuit Board (PCB) for Altera Flex 8000 family.
> Problem is that I don't find any datasheet telling me how to do the
> powering for the Altera. Should I add decoupling capasitors and what
> values they should be?
> 
> Is there internal clock in Altera or should I add a crystall to my PCB?
> 
> If you are wondering why I want to use OLD Altera Flex 8000, because I
> want to add only 2 layers to my PCB. I think that new Alteras need
> separate power and ground layers, so 2 layers is not enough.
> 
> is there some websites/tutorials how to do PCBs for FPGAs?
> 
>  - Jarmo
>    jarmoma@mail.student.oulu.fi

Article: 47428
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: kayrock66@yahoo.com (Jay)
Date: 25 Sep 2002 08:40:47 -0700
Links: << >>  << T >>  << A >>
The package is a really a small part of the cost of these chips.  The
die are very large (and hence the circumfrence and associated I/O
ring), so I/O is cheap and easy to add, so they do.  A smaller package
pin count, while technically producable, may only reduce the cost a
few percent.  In contrast, on a small high yield die, package cost can
be a big part of the cost, but we're in the opposite end of the
spectrum with FPGAs.

So if the cost is nearly the same for a high or low I/O package, the
only advantage is ease of assembly for a larger pitch part.  Products
that use FPGAs tend to be low volume, high value, so theres not much
pressure to have a lower tech soldering process either.

So these are some of the reasons people end up doing like use and
using 40% of the pins in an 1152 pin package.


> We are constantly bumping up against the largest device in a cost
> effective package.  IE, we definitely would move to using a larger
> Virtex-II (XC2V4000) if it were available in anything smaller than an
> expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA
> package].  I realize Xilinx probably has their reasons for the
> offerings they have (most likely thermal?), but if they could overcome
> that, it'd be easy money for them, cause I'll bet there are others out
> there in the same boat as us.
> 
> Same went for the Virtex-E... the 600E was the largest you could get
> in a reasonable cost/size package.  The XCV812EM was available, but
> not competitively priced.  We would have used a large device if Xilinx
> had offered it in a FG676.  Instead, in both the Virtex-II and
> Virtex-E, we get to play roulette with MAP and PAR, constaintly
> bumping up against random timing violations that differ from run to
> run.
> 
> Anyone else in the same boat, wishing there were an XC2V4000-FG676 [or
> actually, just a 3000 with more LUTs, not more BRAM's]?
> 
>    Marc

Article: 47429
Subject: Re: virtex II pro development board
From: "Marty" <martin.quenneville@rd-tech.com>
Date: Wed, 25 Sep 2002 11:59:49 -0400
Links: << >>  << T >>  << A >>
Dan,

We use a development board from Insight Electronics. The board is available
for XC2VP4/P7 Virtex II-pro devices. You can purchase the board online on
their web site : http://www.insight-electronics.com.

Marty.

"Dan" <hombecker1962@hotmail.com> wrote in message
news:f6989659.0209242140.845a696@posting.google.com...
> Is anyone aware of current development boards and software packages
> available for the Virtex II Pro series with the embedded power pc
> processor (namely one or two).  I'm not having much luck finding them.
> I know it's a very recent product, and I think this is one of my
> problems.
>
> Thanks,
> Dan



Article: 47430
Subject: Re: Spartan II JTAG reconfiguration bug - workaround
From: "Steve Casselman" <sc@vcc.com>
Date: Wed, 25 Sep 2002 16:00:07 GMT
Links: << >>  << T >>  << A >>
The spartan II is a Virtex I and there is no "clear program memory" command
in the command set. They do have this in the Virtex II though. However since
the configuration files genereated by Impact are full configurations you
should be able to write over a configuration with no problem. This must be a
software bug. You can try and download Hotman from our web site it is not as
"automatic" as impact so it does not have some of the bugs.

Steve
www.vcc.com


> I sincerely hope this posting helps some future poor sap(s) from
> wasting as much time as I did.




Article: 47431
Subject: coregen DA FIR 7.0 singlerate/interpolated, floorplans, SRL16s and flip-flops
From: "Ken Mac" <aeu96186@yahoo.co.uk>
Date: Wed, 25 Sep 2002 17:13:42 +0100
Links: << >>  << T >>  << A >>
Hello folks,

I generated 2 filters using coregen - a singlerate and an interpolated
filter with the following common params:

coefficients:  "1,3"    (3 bits, signed, non-symmetric, fixed, optimisation
switched on)
input: 1 bit unsigned
parallel implementation with registered output

Zero Packing Factor = 4 for the interpolated filter.

Both filters take 9 slices on a xc2v40-fg256-5 using ISE 4.2.03i.

My question relates to why these filters should be the same size (in slices)
when the interpolated filter does "more".

Here are the mapping stats for both:

Singlerate:

    Number of Slices:                    9 out of     256    3%
   Number of Slices containing
      unrelated logic:                  0 out of       9    0%
   Number of Slice Flip Flops:         11 out of     512    2%
   Total Number 4 input LUTs:           4 out of     512    1%
      Number used as LUTs:                            3
      Number used as Shift registers:                 1
   Number of bonded IOBs:              11 out of      88   12%


Interpolated:

    Number of Slices:                    9 out of     256    3%
   Number of Slices containing
      unrelated logic:                  0 out of       9    0%
   Number of Slice Flip Flops:         11 out of     512    2%
   Total Number 4 input LUTs:           5 out of     512    1%
      Number used as LUTs:                            3
      Number used as Shift registers:                 2
   Number of bonded IOBs:              11 out of      88   12%


Looking at the post place and route floorplans of both, what jumps out is
that the singlerate case has 7 flip-flops being used on their own in slices
without the LUT (as an FG or an SRL16) whereas the interpolated case has
only 6 flip-flops on their own in slices.

It seems that, for the interpolated case, adding the 3 sample delay between
the filter taps (done with 3 SRL16s for the 3-bit signal) simply means that
coregen makes more efficient use of the logic - i.e. instantiates 1 less
flip-flop on its own.

It also seems that SRL16s are always mapped together with a flip-flop by the
tools (is this the case?) - presumeably with the flip-flop taking the last
delay of an N bit delay with the SRL16 doing N-1 delays (N <= 16) - is this
right.

Surely, then coregen could do a better job (i.e. less slices) of the
singlerate case since the interpolated filter simply requires more logic?
Or, could the slice cost of the singlerate case be reduced through some
clever manual floorplanning?

I realise that this post is a little hand-wavy and that you might not be
able to give me some categoric answers but I would appreciate your
thoughts/experience in these areas - even if you do put it all down to tool
"black magic"  ;-) .

Thanks for your time,

Ken



Article: 47432
Subject: Re: Clock balancing in DDR SDRAM design
From: John_H <johnhandwork@mail.com>
Date: Wed, 25 Sep 2002 17:19:04 GMT
Links: << >>  << T >>  << A >>
I'd expect balance concerns if the terminations weren't symmetric around Vtt.
Are you using the recommended SSTLII style terminations?  Beyond that, the
signal routing is the next point that would concern me.  The two signals should
be routed together to avoid skews and - to some extent - keep the differential
voltage signal coupled between the traces.  If the pair is on the same layer,
the routing can be kept to a minimum of skew.  A coworker just pointed out (as I
was looking at the DDR routing I have) that a pair is fine on two symmetric
internal layers between planes as long as they have the *same* routing - the
differential energy is vertical in the board.

Since you have a board that you're trying to get to "work," if the signals are
indeed suffering from different routings, you might be able to compensate by
playing with the termination values, both the series resisters and the Vtt
resistors.

The lag you measured - is this rising CLK and falling CLK* relative to a
reference?  If it's CLK destination relative to CLK source and CLK* destination
relative to CLK* source, there are severe layout issues.  If the "lag between
the two clocks" is the asymmetry, you might want to check (if possible) the real
delay from source to destination.

Good luck.


John Daae wrote:

> I have implemented a DDR SDRAM controller in a VIRTEX II but I have problems
> balancing the clock / not clock to the DDR Sdram. The design work with no
> errors, but the switching where the clk and not clk intersect is outside the
> DDR Sdram specification (MICRON specify that the intersction between the two
> clock should always lie within the 1.05-1.45 voltage range. This is observed
> using a ocsilloscope with active probes.
>
> The two clock are generated be dual-data rate FFDs as follow (the CLK and
> nCLKcomes from a DCM with duty-cycle correction set):
>
>  ---------------------------------------------------------------------------
> --
>   --------------------------------------------------------------------------
> ---
>   -- SDRAM clock generation
>   --------------------------------------------------------------------------
> ---
>   --------------------------------------------------------------------------
> ---
>   clk_gen :
>     FDDRRSE port map (
>       Q  => ddr_clk,
>       D0 => '1',
>       D1 => '0',
>       C0 => clk,
>       C1 => nCLK,
>       CE => '1',
>       S  => '0',
>       R  => '0');
>
>   nCLK_gen :
>     FDDRRSE port map (
>       Q  => ddr_CLK180,
>       D0 => '0',
>       D1 => '1',
>       C0 => clk,
>       C1 => nCLK,
>       CE => '1',
>       S  => '0',
>       R  => '0');
>
> ----------------------------------------------------------------------------
> ----------------
>
> Using 1.25V as a reference, the lag between the two clocks seen on the PCB
> is as follow:
>
> 128 ps using SSTL2_II
> 327 ps using SSTL2_II_dci
> 618 ps using SSTL2_I
> 1364 ps using SSTL2_I_dci
>
> Obviously the latter standards have lower drive capability and thus slower
> slopes and thereby more lag between the clocks.
>
> But I think there must be a lag between the clocks before the actual drivers
> which I cannot account for. I have inspected the FDDRRSE in the FPGA Editor
> a find that there is no delay difference between the clocks into the clock
> pins. So WHAT causes the difference?
>
> ANY IDEAS ANYONE?
>
> Thanks
>
> John


Article: 47433
Subject: ESD Undressing Story
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 25 Sep 2002 10:32:28 -0700
Links: << >>  << T >>  << A >>

--------------C52BA1F100BFC43FEDF15FD6
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Jérémie,

Many years ago I hired an ESD expert to teach me how to find, and fix ESD
problems in a system.

I will describe what he did.

He came in with a roll of aluminum foil.

He wrapped the entire system in foil (cables and all), and then zapped it.  If
it failed, he said that the problem was probably nearly hopeless, and would
require a lot of time and experimentation, as the system was hyper-sensitive.

It passed, so I was happy to have gotten past the first hurdle.

He then unwrapped just the cables, and let them hang out.

He zapped it, and it failed (processor reset).

We then had to place small capacitors, zeners, or resitive diode networks on
all interfaces to all cables.  We did that over two weeks, and then he came
back.

The unwrapping continued.  We opened up the keyboard area.

We zapped it, and it failed.

Again we went through all interconnections to the keyboard, and protected
them.  Then it passed.

We then unwrapped everything down to the metal box (chassis).  We zapped it
and failed.

It turns out that a screw every 3" (~75 mm) to a sheet metal lip that had an
over-lap will limit the electric charge from racing through the slot, and
upsetting 5V logic.  Maybe you would need to place the screws at 2" intervals
now....

(The ESD discharge can be modeled as a traveling wave over any surface:  a
sheet of charge that goes over, around, and through any aperture at the speed
of light with a frequency range into the 10's of GHz).

So, a month later, some money and a few dozen R, C and diodes, and a roll of
aluminum foil later, we had 12KV human body model ESD protection capability.

By the way, after we did the ESD, we also passed FCC/VDE for EMI/RFI.  If you
do a good job on one, you also solve the other.

I recommend hiring the consultant to do this for you the first time.  After
that, it is embarrasing to have to hire them again unless you just can't find
the last sneaky places where ESD is getting into your system,

Austin

"Jérémie WEBER" wrote:

> I have a problem with a design ( 200k spartan II E ) that fail when an
> Electrostatic discharge occurs.
>
> I presume that some flip-flop are reseted but not all. That means that my
> design fail and is unstable.
>
> I have set some hardware things to avoid a large part of this problems but
> when it occurs I always fail.
>
> Have you got any Idea to secure the FPGA design itself ?
>
> Regards.
>
> Jérémie WEBER



Article: 47434
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: John_H <johnhandwork@mail.com>
Date: Wed, 25 Sep 2002 17:41:03 GMT
Links: << >>  << T >>  << A >>
Keep in mind that the lower-cost devices such as the Spartan-IIE (and the
Cyclone?), the package *is* a significant portion of the overall cost, not
single digit percent.  In the enormous xc2v6000, it's hard to imagine how
any package would impact the price.

I've been buying the bigger devices for pin count with low logic utilization
in my current designs compared to the telecom centric stuff I was doing a
few years back where I/O wasn't a big concern.

It takes all kinds...


Jay wrote:

> The package is a really a small part of the cost of these chips.  The
> die are very large (and hence the circumfrence and associated I/O
> ring), so I/O is cheap and easy to add, so they do.  A smaller package
> pin count, while technically producable, may only reduce the cost a
> few percent.  In contrast, on a small high yield die, package cost can
> be a big part of the cost, but we're in the opposite end of the
> spectrum with FPGAs.
>
> So if the cost is nearly the same for a high or low I/O package, the
> only advantage is ease of assembly for a larger pitch part.  Products
> that use FPGAs tend to be low volume, high value, so theres not much
> pressure to have a lower tech soldering process either.
>
> So these are some of the reasons people end up doing like use and
> using 40% of the pins in an 1152 pin package.
>
> > We are constantly bumping up against the largest device in a cost
> > effective package.  IE, we definitely would move to using a larger
> > Virtex-II (XC2V4000) if it were available in anything smaller than an
> > expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA
> > package].  I realize Xilinx probably has their reasons for the
> > offerings they have (most likely thermal?), but if they could overcome
> > that, it'd be easy money for them, cause I'll bet there are others out
> > there in the same boat as us.
> >
> > Same went for the Virtex-E... the 600E was the largest you could get
> > in a reasonable cost/size package.  The XCV812EM was available, but
> > not competitively priced.  We would have used a large device if Xilinx
> > had offered it in a FG676.  Instead, in both the Virtex-II and
> > Virtex-E, we get to play roulette with MAP and PAR, constaintly
> > bumping up against random timing violations that differ from run to
> > run.
> >
> > Anyone else in the same boat, wishing there were an XC2V4000-FG676 [or
> > actually, just a 3000 with more LUTs, not more BRAM's]?
> >
> >    Marc


Article: 47435
Subject: Re: pulldown resistor value for Xilinx CPLD
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 25 Sep 2002 10:53:50 -0700
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> What's magic about a toggle switch?  I thought they all bounced too.
>
> Are you thinking of SPDT kicking an R-S type FF?

Yes, exactly. The storage device can be a latch,  even be a cross-coupled set of
inverters, in which case you need only one I/O pin.
You just yank that pin to Vcc or to ground. High instantaneous current, but only
for a nansecond or two.
Contact bounce is irrelevant in that case
Peter Alfke


Article: 47436
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 25 Sep 2002 18:24:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D91F52F.A89F0BBA@mail.com>, John_H  <johnhandwork@mail.com> wrote:
>Keep in mind that the lower-cost devices such as the Spartan-IIE (and the
>I've been buying the bigger devices for pin count with low logic utilization
>in my current designs compared to the telecom centric stuff I was doing a
>few years back where I/O wasn't a big concern.

One observation is that they are still using perimiter pads on these
parts, so that upping the IO beyond a certain point necessitates a
bigger die.

I'd personally like to see an area pad FPGA, where some of the logic
blocks are replaced with pads, so we wouldn't have these issues.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 47437
Subject: FPGA programming via microcontroller
From: dhorner@med-web.com (David Horner)
Date: 25 Sep 2002 12:29:59 -0700
Links: << >>  << T >>  << A >>
I am very interested in programming and running the fpgas from a microcontroller.

Does anyone know where I can find a good book or tutorial on the net?

Know any good evaluation/proto boards?

Thanks
--Dave

Article: 47438
Subject: Re: FPGA programming via microcontroller
From: "Mikhail Matusov" <matusov@ANNTIsquarepegSPPAMM.ca>
Date: Wed, 25 Sep 2002 20:31:05 GMT
Links: << >>  << T >>  << A >>
There is many ways you can do it. Xilinx has published multiple detailed
appnotes on this. Here are some of them:
http://www.xilinx.com/xapp/xapp058.pdf
http://www.xilinx.com/xapp/xapp176.pdf
http://www.xilinx.com/xapp/xapp188.pdf
http://www.xilinx.com/xapp/xapp098.pdf

I believe Altera has similar information for their chips...

/Mikhail



"David Horner" <dhorner@med-web.com> wrote in message
news:b67cf57a.0209251129.129fc6f1@posting.google.com...
> I am very interested in programming and running the fpgas from a
microcontroller.
>
> Does anyone know where I can find a good book or tutorial on the net?
>
> Know any good evaluation/proto boards?
>
> Thanks
> --Dave



Article: 47439
Subject: Virtex2 Block Multiplier: Faster, Faster
From: rrr@ieee.org (Rajeev)
Date: 25 Sep 2002 13:42:55 -0700
Links: << >>  << T >>  << A >>
I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block
Multipliers.  I'm looking at the Post-Place-and-Route Static Timing Analyzer.

I added output registers on the block RAMs to bring the Min Period down from
9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers
(Tmult=4.121ns plus 2 nets plus FFin/outs).

Is this it, or is there anything I can do to make it faster in this speed
grade ?  I don't want to increase the multiplier latency, as I'm working with
an iterative algorithm and the multiplier output gets fed back to the input.

Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041
ns.  How is this possible ?

Thanks,
-rajeev-

Article: 47440
Subject: Re: spartan II and PCI 5 volt
From: "dohi" <y_dohi@hotmail.com>
Date: Thu, 26 Sep 2002 05:45:22 +0900
Links: << >>  << T >>  << A >>
Kon-nichi-wa,

Spartan-II's I/Os configured in LVTTL accept 5 volts, drive more than 2.4
volts
(at Vcco=3.3 volts) then it works with 5 volt PCI bus. (with right design
^_^;)
But Spartan-IIE, Virtex-E and later FPGAs are not for 5 volt compliance.

Good Luck!


--
-------------------------
DOHI, Yutaka
mailto: y_dohi@hotmail.com
http://www4.justnet.ne.jp/~dohi/


"Jamba" <xxxx@supereva.it> wrote in message
news:wvek9.140505$ub2.3069274@news1.tin.it...
>
>
> I have to mount a spartan II fpga ( 3.3 volt ) with an 5 volt interface
pci
> 32 bit.
> How is it possible?
>
> Thanks, J
>
>


Article: 47441
Subject: Re: Unpredictable Place and Route
From: Dali <dadicool@ifrance.com>
Date: Wed, 25 Sep 2002 22:21:19 +0000
Links: << >>  << T >>  << A >>
 From previous experience with the xilinx tools at my compagny, if you 
delete the files generated by the place&route tool when you want to 
rerun the flow, it makes the P&R faster and gives better results. This 
is due to the P&R tool taking old files as a "reference", just like 
reentrant routing.

I did not follow what Xilinx had to say about it but I would be curious 
to know.

Dali

Clyde R. Shappee wrote:
> No, the design is only half empty (optimist!).
> 
> What I have learned today  is that the place and route tool is passing constraints onto the Xilinx flow,
> and this has been probably constraining the design where it should not be  so stringent.
> 
> I had some help today from a resource that is getting me on my way to properly constraining the design.
> 
> It does appear that the varying number of logic levels is coming from the Xilinx P/R and not the
> synthesis tool.
> 
> Clyde
> 
> Marc Randolph wrote:
> 
> 
>>"Clyde R. Shappee" <clydes@world.std.com> wrote in message news:<3D910893.3ACBCF64@world.std.com>...
>>
>>>Hello, all,
>>>
>>>I am working a design with the Xilinx Spartan IIe, using ISE 4.2 sp3,
>>>Sinplicity 7.1 for synthesis.
>>>
>>>My design is relatively minimally constrained and meets static timing.
>>>In my report I see 8 levels of logic associated with my system clock.
>>>
>>>Today, I removed some unused logic, and reduced the length of some shift
>>>registers in my design, dropping about 32 flip-flops.
>>>
>>>Now the design fails to make static timing and the number of levels of
>>>logic associated with my clock has gone up to 12!
>>>
>>>What is at work here?
>>>
>>>Is the synthesis tool shooting me in the foot, or is it in the Xilinx
>>>tool, or my constraints.
>>
>>Howdy Cylde,
>>
>>Is this device pretty full?  We've only run into this type of problem
>>when things are pretty packed.
>>
>>When this occurs, our typical mode of operation has been to do a
>>multi-pass place and route if it is close to meeting timing (say a
>>timing score of under 10000).  One of the passes will usually hit on
>>an overnight session.
>>
>>If the timing is further out than that, we just continue improving the
>>code where we can (often times in areas completely unrelated), and the
>>next time around, it often meets timing, or gets very close (and will
>>meet with a multi-pass session).
>>
>>Good luck,
>>
>>   Marc
> 
> 



Article: 47442
Subject: Re: Finding nets in hierarchy
From: Dali <dadicool@ifrance.com>
Date: Wed, 25 Sep 2002 22:29:05 +0000
Links: << >>  << T >>  << A >>
I would look in the file generated by your synthesis tool (edif for 
synplicity) because that's where the nets are named with such generic names.

Then you can then look at the net drivers. What you can do also is to 
ask the synthesis tool to preserve hierarchy so you can locate the net 
into a module easily.

Dali

David R Brooks wrote:
> Running the Xilinx ISE 4.2i tools, I get a warning
>   ERROR:NgdBuild:455 - logical net 'N812' has multiple drivers
> 
> Now the meaning is obvious enough, but the problem is, how to locate
> this net (it is a synthesiser-generated name) in the hierarchy. The
> tools don't give any indication where it is located. It is a large
> project, with over 40 VHDL design elements in a deep hierarchy.
> 
> A search of the output files shows none of them contain this string,
> except the NGD log, which only contains the error as above.
> 
> This error causes no post-synthesis VHDL file to be generated, else
> one could search that file for the net.
> 
> Any ideas?
> 



Article: 47443
Subject: Re: Virtex2 Block Multiplier: Faster, Faster
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 25 Sep 2002 15:57:20 -0700
Links: << >>  << T >>  << A >>


Rajeev wrote:

> <snip>
> Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041
> ns.  How is this possible ?

How wide is your multiplier, both operands and the result?
Fewer than 18-bit-wide operands improve the through-delay.
Peter Alfke-



Article: 47444
Subject: Re: ESD Undressing Story
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Sep 2002 22:58:26 GMT
Links: << >>  << T >>  << A >>

--------------9E61DE124A94F663DF680181
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Much like my experiences.   He also had a box of all sorts
of ferrites with him, and in my case he stuck around until
we got the system passing.

Austin Lesea wrote:

> Jérémie,
>
> Many years ago I hired an ESD expert to teach me how to
> find, and fix ESD problems in a system.
>
> I will describe what he did.
>
> He came in with a roll of aluminum foil.
>
> He wrapped the entire system in foil (cables and all), and
> then zapped it.  If it failed, he said that the problem
> was probably nearly hopeless, and would require a lot of
> time and experimentation, as the system was
> hyper-sensitive.
>
> It passed, so I was happy to have gotten past the first
> hurdle.
>
> He then unwrapped just the cables, and let them hang out.
>
> He zapped it, and it failed (processor reset).
>
> We then had to place small capacitors, zeners, or resitive
> diode networks on all interfaces to all cables.  We did
> that over two weeks, and then he came back.
>
> The unwrapping continued.  We opened up the keyboard area.
>
> We zapped it, and it failed.
>
> Again we went through all interconnections to the
> keyboard, and protected them.  Then it passed.
>
> We then unwrapped everything down to the metal box
> (chassis).  We zapped it and failed.
>
> It turns out that a screw every 3" (~75 mm) to a sheet
> metal lip that had an over-lap will limit the electric
> charge from racing through the slot, and upsetting 5V
> logic.  Maybe you would need to place the screws at 2"
> intervals now....
>
> (The ESD discharge can be modeled as a traveling wave over
> any surface:  a sheet of charge that goes over, around,
> and through any aperture at the speed of light with a
> frequency range into the 10's of GHz).
>
> So, a month later, some money and a few dozen R, C and
> diodes, and a roll of aluminum foil later, we had 12KV
> human body model ESD protection capability.
>
> By the way, after we did the ESD, we also passed FCC/VDE
> for EMI/RFI.  If you do a good job on one, you also solve
> the other.
>
> I recommend hiring the consultant to do this for you the
> first time.  After that, it is embarrasing to have to hire
> them again unless you just can't find the last sneaky
> places where ESD is getting into your system,
>
> Austin
>
> "Jérémie WEBER" wrote:
>
>> I have a problem with a design ( 200k spartan II E )
>> that fail when an
>> Electrostatic discharge occurs.
>>
>> I presume that some flip-flop are reseted but not all.
>> That means that my
>> design fail and is unstable.
>>
>> I have set some hardware things to avoid a large part of
>> this problems but
>> when it occurs I always fail.
>>
>> Have you got any Idea to secure the FPGA design itself ?
>>
>> Regards.
>>
>> Jérémie WEBER
>
--
--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: 47445
Subject: Re: writing across a column in an SDRAM
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Sep 2002 23:05:40 GMT
Links: << >>  << T >>  << A >>
It sounds like his image is too big to do a corner turn in on-chip memory.
Without doing clever things he pretty much is stuck with single word writes.
Fortunately, he doesn't have to live with that.  Rather than reading linearly,
you can be a little cute about how the writes are done so that the data stored
in the memory is a transformation 'halfway between' the row ordered and the
column ordered image.  The sole purpose of doing that is to be able to use some
small bursts in order to hide the active commands.  Using auto precharge
alleviates the need for an explicit precharge command, but you do still have to
be careful to allow enough time for the precharge, active and the minimum times
between.  With 4 banks, I think you can get there with a burst size of 4, and
perhaps 2 if the cas latency is 2.  It is going to take a bit of playing with
the address order on both read and write, plus a smallish reordering buffer on
both the read and write paths to make it happen.

"A. Nelson" wrote:

> I have an odd problem that I'd like anyone's opinion on.
>
> I have a data stream, that I'd like to write into SDRAM (I'm writing my own
> controller, so I can do it any way I'd like).  However, I don't want to
> write across a row (like you're supposed to do, so you can take advantage of
> bursting), but rather across a column.
>
> This means that every word would go to a different row.  So, every word
> would require a full write cycle (active, write, precharge).  This is far
> too slow.
>
> So, I got the idea of "bursting" across the banks (which allows for 4
> writes, before a precharge), like this:
>
> (A=Active, W= write, P = precharge, r=row, b=bank, c=column)
>
> A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c
> 0, b 2), A (r 0, b 3), W (c 0, b 3), P
>
> then
>
> A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c
> 0, b 2), A (r 1, b 3), W (c 0, b 3), P
>
> and so on (with the required NOPs, to meet timing).
>
> I was also considering doing all the actives, then writes, then precharge
> (A, A, A, A, W, W, W, W, P).
>
> Any other suggestions?

--
--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: 47446
Subject: Re: Virtex2 Block Multiplier: Faster, Faster
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Sep 2002 23:08:52 GMT
Links: << >>  << T >>  << A >>
YOu get a bit more by carefully placing the flip-flops around the multiplier so
that each gets a direct connect to the multiplier rather than having to go
through extra pips to get there.  You'll have to go into the FPGA editor to
figure out where those need to go.  THere may be an app note on the xilinx
website detailing that placement for max performance, I know it had been talked
about.

Rajeev wrote:

> I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block
> Multipliers.  I'm looking at the Post-Place-and-Route Static Timing Analyzer.
>
> I added output registers on the block RAMs to bring the Min Period down from
> 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers
> (Tmult=4.121ns plus 2 nets plus FFin/outs).
>
> Is this it, or is there anything I can do to make it faster in this speed
> grade ?  I don't want to increase the multiplier latency, as I'm working with
> an iterative algorithm and the multiplier output gets fed back to the input.
>
> Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041
> ns.  How is this possible ?
>
> Thanks,
> -rajeev-

--
--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: 47447
Subject: Re: Virtex2 Block Multiplier: Faster, Faster
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Sep 2002 23:10:43 GMT
Links: << >>  << T >>  << A >>
Oh,

one more thing.  you could use a pair of multipliers and interleave them so that
you get two products per clock.

Rajeev wrote:

> I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block
> Multipliers.  I'm looking at the Post-Place-and-Route Static Timing Analyzer.
>
> I added output registers on the block RAMs to bring the Min Period down from
> 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers
> (Tmult=4.121ns plus 2 nets plus FFin/outs).
>
> Is this it, or is there anything I can do to make it faster in this speed
> grade ?  I don't want to increase the multiplier latency, as I'm working with
> an iterative algorithm and the multiplier output gets fed back to the input.
>
> Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041
> ns.  How is this possible ?
>
> Thanks,
> -rajeev-

--
--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: 47448
Subject: Re: Clock balancing in DDR SDRAM design
From: David R Brooks <daveb@iinet.net.au>
Date: Thu, 26 Sep 2002 07:21:27 +0800
Links: << >>  << T >>  << A >>
XAPP200 speaks to this issue, as regards getting the balance right
*within* the chip.
It shows one clock phase generated from the DLL, and a simple inverter
used to generate the other. So the flow is:
 DLL --+---------- OBUF --> clk
       |
       +-- INVT -- OBUF --> clkb

This works, because the inverter is pulled into the output block.
Assuming you have placed the outputs in adjacent pads (in XAPP200:
   NET ddr_clkb LOC = E28 ;
   NET ddr_clk  LOC = C30 ; 
 ), the wire-delay to the pads must be equal, as it is the same wire.
The extra delay from the buried inverter is apparently negligible.

"John Daae" <john.daae@datarespons.no> wrote:

:I have implemented a DDR SDRAM controller in a VIRTEX II but I have problems
:balancing the clock / not clock to the DDR Sdram. The design work with no
:errors, but the switching where the clk and not clk intersect is outside the
:DDR Sdram specification (MICRON specify that the intersction between the two
:clock should always lie within the 1.05-1.45 voltage range. This is observed
:using a ocsilloscope with active probes.
:
:The two clock are generated be dual-data rate FFDs as follow (the CLK and
:nCLKcomes from a DCM with duty-cycle correction set):
:
: ---------------------------------------------------------------------------


Article: 47449
Subject: Re: Virtex2 Block Multiplier: Faster, Faster
From: Yenni Totong <yenni.totong@xilinx.com>
Date: Wed, 25 Sep 2002 16:31:28 -0700
Links: << >>  << T >>  << A >>
Reference :
 http://www.xilinx.com/xapp/xapp636.pdf


Ray Andraka wrote:

> YOu get a bit more by carefully placing the flip-flops around the multiplier so
> that each gets a direct connect to the multiplier rather than having to go
> through extra pips to get there.  You'll have to go into the FPGA editor to
> figure out where those need to go.  THere may be an app note on the xilinx
> website detailing that placement for max performance, I know it had been talked
> about.
>
> Rajeev wrote:
>
> > I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block
> > Multipliers.  I'm looking at the Post-Place-and-Route Static Timing Analyzer.
> >
> > I added output registers on the block RAMs to bring the Min Period down from
> > 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers
> > (Tmult=4.121ns plus 2 nets plus FFin/outs).
> >
> > Is this it, or is there anything I can do to make it faster in this speed
> > grade ?  I don't want to increase the multiplier latency, as I'm working with
> > an iterative algorithm and the multiplier output gets fed back to the input.
> >
> > Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041
> > ns.  How is this possible ?
> >
> > Thanks,
> > -rajeev-
>
> --
> --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




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