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 85300

Article: 85300
Subject: Re: VirtexII:DCM:CLKFX phase delay
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Tue, 7 Jun 2005 14:48:50 -0400
Links: << >>  << T >>  << A >>
i think this is a VARIABLE parameter, and it's a function of fractional 
frequency synthesis M/N,
temperature, input jitter ,etc...


"al82" <yscdi62k001@sneakemail.com> wrote in message 
news:1118146996.993258.79830@g43g2000cwa.googlegroups.com...
> Can anyone tell me which is the phase delay between input and
> output(CLKFX) when there is no feedback (Input frequency less than
> 24MHz)
>
> Thanks
> 



Article: 85301
Subject: Re: Clock doubler to double an input 13.5 Mhz
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Tue, 7 Jun 2005 14:52:45 -0400
Links: << >>  << T >>  << A >>
There are two ways to do this:

(1) Use DCM with CLKFX output, DO NOT USE DLL outputs, as they limit you to 
24 MHz.
(2) There is a nice circuit which doubles any frequency using a delay buffer 
+ XOR.

If you REALLY want to go for it (it's working, but ...), just say it.
Hope this helps.

Vladislav

"methi" <gmethi@gmail.com> wrote in message 
news:1118085861.383732.169030@g14g2000cwa.googlegroups.com...
> Hi,
>
> I need to double an input clk of 13.5mhz to 27 mhz...but the DCM core
> in xilinx can take frequencies from 24 Mhz and up only...
>
> On going through some of the posts, this is the idea that I have come
> across:
>
> Give my input clk to one input of the XOR gate.
>
> Delay my input clk with a series of inverters and give it as the second
> input of the XOR gate..
>
> Would this work?
>
> Thank you,
>
> Methi
> 



Article: 85302
Subject: Re: faster Spartan III adder
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 7 Jun 2005 20:58:44 +0200
Links: << >>  << T >>  << A >>
"Paul Smith" <ptsmith@nospam.indiana.edu> schrieb im Newsbeitrag
news:d84q4e$uga$1@rainier.uits.indiana.edu...
> Hi,
>
> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
>
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and
> RPM on, the best cycle time I can get is 4.55 ns.  At each pipeline
> level the critical path is a LUT, a MUXCY, and another LUT.
>
> Can anyone point me at some hints for a faster implementation (besides
> going to a faster part?
>
> TIA
>
> Paul Smith
> Indiana University Physics

solution (one possibility) is simple

do it 2 times in parallel and demux the output results back into one stream
then the addition works on 125MHz and the demux should be single LUT so it
works on 250 without problems

:)
antti3cents



Article: 85303
Subject: Re: FPGA/CPLD trend
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Tue, 7 Jun 2005 14:59:13 -0400
Links: << >>  << T >>  << A >>
as simple as this:

ALWAYS use Verilog/VHDL

NEVER use schematic capture

those who come from ASIC/FPGA world would probably agree.

but honestly, the only place where you might use schematic capture would be 
a small,
very well defined project with knowing that the flexible design & fast 
design time is not an issue.

yet the speed of the design process + its integrability with some other 
people like me,
who really hate schematic capture, because the warnings generated during 
synthesis are annoying and i most cases cannot be avoided.

Vladislav


<learnfpga@gmail.com> wrote in message 
news:1118084694.279439.98850@g43g2000cwa.googlegroups.com...
>I had a question about the latest happening in this market. Since I am
> new in this area excuse me in advance if the question sounds
> stupid.(:-. What is trend for programming devices now a days. I mean
> are people using VHDL/Verilog more and more for design or they use
> design tools such as Orcad etc. What is better off the two. What are
> the pro/cons of using VHDL/Verilog in comparision to schematic capture.
> Thanks
> 



Article: 85304
Subject: Re: Pissed off with Xilinx - Spartan 3
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Tue, 07 Jun 2005 12:01:16 -0700
Links: << >>  << T >>  << A >>
On Mon, 06 Jun 2005 10:01:02 -0700, Fred wrote:

> 14 week lead time for samples for the XC3S200.  How can you prototype
> with that?
> 
> It makes worry even more when it comes to manufacture where I might need
> quantity.
 
If you want to pay shipping I've got 4 XC3S400-PQ208 engineering samples
(ony minor bugs should not affect most applications) You can have for
just cost of shipping. These are pin compatible with the XC3S200 so
should work on your proto

Peter Wallace

Article: 85305
Subject: Re: faster Spartan III adder
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Tue, 7 Jun 2005 15:07:21 -0400
Links: << >>  << T >>  << A >>
(1) try using timing driven packing and placement, it might help.
(2) if you can pipeline the result, i.e. just add one more sample, this 
would solve a problem.
but try using high level code, but core generator.
(3) split the addition into two parallel ones at 1/2 frequency, and 
multiplex them at full frequency

take also a look how much % of the delay is contributed by routing :o(

Hope this helps

Vladislav

"Paul Smith" <ptsmith@nospam.indiana.edu> wrote in message 
news:d84q4e$uga$1@rainier.uits.indiana.edu...
> Hi,
>
> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit 
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
>
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and RPM 
> on, the best cycle time I can get is 4.55 ns.  At each pipeline level the 
> critical path is a LUT, a MUXCY, and another LUT.
>
> Can anyone point me at some hints for a faster implementation (besides 
> going to a faster part?
>
> TIA
>
> Paul Smith
> Indiana University Physics 



Article: 85306
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: "johnp" <johnp3+nospam@probo.com>
Date: 7 Jun 2005 12:17:21 -0700
Links: << >>  << T >>  << A >>
The seminar was a nice follow-up to the previous one and I thought was
well done.  I'd like to see a future seminar dealing in more detail
with board layout issues  that affect signal integrity.

John Providenza


Article: 85307
Subject: Re: faster Spartan III adder
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 07 Jun 2005 19:21:58 GMT
Links: << >>  << T >>  << A >>
The trouble is probably your second LUT.  The first LUT feeds the S input of
the carry chain, yes?  This would be the LUT attached directly to the carry
chain.  The second LUT means - for reasons unknown to us - the result is
going through additional logic.  It's this logic that needs to be tweaked a
little.

Since it didn't pass through an XORCY I'm guessing this is the carry-out of
the 8-bit adder?  Look at what else feeds the LUT and try to determine why
the synthesizer wants to add logic to the adder's OUTPUT rather than in the
4-input LUT.


"Paul Smith" <ptsmith@nospam.indiana.edu> wrote in message
news:d84q4e$uga$1@rainier.uits.indiana.edu...
> Hi,
>
> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
>
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and
> RPM on, the best cycle time I can get is 4.55 ns.  At each pipeline
> level the critical path is a LUT, a MUXCY, and another LUT.
>
> Can anyone point me at some hints for a faster implementation (besides
> going to a faster part?
>
> TIA
>
> Paul Smith
> Indiana University Physics



Article: 85308
Subject: Re: Placing variables at a specific location (address) using microblaze GCC
From: "JW" <jweese@senstarstellar.com>
Date: 7 Jun 2005 12:40:13 -0700
Links: << >>  << T >>  << A >>
Thank you for your reply, I did finally find this information.


Article: 85309
Subject: Anonymous structs in Microblaze C compiler
From: "JW" <jweese@senstarstellar.com>
Date: 7 Jun 2005 12:43:29 -0700
Links: << >>  << T >>  << A >>
I am trying to figure out what version of GCC the mb -gcc is based on.
This will tell me if I can use anonymous structures with the Microblaze
compiler.

Any ideas?

JW


Article: 85310
Subject: Re: Lattice and Mentor seminar info pieces... & ST's new 'uC'+FPGA
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 08 Jun 2005 07:46:09 +1200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> Hi
> 
> some info from the Lattice roadshow seminar at Mentor
> 
> 1) 0.9 and 0.65 !? products are coming...

You mean 90nm and 65nm ?

> 2) new FPGA products to be exptected (when you are back from sommer
> vaccation..) that goes for new FPGA products (not low end), not just some
> new device/derivate of existing things
> 3) something new is coming to the PLD offering as well (same timeline as
> above?)

No hints on pin counts and resource ?
[A MAXII ~clone with RAM would be nice :) ]

> 4) serdes 2.5G+ will be included in some of the new devices
> 5) Lattice has completly solved the NBTI (and other submicron) issues (as
> much as I understood it means all the V4 NBTI like issues, things why xilinx
> is not shipping V4 silicon with working MGTs and why Stratix IIGX is
> delayed) are solved

