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 44200

Article: 44200
Subject: Re: Altera APEX reconfigurates endlessly
From: "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl>
Date: Thu, 13 Jun 2002 21:36:22 +0200
Links: << >>  << T >>  << A >>

"Michael J." <michajo@gmx.de> wrote in message
news:ae9hkj$a11$1@nets3.rz.RWTH-Aachen.DE...
> Hi all,
>
> in my design a EP20K200CQ240C7 gets his
> configuration from 2 EPC2. After configuration
> the APEX runs for ~500 ms then configuration
> restarts ~200 ms and so on.
> An endless loop .......
>
> What may be wrong ?
>
> Thanks in advance
> Michael


Have you put the proper pullup resistors to the nConfig etc. lines? Download
the latest version of Appnote 116 from the Altera website and compare it
with your schematic. Could also be crosstalk or so.

Best regards,


Ben



Article: 44201
Subject: Re: fpga and ultra highspeed counters
From: kayrock66@yahoo.com (Jay)
Date: 13 Jun 2002 13:16:55 -0700
Links: << >>  << T >>  << A >>
I don't want to spoil your fun but this sounds like something that
might already be available.  Look at those PC intrumentation guys like
National Instruments and the like, they may have something you can use
or that can be gated.

Regards

p.s. PDP-11, I haven't seen those used for a while.

John_H <johnhandwork@mail.com> wrote in message news:<3D067F61.FADAE0B@mail.com>...
> Another idea for lots of capability in small space depending on the detail of your
> needs.  If you want your read value accurate to a few nanoseconds *and* you need
> access to multiple values with a few 10s of nanoseconds, this approach wouldn't
> work.
> 
> Use a Virtex-II XC2V40 device.
> 
> Bring the gate in on the DDR input registers.
> 
> For N counters, use N lower count stages of only a few bits to add zero, one, or two
> bits depending on the DDR gate.
> 
> Cycle through a dual-port CLB SelectRAM (or BlockRAMs for that matter), replacing
> the LSbits with the live lower stage value and incrementing the upper bits by one as
> appropriate.  This function can be done at a slower speed than the counter.
> 
> Read the count value directly from the dual-port RAM.
> 
> If you need a read strobe to catch a live count value rather than one that's a few
> cycles off due to the cycling, you can add a little logic to preempt the normal
> cycling and process the live value.
> 
> The resolution and capabilities you want could probably support up to 64 counters of
> 32 bits each at nearly 800MHz (based on DDR capabilities but possibly limited by
> 8-bit 0/+1/+2 adders) in a part you can get for a decent price.
> 
> A fun little project.