Fujitsu are the ones who would do the solving, not Lattice, and I would
suspect anyone's "completely solved" claim, until proven by time...

> 6) EC family pricing can meed the S3 pricing in all cases where xilinx is
> not dumping on the high volumes
> 7) ECP and XP prices are EC+10%
> 
> please dont take those above as some official announcements, its only the
> answers I got ;) and possible my interpretation what may not be entirely
> accurate

On the topic of news, ST have their second member roll out on this family :

http://www.st.com/stonline/press/news/year2005/p1613h.htm
&
http://www.st.com/stonline/books/pdf/docs/11335.pdf

With a claimed 'volume' price of ~$30, and the raw MIPS performance and 
resources, it has the potential to shake the FPGA tree.

Similar in concept to the uPSD, [uC.ADC.PLD.Memory] but monstered up
with 300MHz ARM9, 600MHz Dual MAX DSP, 200MHZ FPGA, & OnChip DRAM,
plus peripherals FPGA users can only dream about.
They still call this a MicroController :)

Success will depend on the device errata, how solid the tools are, and 
their ability to ship - [as other FPGA vendors are finding...?]

-jg



Article: 85311
Subject: Re: Sch & Layout Free Program
From: "Mat Nieuwenhoven" <mnieuw@dontincludethis.zap.a2000.nl>
Date: Tue, 07 Jun 2005 21:47:59 +0200 (CEST)
Links: << >>  << T >>  << A >>
On 6 Jun 2005 13:26:56 -0700, Eric wrote:

>What is the best FREE Schematic & PCB Layout software available that
>will run on Windoze XP?
>
>I've looked at PCB123.com and Expresspcb.com and they have pretty good
>programs available. Unfortunately if I use either one I'm stuck getting
>the prototypes through them. (Because they won't output Gerbers)
>
>I've also looked at Eagle Layout at cadsoft.de, but the size limitation
>of 100 x 80mm on the free version is a negative. It would work for my
>current project.
>
>I'm just curious at what other people's opinions are.

I'm quite happy with Eagle (also on Linux). Don't underestimate the value of
a big component library and how important it is that you can create your own
components easily. For non-profit, there's a non-free but cheap version of
Eagle which will do full eurocard format (100x160). Eagle is also extensible
my user programs, there is such an 'ULP' to export to spice for simulation by
e.g. SwitchCadIII (I've never tried that though).

Mat Nieuwenhoven




Article: 85312
Subject: Re: Lattice and Mentor seminar info pieces... & ST's new 'uC'+FPGA
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 7 Jun 2005 21:57:02 +0200
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag
news:42a5f953$1@clear.net.nz...
> Antti Lukats wrote:
> > Hi
> >
> > some info from the Lattice roadshow seminar at Mentor
> >
> > 1) 0.9 and 0.65 !? products are coming...
>
> You mean 90nm and 65nm ?
yes

> > 2) new FPGA products to be exptected (when you are back from sommer
> > vaccation..) that goes for new FPGA products (not low end), not just
some
> > new device/derivate of existing things
> > 3) something new is coming to the PLD offering as well (same timeline as
> > above?)
>
> No hints on pin counts and resource ?