Article: 44202
Subject: Re: MAP problem with RLOC'ed macros
From: Ray Andraka <ray@andraka.com>
Date: Thu, 13 Jun 2002 20:31:41 GMT
Links: << >>  << T >>  << A >>
Aw man!   I'm still using mostly 7.03 because I have a couple projects that started before 7.1
came out and I don't like switchin horses midstream.   I guess we now will have to put the syn
keeps before the LUT (!!!).  That does get messy.  I'm still very annoyed that Synplify thinks
that if it can figure out what is in a black box (by virtue of the black box happening to be a
xilinx primitive) it has a right to muck with it.  As far as I am concerned, if it is a black
box, it should not be mucked with PERIOD.  Of course the Synplicity response is that they don't
see it as a real problem.  This is right up there with the tristate push through issue.  It
completely wrecks the libraries I've put together over the past 3 years.  Guess I'll be
spending time looking for a work-around once again :-(

John_H wrote:

> I "hadn't" had many problems with MUXCYs either.  7.1 is messing me up.  With a syn_keep on
> the LUT outputs, Synplify is adding a LUT1_2 (through-wire) between the keepbuf and the
> MUXCY select.  Since the Xilinx P&R tools don't expect such superfluous slop, it dutifully
> implements the LUT1_2 with the MUXCY and the LUT that *should* drive it ends up in the
> adjacent LUT, out through .Y and back in through .BX - yeesh.
>
> Ray Andraka wrote:
>
> > I haven't had too much trouble with the MUXCY's if I put syn_keeps on the LUT output
> > driving the select.
> >
> > Brian Davis wrote:
> >
> > > John_H wrote:
> > > >
> > > >I tried a MUXCY primitive redefinition (I called it MUXCYdammit) with
> > > >syn_hier="hard" like I did earlier with an FDRE but if you push down
> > > >into the instance in HDL_Analyst, there's a pass-LUT on the sel input.
> > > >
> > >
> > >  By "redefinition", do you mean:
> > >
> > >   A) put a MUXCYdammit wrapper with syn_hier="hard" around a MUXCY
> > >
> > > or,
> > >
> > >   B) black box something called MUXCYdammit and edit the EDIF
> > >      post-synthesis to fix up the primitive names
> > >
> > >  I think "B" is fairly bulletproof, but you need a search-and-replace
> > > to fix up the EDIF names, and a wrappered simulation library to let you
> > > sim the primitives that have the tiny brown paper bags over their heads.
> > >
> > > Brian
> > >
> > > John_H <johnhandwork@mail.com> wrote in message news:<3D07B0CB.F77B1634@mail.com>...
> > > > I'm having MUXCY trimming problems *right now*.  I tried to take my 29 MUXCY
> > > > instantiations and convert them into an array of instances.  Yuck!  The physical
> > > > implementation of my chain became toast once Synplify started "optimizing" the pass
> > > > elements out of the chain (I have several in the middle).
> > > >
> > > > The inclusion of oh-so-many LUT1_2 elements is getting at my nerves as well:  I
> > > > tried a MUXCY primitive redefinition (I called it MUXCYdammit) with syn_hier="hard"
> > > > like I did earlier with an FDRE but if you push down into the instance in
> > > > HDL_Analyst, there's a pass-LUT on the sel input.  Once again Synplify knows
> > > > better.  Oy.
> > > >
> > > > The apps engineers are looking at my chain, but I imagine it's back to the 29
> > > > individual instances.  I hope those aren't broken!
> > > >
> > > > - John_H
> > > >
> > > >
> >
> > --
> > --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

--
--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: 44203
Subject: Re: Altera APEX reconfigurates endlessly
From: mike_one_11@yahoo.com (Mike)
Date: 13 Jun 2002 14:04:17 -0700
Links: << >>  << T >>  << A >>
You are probably asserting nCONFIG somehow.  That would initiate a
reconfiguration.  Monitor that line, and see if something is pulling
it down, or if there are any glitches on it once in user-mode

good luck

"Michael J." <michajo@gmx.de> wrote in message news:<ae9hkj$a11$1@nets3.rz.RWTH-Aachen.DE>...
> Hi all,
> 
> in my design a EP20K200CQ240C7 gets his
> configuration from 2 EPC2. After configuration
> the APEX runs for ~500 ms then configuration
> restarts ~200 ms and so on.
> An endless loop .......
> 
> What may be wrong ?
> 
> Thanks in advance
> Michael

Article: 44204
Subject: Re: Power supply caps on PCB
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 14 Jun 2002 09:59:13 +1200
Links: << >>  << T >>  << A >>
John_H wrote:
<snip> 
> The wide range of frequencies is, indeed, very important.  I had kept close to my
> engineering heart the "truth" that more capacitance is most often a good thing, that low
> capacitance values were silly.  If I throw together a dozen 1uF ceramic caps, I end up
> with a nice low impedance at the SRF but not so very low a decade or two above or
> below.  One graph I'm looking at shows an SRF of about 7MHz for a 1uF 1206.  The
> impedance at 7MHz is about 0.1 Ohm each.  The impedance drops to 1ohm around 250kHz and
> 150MHz.  While these values aren't bad, consider the current demands for 150MHz:  1/12
> Ohm (12 1uF caps in parallel, ignoring other parasitics for the moment) will keep the
> voltage tolerance within 100mV for 1.2A surges. 