no, but I think they have also recognized that CSP and QFN packages are
nice, but no info if/when products in CSP will be available

> [A MAXII ~clone with RAM would be nice :) ]

not sure, what it will be, but yes Lattice thinks as well that missing ram
in MAX2 is a BIG MISTAKE, almost as big as having the RAM not initializeable
in PA3 !

> > 4) serdes 2.5G+ will be included in some of the new devices
> > 5) Lattice has completly solved the NBTI (and other submicron) issues
(as
> > much as I understood it means all the V4 NBTI like issues, things why
xilinx
> > is not shipping V4 silicon with working MGTs and why Stratix IIGX is
> > delayed) are solved
>
> Fujitsu are the ones who would do the solving, not Lattice, and I would
> suspect anyone's "completely solved" claim, until proven by time...

sure actually that what they meant, that F has solved the issues, eg
whatever issues they think there are

> > 6) EC family pricing can meed the S3 pricing in all cases where xilinx
is
> > not dumping on the high volumes
> > 7) ECP and XP prices are EC+10%
> >
> > please dont take those above as some official announcements, its only
the
> > answers I got ;) and possible my interpretation what may not be entirely
> > accurate
>
> On the topic of news, ST have their second member roll out on this family
:
>
> http://www.st.com/stonline/press/news/year2005/p1613h.htm
> &
> http://www.st.com/stonline/books/pdf/docs/11335.pdf
>
> With a claimed 'volume' price of ~$30, and the raw MIPS performance and
> resources, it has the potential to shake the FPGA tree.
>
> Similar in concept to the uPSD, [uC.ADC.PLD.Memory] but monstered up
> with 300MHz ARM9, 600MHz Dual MAX DSP, 200MHZ FPGA, & OnChip DRAM,
> plus peripherals FPGA users can only dream about.
> They still call this a MicroController :)
>
> Success will depend on the device errata, how solid the tools are, and
> their ability to ship - [as other FPGA vendors are finding...?]
>
> -jg
>

WAU!! I want that starterkit NOW !!

1MS/S ADC!, real DAC and hei they even have POR detect on that chip, I would
not have even dreamed of that in such monster, the small things are usually
forgotten

Antti










Article: 85313
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 7 Jun 2005 13:55:23 -0700
Links: << >>  << T >>  << A >>
John,
Indeed, layout is important. Like put the ground plane as close as possible
to the BGA rather than on the otherside of the board to make the Altera
parts look unusable. Don't get me wrong, the Xilinx BGA pin layout is
superior to the Altera one in terms of SI. However, by using a more
realistic stackup, I would suggest the problems are not as pronounced as in
today's demo.
Also, in the original demo,
http://www.xilinx.com/products/virtex4/pdfs/BGA_Crosstalk.pdf , I would
question whether the PCB was laid out optimally, or in such a way as to
accentuate the problem. Long and adjacent traces far from a ground plane
would do this. There's no picture of the stackup or layout in the demo
document.
>From the first demo, the conclusion is :-

The Altera package suffers from two issues:

  1.. . Excessively fast signal rise/fall time


  2.. . Over-concentration of power/ground balls in core region
I'd argue that 1) isn't a problem; fast rise time is good, as long as you
know what you're doing. (BTW Xilinx can't compete on risetime because of
their 12.5pF pin capacitance.) Now, 2) could be a SI problem, for which the
Xilinx package is a solution, but I question whether the data presented are
a realistic 'real world' set up. If they are, no-one would be able to drive
DDR ram from an Altera part. On the other hand, 2) could be better in terms
of signal routing, the traces from the centre of the Altera package don't
have to negotiate a lot of power and ground vias as they fan out from the
device.
In conclusion, I think the Xilinx BGA layout is a good thing. Well done.
But, I don't believe the Altera parts have to be as bad as they appear in
these demos. And, for differential signals, for which the Altera parts are
much better (see above comment about pin capacitance), the BGA layout makes
bugger all difference.
Cheers, Syms.

p.s. Thanks to Xilinx for these seminars; it shows the subject is being
taken seriously.

"johnp" <johnp3+nospam@probo.com> wrote in message
news:1118171841.280608.167380@o13g2000cwo.googlegroups.com...
> The seminar was a nice follow-up to the previous one and I thought was
> well done.  I'd like to see a future seminar dealing in more detail
> with board layout issues  that affect signal integrity.
>
> John Providenza
>



Article: 85314
Subject: Re: Fast/low area Sorting hardware.
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 7 Jun 2005 23:04:02 +0200
Links: << >>  << T >>  << A >>
"c d saunter" <christopher.saunter@durham.ac.uk> schrieb im Newsbeitrag
news:d84pvd$5pu$1@heffalump.dur.ac.uk...

> Bubble sort should actually be quite fast - you can store all 48 values in
> registers, then compare and swap if necessary odd pairs on odd clock
cycles
> and even pairs on even cycles.   After 48 cycles the registers should hold
> a sorted data set.

This sounds like a almost full parallel approach. Could be quite fast, but
also quite resouce hungry.

> Probably this aproach is about as fast as you can get?  The speedup comes
> from the fact that many many bubble sort opperations can occour in
> parallel.  Is this the most hardware efficient sort that runs at this
speed
> though?
>
> If possible data should be shifted sequentially into and out of (or at
least
> out of) the registers as a readout mux would be a resource hog.  Using a

Thats why a BRAM is quite handy. Using both ports you can pull two datas out
in one cycle, compare, and write them back on a second cycle.

Regards
Falk






Article: 85315
Subject: Re: FPGA I/O pin current sink
From: "Berty" <wooster.berty@gmail.com>
Date: 7 Jun 2005 14:16:05 -0700
Links: << >>  << T >>  << A >>
Better use external transistor / Fet as multiple pin can get all burned
due to the fact that they do not open and close at the same exact
moment and the first to open theoretically will need to drive for some
period the total current and this get repeated over and over until ...

Of course if the current ramp slow enough multiple IO can be solution
though myself I would stick with one IO and transistor / Fet.

Have fun


Article: 85316
Subject: Re: FPGA I/O pin current sink
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 7 Jun 2005 14:25:49 -0700
Links: << >>  << T >>  << A >>
Nah, I think the I/Os are safe even if they're shorted to ground or Vcco.
Use the IOB FFs to be on the safe side!
Cheers, Syms.
"Berty" <wooster.berty@gmail.com> wrote in message
news:1118178964.986594.252320@f14g2000cwb.googlegroups.com...
> Better use external transistor / Fet as multiple pin can get all burned
> due to the fact that they do not open and close at the same exact
> moment and the first to open theoretically will need to drive for some
> period the total current and this get repeated over and over until ...
>
> Of course if the current ramp slow enough multiple IO can be solution
> though myself I would stick with one IO and transistor / Fet.
>
> Have fun
>



Article: 85317
Subject: Re: ISE/EDK 6.3 vs 7.1...
From: Paulo Dutra <paulo.dutra@NOSPAM.com>
Date: Tue, 07 Jun 2005 14:32:01 -0700
Links: << >>  << T >>  << A >>
This maybe an issue with the constraints listed in the UCF file.

iSE 7.1 incorrectly interprets "NET-PERIOD" constraints when
applied to designs assembled from multiple NGC files. Unfortunate,
as this is the design assembly method of EDK.

If you have a UCF constraint of the following format:

NET sys_clk PERIOD = 10 ns;

Replace with the following

TIMESPEC "TS_sys_clk" = PERIOD "sys_clk_grp" 10 ns;
NET sys_clk TNM_NET=sys_clk_grp;


Also, you may want to also change the effort level of "-ol std"
to "-ol high". This can be modified in the <proj>/etc/fast_runtime.opt