Sudden load step-response is very important. The Pentium power supplies
know all
about this, and bigger FPGA ones should too.

> Maybe this is sufficient, but one cap
> with an SRF around 150MHz would give you performance nearly as good at 150MHz.  

Not sure you can move from load step, to this SRF comment - a load step
cannot have
a single-point 150Mhz spectrum  ?

> The 7MHz
> filtering in the 12 cap configuration above is probably significant overkill at 8.3
> milliOhm.  A mix would allow a low overall impedance floor without overkill.

 I think where SRF _can_ help, is not so much in total lowering, but in
a 
'focus on area of complaint' - eg a marine radio telephone user at
156MHz etc.

 The tolerances and tempco's are such that the notch will move about a
bit anyway...

-jg

Article: 44205
Subject: must signals to ram come from a register?
From: "Holger Kleinegraeber" <olgi42@web.de>
Date: Fri, 14 Jun 2002 00:37:22 +0200
Links: << >>  << T >>  << A >>
Hello,

when writing to ram (e.g. block ram in a virtex) must the signals to the ram
come from a register? The timing diagrams I found implicate this (e.g.
http://www.free-ip.com/ramlib/ram_dp.html ). The adress signal or the 'write
enable' signal have a very short delay in my design. But the data word I
want to store is the critical path and so arrives at the end of the clock
period. Is this sufficient for the ram to sample the data?

Kind regards,
   Holger




Article: 44206
Subject: Re: Xilinx JTAG verification failed
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Thu, 13 Jun 2002 17:41:25 -0500
Links: << >>  << T >>  << A >>
Damir Danijel Zagar wrote:

> Hi,
>
> I've successfuly implemented design on Spartan II 200 but during
> JTAG programming (Parallel Cable IV) verification fails on 257
> location. Also, when manualy identifying the JTAG chain, Spartan
> is reported as Virtex. Otherwise FPGA works fine and user ID
> code is readable without any problem. What could cause the
> verification problems? Regards,

The Parallel Cable does not work with certain motherboards, due
to the particular chip in the parallel port.  Others work with
very high reliability.  So, you might try it with a different PC and
see if it works better.  I have experienced this in a couple of cases,
and then found a PC that worked well, and used that one for the
JTAG programming or download.

Jon


Article: 44207
Subject: Re: 20,000 gates?
From: "Tony Burch" <tony@burched.com.au>
Date: Fri, 14 Jun 2002 09:01:22 +1000
Links: << >>  << T >>  << A >>
BurchED now sells a low cost board
based on the XC2S300E.
http://www.burched.com.au/B5Spartan2.html
Excellent value at US$190.

Best regards
Tony Burch
http://www.BurchED.com
Low cost FPGA boards, for System-On-Chip
prototyping and education

"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:aeao2h$5bfsh$1@ID-84877.news.dfncis.de...
> "Roger King" <roger@king.com> schrieb im Newsbeitrag
> news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com...
> > I don't have the info, but what about the XC2S50 chip/family?
>
> XC2S50 is a Spartan-II, 50k gates (whatever gates means  . .;-)
>
> It has also 6 BlockRams, 4kbit each.
>
> > and is that a good number?
>
> XC2S50 is a nice chip to start with. But as others already said, go for a
> 200K or 300K gates device, they cost not much more (together with a
> demoboad).
> Also remember, the bigger the device, the cheaper the logic funktions
> ($/LUT), with some minor exceptions.
>
> --
> MfG
> Falk
>
>
>
>



Article: 44208
Subject: Re: compatibility between F3.1 and F4.1
From: John Williams <j2.williams@qut.edu.au>
Date: Fri, 14 Jun 2002 09:26:59 +1000
Links: << >>  << T >>  << A >>


Hristo Stevic wrote:
> 
> Hellom
> is there any compatibility issue between the Foundation 3.1 and
> Foundation 4.1. I use schematic entry

Hristo,

I don't think schematics from 3.1 can be read into 4.1.

Regards,

John

Article: 44209
Subject: Re: Power supply caps on PCB
From: John_H <johnhandwork@mail.com>
Date: Thu, 13 Jun 2002 23:30:19 GMT
Links: << >>  << T >>  << A >>
The "notch" isn't a 20dB dip in a 1% bandwidth as notch filters would.  The SRF gives the
bottom of a somewhat wide bottom.  My point is that - rather than paralleling a bunch of these
"bathtubs" to get an overall "bathtub" curve so that the ends provide a low enough impedance -
one should get the SRFs lined up across a wide enough coverage that the overall impedance
floor is much wider at a target impedance.  A 10:1 impedance for the 1uF cap I mentioned is
about 250kHz to 150 MHz.  If the minimum impedance on the chosen caps are low and the SRFs are
distributed, the overall effect is greater wideband stiffness.

Load-step response is addressed by spreading the SRFs across a range of frequencies.  The
clock has harmonics and the data tends to downspread, including those harmonics.  There's a
time domain for the step and a frequency domain for the impedances that need to line up to
each other.  The balance can be struck without "one 0.1uF and one 0.01uF cap per power/ground
pin pair."

The single-point spectrum isn't my concern as much as "covering holes."  Make sure your
impedance at all frequencies is low.  If the impedance could be improved across a frequency
band that isn't stiff enough, add a cap that covers that hole.

The tolerances and tempcos will move the bottom around a little, but compared to the 2x bottom
of around 2-20MHz, (0.2 ohm @ 2MHz, 0.1 ohm @ 7 MHz, 0.2 ohm at 20 MHz), several percent
changes won't skew a decade of good impedance.


Jim Granville wrote:

> John_H wrote:
> <snip>
> > The wide range of frequencies is, indeed, very important.  I had kept close to my
> > engineering heart the "truth" that more capacitance is most often a good thing, that low
> > capacitance values were silly.  If I throw together a dozen 1uF ceramic caps, I end up
> > with a nice low impedance at the SRF but not so very low a decade or two above or
> > below.  One graph I'm looking at shows an SRF of about 7MHz for a 1uF 1206.  The
> > impedance at 7MHz is about 0.1 Ohm each.  The impedance drops to 1ohm around 250kHz and
> > 150MHz.  While these values aren't bad, consider the current demands for 150MHz:  1/12
> > Ohm (12 1uF caps in parallel, ignoring other parasitics for the moment) will keep the
> > voltage tolerance within 100mV for 1.2A surges.
>
> Sudden load step-response is very important. The Pentium power supplies
> know all
> about this, and bigger FPGA ones should too.
>
> > Maybe this is sufficient, but one cap
> > with an SRF around 150MHz would give you performance nearly as good at 150MHz.
>
> Not sure you can move from load step, to this SRF comment - a load step
> cannot have
> a single-point 150Mhz spectrum  ?
>
> > The 7MHz
> > filtering in the 12 cap configuration above is probably significant overkill at 8.3
> > milliOhm.  A mix would allow a low overall impedance floor without overkill.
>
>  I think where SRF _can_ help, is not so much in total lowering, but in
> a
> 'focus on area of complaint' - eg a marine radio telephone user at
> 156MHz etc.
>
>  The tolerances and tempco's are such that the notch will move about a
> bit anyway...
>
> -jg


Article: 44210
Subject: Re: must signals to ram come from a register?
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Thu, 13 Jun 2002 16:37:06 -0700
Links: << >>  << T >>  << A >>
You can treat the BlockRAM inputs as if they were a register.
There is a clock edge, and you have to meet the set-up times for CE, WE,
Address, and Data (if write). That's all.
The enabled clock edge starts a sequence of actions, latches up the address,
then reads and if required writes data. But you only have to abide by the timing
requirements, i.e. the set-up times.

Viele Gruesse
Peter Alfke, Xilinx Applications
===================================
Holger Kleinegraeber wrote:

> Hello,
>
> when writing to ram (e.g. block ram in a virtex) must the signals to the ram
> come from a register? The timing diagrams I found implicate this (e.g.
> http://www.free-ip.com/ramlib/ram_dp.html ). The adress signal or the 'write
> enable' signal have a very short delay in my design. But the data word I
> want to store is the critical path and so arrives at the end of the clock
> period. Is this sufficient for the ram to sample the data?
>
> Kind regards,
>    Holger


Article: 44211
Subject: Re: must signals to ram come from a register?
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 13 Jun 2002 23:53:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D092CA2.60C1A024@xilinx.com>,
Peter Alfke  <Peter.Alfke@xilinx.com> wrote:
>You can treat the BlockRAM inputs as if they were a register.
>There is a clock edge, and you have to meet the set-up times for CE, WE,
>Address, and Data (if write). That's all.
>The enabled clock edge starts a sequence of actions, latches up the address,
>then reads and if required writes data. But you only have to abide by the timing
>requirements, i.e. the set-up times.

However, note that the set-up time can be considerable, especially for
the WE, so that if performance is a goal, having a register in front
of the BlockRAM may be useful, but it isn't manditory.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 44212
Subject: Re: MAP problem with RLOC'ed macros
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 14 Jun 2002 01:19:47 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> Aw man!   I'm still using mostly 7.03 because I have a couple projects that started before 7.1
> came out and I don't like switchin horses midstream.   I guess we now will have to put the syn
> keeps before the LUT (!!!).  That does get messy.  I'm still very annoyed that Synplify thinks
> that if it can figure out what is in a black box (by virtue of the black box happening to be a
> xilinx primitive) it has a right to muck with it.  As far as I am concerned, if it is a black
> box, it should not be mucked with PERIOD.  Of course the Synplicity response is that they don't
> see it as a real problem.  This is right up there with the tristate push through issue.  It
> completely wrecks the libraries I've put together over the past 3 years.  Guess I'll be
> spending time looking for a work-around once again :-(

Look like once again we have a good->v.good product being damaged by post-IPO arrogance ... or is
it just another symptom of the constant drift towards the ``push the big green button''  approach ?

I don't instantiate as much as you do but I absolutely concur that an instantiated black box
component should just be left alone, FULL STOP (US = PERIOD), no questions - its *my* decision to
do this *not* the tool's
If I have to instantiate then its because the tool, together with any syn directives/attributes, is
not getting me what I want from the RTL so the last thing I want is yet more messing about.

Instead of wasting time on this rubbish [and tri-state push through is even more ludicrous] why
can't Synplicity get the register replication stuff working as well it did for 5.x ?

In the sprirt of this thread I'd like to add a new directive:

syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse

or

syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone





Article: 44213
Subject: Re: Power supply caps on PCB
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 14 Jun 2002 12:32:24 +1200
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> The "notch" isn't a 20dB dip in a 1% bandwidth as notch filters would.  The SRF gives the
> bottom of a somewhat wide bottom.  My point is that - rather than paralleling a bunch of these
> "bathtubs" to get an overall "bathtub" curve so that the ends provide a low enough impedance -
> one should get the SRFs lined up across a wide enough coverage that the overall impedance
> floor is much wider at a target impedance.  A 10:1 impedance for the 1uF cap I mentioned is
> about 250kHz to 150 MHz.  If the minimum impedance on the chosen caps are low and the SRFs are
> distributed, the overall effect is greater wideband stiffness.
> 
> Load-step response is addressed by spreading the SRFs across a range of frequencies.  The
> clock has harmonics and the data tends to downspread, including those harmonics.  There's a
> time domain for the step and a frequency domain for the impedances that need to line up to
> each other.  The balance can be struck without "one 0.1uF and one 0.01uF cap per power/ground
> pin pair."
> 
> The single-point spectrum isn't my concern as much as "covering holes."  Make sure your
> impedance at all frequencies is low.  If the impedance could be improved across a frequency
> band that isn't stiff enough, add a cap that covers that hole.
> 
> The tolerances and tempcos will move the bottom around a little, but compared to the 2x bottom
> of around 2-20MHz, (0.2 ohm @ 2MHz, 0.1 ohm @ 7 MHz, 0.2 ohm at 20 MHz), several percent
> changes won't skew a decade of good impedance.

 Sounds right to me.
Anyone got any practical experience with SRF spread & deployment, on
real PCBs ?

 -jg

Article: 44214
Subject: new to fpga.
From: ananth12@rediffmail.com (Ananth)
Date: 13 Jun 2002 20:29:40 -0700
Links: << >>  << T >>  << A >>
Hi.

Im new to FPGA world. I must say I havent stepped in. But am very
interested. Ive access to some fpga material mostly data books of
Xilinx. Could you pls suggest where do I start learning the
programming.

thanks
ananth

Article: 44215
Subject: Re: new to fpga.
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 14 Jun 2002 03:47:28 GMT
Links: << >>  << T >>  << A >>


Ananth wrote:

> Hi.
>
> Im new to FPGA world. I must say I havent stepped in. But am very
> interested. Ive access to some fpga material mostly data books of
> Xilinx. Could you pls suggest where do I start learning the
> programming.
>
> thanks
> ananth

Ananth, welcome to the exciting world of programmable logic, where
you can create and change circuits almost without effort.
I would suggest that you first look at the FPGA architecture, i.e.
logic, flip-flops, and memory available on these chips.
Then you must come up with some idea what you want to implement.
Finally, you decide on a design methodology, schematic or High-Level
Language.
There are design kits available from various distributors and other
manufacturers.
Have fun!

Peter Alfke, Xilinx Applications



Article: 44216
Subject: Re: MAP problem with RLOC'ed macros
From: John_H <johnhandwork@mail.com>
Date: Fri, 14 Jun 2002 03:59:33 GMT
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:

> In the sprirt of this thread I'd like to add a new directive:
>
> syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse
>
> or
>
> syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone

Actually, that was my other call to the help line...

<quote>
Hello John,
 I am very sorry but I gave you some wrong info.  The attribute to prevent
the replication for speed is not syn_preserve, it is called syn_replicate.
This attribute can either be set globaly or on a specific register.
</quote>

The syn_replicate is supported starting in 7.1.  I haven't used it yet but it sounds like *just* the
thing I wanted.  The _fast replicants are one of my biggest sore spots making my synthesize at "50 MHz"
instead of "133 MHz" just to avoid that nonsense.


Article: 44217
Subject: Re: MAP problem with RLOC'ed macros
From: Ray Andraka <ray@andraka.com>
Date: Fri, 14 Jun 2002 04:06:41 GMT
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

>
> In the sprirt of this thread I'd like to add a new directive:
>
> syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse
>
> or
>
> syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone...

...and_if_it_is_an_instantiated_ff_then_don't_replicate_it_either



--
--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: 44218
Subject: Re: MAP problem with RLOC'ed macros
From: Ray Andraka <ray@andraka.com>
Date: Fri, 14 Jun 2002 04:08:30 GMT
Links: << >>  << T >>  << A >>


John_H wrote:

> Rick Filipkiewicz wrote:
>
> > In the sprirt of this thread I'd like to add a new directive:
> >
> > syn_dont_buffer_signals_or_replicate_luts_since_it_always_makes_things_worse
> >
> > or
> >
> > syn_if_you_cant_reduce_fanout_by_replicating_ffs_then_leave_the_net_alone
>
> Actually, that was my other call to the help line...
>
> <quote>
> Hello John,
>  I am very sorry but I gave you some wrong info.  The attribute to prevent
> the replication for speed is not syn_preserve, it is called syn_replicate.
> This attribute can either be set globaly or on a specific register.
> </quote>
>
> The syn_replicate is supported starting in 7.1.  I haven't used it yet but it sounds like *just* the
> thing I wanted.  The _fast replicants are one of my biggest sore spots making my synthesize at "50 MHz"
> instead of "133 MHz" just to avoid that nonsense.

Ayup,  I often set the target speed to ZERO to keep it from doing that nonsense...of course that kills any
RTL stuff that has more than 4 inputs.


--
--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: 44219
Subject: Re: 20,000 gates?
From: samg@codenet.net
Date: Fri, 14 Jun 2002 04:49:38 GMT
Links: << >>  << T >>  << A >>
Asked an Application engineer today and he mentioned that there is
about 5-1 ratio between custom ASICs and the Xilinx basic FPGA.
So I guess a 20K Xilinx part would actually be a 4K custom ASIC in
size.  I tend to think in the ASIC sizes so the rule is good for
estimation. 
From our latest work in verifying our DSP IP for FPGAs I would
say that he is pretty close if your synthesizer doesn't use some of
the newer blocks like the multipliers in the new Virtex 2 line.
If your synthesizer maps to these new blocks then that ratio can
improve a bit.

Sam Gladstone
Digital Design Engineer
Acculent Corporation
samg@acculentdsp.com


On Fri, 14 Jun 2002 09:01:22 +1000, "Tony Burch" <tony@burched.com.au>
wrote:

>BurchED now sells a low cost board
>based on the XC2S300E.
>http://www.burched.com.au/B5Spartan2.html
>Excellent value at US$190.
>
>Best regards
>Tony Burch
>http://www.BurchED.com
>Low cost FPGA boards, for System-On-Chip
>prototyping and education
>
>"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
>news:aeao2h$5bfsh$1@ID-84877.news.dfncis.de...
>> "Roger King" <roger@king.com> schrieb im Newsbeitrag
>> news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com...
>> > I don't have the info, but what about the XC2S50 chip/family?
>>
>> XC2S50 is a Spartan-II, 50k gates (whatever gates means  . .;-)
>>
>> It has also 6 BlockRams, 4kbit each.
>>
>> > and is that a good number?
>>
>> XC2S50 is a nice chip to start with. But as others already said, go for a
>> 200K or 300K gates device, they cost not much more (together with a
>> demoboad).
>> Also remember, the bigger the device, the cheaper the logic funktions
>> ($/LUT), with some minor exceptions.
>>
>> --
>> MfG
>> Falk
>>
>>
>>
>>
>
>


Article: 44220
Subject: Re: 20,000 gates?
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 14 Jun 2002 04:58:40 GMT
Links: << >>  << T >>  << A >>
Gate count is known to be a meaningless measure of FPGA capability.
Take the simple case of a Xilinx look-up table.
Xilinx counts it as about 6 gates ( 12 gates together with the associated
flip-flop).

The user might see it as a single gate, or, at the other extreme, as a 16-bit
shift register, in which case it is worth at least sixty ASIC gates.
Anything with an uncertainty range from 1 to 60 is a lousy measuring stick.

And how do you count clock management, carry, I/O flexibility etc ?
Five-to-one? Just give up, and realize that it's futile!

Peter Alfke, Xilinx Applications
=================
samg@codenet.net wrote:

> Asked an Application engineer today and he mentioned that there is
> about 5-1 ratio between custom ASICs and the Xilinx basic FPGA.
> So I guess a 20K Xilinx part would actually be a 4K custom ASIC in
> size.  I tend to think in the ASIC sizes so the rule is good for
> estimation.
> From our latest work in verifying our DSP IP for FPGAs I would
> say that he is pretty close if your synthesizer doesn't use some of
> the newer blocks like the multipliers in the new Virtex 2 line.
> If your synthesizer maps to these new blocks then that ratio can
> improve a bit.
>
> Sam Gladstone
> Digital Design Engineer
> Acculent Corporation
> samg@acculentdsp.com
>
> On Fri, 14 Jun 2002 09:01:22 +1000, "Tony Burch" <tony@burched.com.au>
> wrote:
>
> >BurchED now sells a low cost board
> >based on the XC2S300E.
> >http://www.burched.com.au/B5Spartan2.html
> >Excellent value at US$190.
> >
> >Best regards
> >Tony Burch
> >http://www.BurchED.com
> >Low cost FPGA boards, for System-On-Chip
> >prototyping and education
> >
> >"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
> >news:aeao2h$5bfsh$1@ID-84877.news.dfncis.de...
> >> "Roger King" <roger@king.com> schrieb im Newsbeitrag
> >> news:lRvN8.287033$t8_.195817@news01.bloor.is.net.cable.rogers.com...
> >> > I don't have the info, but what about the XC2S50 chip/family?
> >>
> >> XC2S50 is a Spartan-II, 50k gates (whatever gates means  . .;-)
> >>
> >> It has also 6 BlockRams, 4kbit each.
> >>
> >> > and is that a good number?
> >>
> >> XC2S50 is a nice chip to start with. But as others already said, go for a
> >> 200K or 300K gates device, they cost not much more (together with a
> >> demoboad).
> >> Also remember, the bigger the device, the cheaper the logic funktions
> >> ($/LUT), with some minor exceptions.
> >>
> >> --
> >> MfG
> >> Falk
> >>
> >>
> >>
> >>
> >
> >


Article: 44221
Subject: Re: Xilinx primitives & ModelSim
From: David R Brooks <daveb@iinet.net.au>
Date: Fri, 14 Jun 2002 13:07:43 +0800
Links: << >>  << T >>  << A >>
On Thu, 13 Jun 2002 11:28:09 GMT, in comp.arch.fpga, Allan Herriman
and Ray Andraka wrote:


[snip]
:
:3.  Set the generic TimingChecksOn to FALSE when you instantiate the
:FD.  You will need to put in pragmas to stop the synthesiser from
:seeing the generics:
:
:ff : FD
:  -- synopsys translate_off
:  generic map (
:      TimingChecksOn =3D> FALSE
:  )
:  -- synopsys translate_on
:  port map (
:    ....


Hmm, I try that, & get "undefined identifier TimingChecksOn" messages.
This seems to imply that TimingChecksOn is not a generic of FD. Have I
missed something? (I am using the standard mapping of UNISIM).


Also, is it possible to get the timing checks turned off when running
VSIM from the GUI, or is it only possible from the command line? (I
see no parameter in MODELSIM.INI that would control it.)


TIA

Article: 44222
Subject: I am a novice at FPGA.Please take care of me.THX!
From: arena_yang@hotmail.com (Arena.Yang)
Date: 13 Jun 2002 23:05:51 -0700
Links: << >>  << T >>  << A >>
Hi,Everybody!
   I am a novice at FPGA design,but I am very interested in it.
   I have completed a multiplexer design based on FPGA,and I feel I am
so poor at the FPGA and its relative technologies such as:system
plan,simulation,verification, etc.
   So welcome anyone interested in FPGA and Me(^_^) contact with me.

Article: 44223
Subject: Re: Altera APEX reconfigurates endlessly
From: "Michael J." <michajo@gmx.de>
Date: Fri, 14 Jun 2002 08:21:42 +0200
Links: << >>  << T >>  << A >>
Thank you Mike and Ben,

nCONFIG wasn't connected propperly.
Now it works !!

Michael



Article: 44224
Subject: Re: Power supply caps on PCB
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 14 Jun 2002 08:58:42 +0100
Links: << >>  << T >>  << A >>
Jim Granville <jim.granville@designtools.co.nz> writes:

> Anyone got any practical experience with SRF spread & deployment, on
> real PCBs ?
> 

My last design (2 Altera 10KE100s and a TI C6711 amongst other things)
has a power distribution system designed in just such a way as to keep
the imppedance flattish and beneath a target impedance (as suggested
in
http://groups.yahoo.com/group/si-list/files/Signal%20Integrity%20Documents/Published%20SI%20Papers%20from%20Sun/cpmt_1999.pdf
 - apologies for a the long link!)

Seems to work well, although I haven;t had chance to get any actual
numbers from it - other than the noise on the various power planes (as
viewed on a Tek LogiScope @ up to 2Gs/sec) is much less than the 5%
tolerance.

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt



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