Big Boy wrote:
> I tried both ISE/EDK 7.1 and 6.3 (all with latest service pack, but
> tested very quicly), and I'm having some problems with 7.1.  For
> example, a Microblaze design that fit in 6.3 doesn't fit as tight in
> 7.1.  Moreover, I'm using Spartan-3 (FG456, speed: -4) with 66.6MHz
> clock, and I can't meet the timing requirement in 7.1, while 6.3 meet
> it.  Moreover, for the same design, 6.3 give 6 level of logic in the
> critical path, while 7.1 give 9 levels.
> 
> Also, with 7.1, when doing synthesis, I get a lot of warnings, like
> 'Packer: ... can not be packed with the carry due to conflict ...'. 
> Some other warnings too.  With 6.3, no such warnings.
> 
> I'm currently testing on a workstation with 6.3, and I'll verify if
> some of the other issues I was having are there or not.
> 
> Anyone having bad experience with 7.1?
> 


-- 
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ `  Xilinx                              hotline@xilinx.com
/ /    2100 Logic Drive                    http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA


Article: 85318
Subject: Re: faster Spartan III adder
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 7 Jun 2005 23:48:59 +0200
Links: << >>  << T >>  << A >>

"Paul Smith" <ptsmith@nospam.indiana.edu> schrieb im Newsbeitrag
news:d84q4e$uga$1@rainier.uits.indiana.edu...

> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
>
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and
> RPM on, the best cycle time I can get is 4.55 ns.  At each pipeline
> level the critical path is a LUT, a MUXCY, and another LUT.

Hmm, strange. a 8 bit adder should fit into one level of logic. make sure
both inputs are registered and placed correctly (close to the carry chain).
The output should be registerd too, of course ;-)

OK, I did a quick test using Webpack 7.1.

A plain description reaches 3.995 ns, uhhh tight timing ;-)
Looking at the floorplanner (after P&R) I see the mess.The registers for my
inputs are placed inside the IOBs. Not bad in general, but bad here, where
we need every fraction of a ns. So I disable the option for placing the
registers into the IOBs and run again.
BINGO! 3.5ns.

But the automatic P&R tools are lazy bastards. A look at the floorplanner
reveals, that the input registers are spread over the chip. OK, handmade is
handmade. We add some LOCs into the UCF. New run.
3.49 ns. Hmm, not too much improvement, but since the placement is fixed
this should be reliable.
See the files below.

Njoy.
Falk


-- VHDL

----------------------------------------------------------------------------
----
-- Company:
-- Engineer:
--
-- Create Date:    23:08:28 06/07/05
-- Design Name:
-- Module Name:    top_adder - Behavioral
-- Project Name:
-- Target Device:
-- Tool versions:
-- Description:
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------
----
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity top_adder is
    Port ( clk : in std_logic;
           a : in std_logic_vector(7 downto 0);
           b : in std_logic_vector(7 downto 0);
           c : out std_logic_vector(8 downto 0));
end top_adder;

architecture Behavioral of top_adder is

signal a_int, b_int : std_logic_vector(7 downto 0);
signal c_int : std_logic_vector(8 downto 0);

begin

process(clk)
begin

  if rising_edge(clk) then
    a_int <= a;
    b_int <= b;
    c <= c_int;
    c_int <= ('0' & a_int) + ('0' &  b_int);
  end if;

end process;

end Behavioral;


-- UCF

net clk period=3.5ns;

INST "c_int_0"       LOC = "SLICE_X14Y4";
INST "c_int_1"       LOC = "SLICE_X14Y4";
INST "c_int_2"       LOC = "SLICE_X14Y5";
INST "c_int_3"       LOC = "SLICE_X14Y5";
INST "c_int_4"       LOC = "SLICE_X14Y6";
INST "c_int_5"       LOC = "SLICE_X14Y6";
INST "c_int_6"       LOC = "SLICE_X14Y7";
INST "c_int_7"       LOC = "SLICE_X14Y7";
INST "c_int_8"       LOC = "SLICE_X14Y8";

INST "a_int_0"       LOC = "SLICE_X13Y4";
INST "a_int_1"       LOC = "SLICE_X13Y4";
INST "a_int_2"       LOC = "SLICE_X13Y5";
INST "a_int_3"       LOC = "SLICE_X13Y5";
INST "a_int_4"       LOC = "SLICE_X13Y6";
INST "a_int_5"       LOC = "SLICE_X13Y6";
INST "a_int_6"       LOC = "SLICE_X13Y7";
INST "a_int_7"       LOC = "SLICE_X13Y7";

INST "b_int_0"       LOC = "SLICE_X15Y4";
INST "b_int_1"       LOC = "SLICE_X15Y4";
INST "b_int_2"       LOC = "SLICE_X15Y5";
INST "b_int_3"       LOC = "SLICE_X15Y5";
INST "b_int_4"       LOC = "SLICE_X15Y6";
INST "b_int_5"       LOC = "SLICE_X15Y6";
INST "b_int_6"       LOC = "SLICE_X15Y7";
INST "b_int_7"       LOC = "SLICE_X15Y7";








Article: 85319
Subject: Re: Fast/low area Sorting hardware.
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Tue, 7 Jun 2005 22:13:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Falk Brunner (Falk.Brunner@gmx.de) wrote:
: "c d saunter" <christopher.saunter@durham.ac.uk> schrieb im Newsbeitrag
: news:d84pvd$5pu$1@heffalump.dur.ac.uk...

: > Bubble sort should actually be quite fast - you can store all 48 values in
: > registers, then compare and swap if necessary odd pairs on odd clock
: cycles
: > and even pairs on even cycles.   After 48 cycles the registers should hold
: > a sorted data set.

: This sounds like a almost full parallel approach. Could be quite fast, but
: also quite resouce hungry.

Yup.  Unless the OP posts some details about desired performance it's impossible
to know which one is best...

: Thats why a BRAM is quite handy. Using both ports you can pull two datas out
: in one cycle, compare, and write them back on a second cycle.

Indeed.  There is a nice intermediate level of parallelism availible by using 
LUT RAMs to build units 16 words deep, each of which sort sequentially, with
every other set of sorts crossing the LUT RAM boundaries.  This would also be
the most complicated case to code :-)

cheers
cds

Article: 85320
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 08 Jun 2005 10:28:36 +1200
Links: << >>  << T >>  << A >>
Symon wrote:
> John,
> Indeed, layout is important. Like put the ground plane as close as possible
> to the BGA rather than on the otherside of the board to make the Altera
> parts look unusable. Don't get me wrong, the Xilinx BGA pin layout is
> superior to the Altera one in terms of SI. However, by using a more
> realistic stackup, I would suggest the problems are not as pronounced as in
> today's demo.
> Also, in the original demo,
> http://www.xilinx.com/products/virtex4/pdfs/BGA_Crosstalk.pdf , I would
> question whether the PCB was laid out optimally, or in such a way as to
> accentuate the problem. Long and adjacent traces far from a ground plane
> would do this. There's no picture of the stackup or layout in the demo
> document.

NOR any detail of the DIE bonding. The total path is what matters.

Are these Xilinx devices flip-chip / direct bonded ?

If so, they should clarify which other xilinx devices are not....

> From the first demo, the conclusion is :-
> 
> The Altera package suffers from two issues:
> 
>   1.. . Excessively fast signal rise/fall time

For dI/dT, yes, but slower rise times make poorer eye diagrams...

> 
>   2.. . Over-concentration of power/ground balls in core region
> I'd argue that 1) isn't a problem; fast rise time is good, as long as you
> know what you're doing. (BTW Xilinx can't compete on risetime because of
> their 12.5pF pin capacitance.) Now, 2) could be a SI problem, for which the
> Xilinx package is a solution, but I question whether the data presented are
> a realistic 'real world' set up. If they are, no-one would be able to drive
> DDR ram from an Altera part.

  Most logic interfaces do not try and clock at the same time as the 
address bus changes, so cross talk becomes mission-serious only onto the
write line - and if you are silly enough to choose a WRN strobe, right
on the most noisy pin, then you rather deserve to get bitten....

  That said, there are other more analog situations where low system 
noise is a very good thing, and EMC tests would have been interesting.


> On the other hand, 2) could be better in terms
> of signal routing, the traces from the centre of the Altera package don't
> have to negotiate a lot of power and ground vias as they fan out from the
> device.
> In conclusion, I think the Xilinx BGA layout is a good thing. Well done.
> But, I don't believe the Altera parts have to be as bad as they appear in
> these demos. 

  Probably not in the real world....
The pdf says min 7" traces, and 500 aggressors - and I've never seen
a real design come close to either number...

  Still, it is an educational test, and good to see simulations and 
physical correlations.


  Comment: The inductive nature of the cross talk, suggests some 
controlled capacitive crosstalk could actually help counteract/null this

Has anyone actually tried that ?

-jg


Article: 85321
Subject: Re: Pissed off with Xilinx - Spartan 3
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 08 Jun 2005 11:16:24 +1200
Links: << >>  << T >>  << A >>
Fred wrote:

> Thanks for your offer but I need the pins.
> 
> Xilinx have their buy online store but they only sell CPLDs there.  A reply 
> to an email I sent to "online store" said talk to your distributor and sales 
> office which are things I had already done.  I have searched in vain but 
> can't get any hint of sourcing samples off their website.  Do you have any 
> links?

Try mentioning this link, might hurry them along a bit...

http://www.altera.com/buy/devices/buy-devices.html

Xilinx only have CPLDs here :

http://www.xilinx.com/xlnx/xebiz/onlinestore.jsp?sGlobalNavPick=PURCHASE

and then, they do not have the new 32A and 64A, nor the MLF packages....

I did notice this line in the XC2C64 ?! listings

XC3S200-4FT256C  	 FT  	 -4  	 256  	 Commercial  	 $25.55 In Stock

-jg



Article: 85322
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: "Peter Alfke" <peter@xilinx.com>
Date: 7 Jun 2005 16:16:41 -0700
Links: << >>  << T >>  << A >>
Jim, we described Virtex-4, which is 100% flip-chip.
This was not a history lesson on the older families, nor on TQ144
packages  :-(
Peter Alfke


Article: 85323
Subject: Re: Anonymous structs in Microblaze C compiler
From: "Zolee" <zoltan_csizmadia@yahoo.com>
Date: 7 Jun 2005 16:31:03 -0700
Links: << >>  << T >>  << A >>
mb-gcc --version -> 2.95.3-4 Xilinx EDK 6.3
Yes, it supports anonym structs.

Zolee


Article: 85324
Subject: Re: Great Tutorial on Signal Integrity, SSOs, Ground Bounce etc
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 07 Jun 2005 23:33:18 GMT
Links: << >>  << T >>  << A >>

This was a good, useful presentation, particularly the discussion on
the utility of "soft grounds."

But it did make me wonder this: with all of the concern about
crosstalk, how many designers take the time to separate groups of
mutually asynchronous signals when assigning the FPGA pinout?  Most of
us don't have the luxury of running everything at the same clock
speed, and yet I've seen little or no mention of how beneficial it is
to separate signals that run at different speeds.  Maybe this idea is
buried in the docs somewhere, but I've yet to see a single
presentation from any vendor that suggests this.

Perhaps this gets little play because it's obvious.  But given the
number of designs I've seen with I/O signals placed anywhere they'll
fit, I think otherwise.

Bob Perlman
Cambrian Design Works




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