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 103300

Article: 103300
Subject: Re: generating IP cores
From: "Antti" <Antti.Lukats@xilant.com>
Date: 30 May 2006 12:21:01 -0700
Links: << >>  << T >>  << A >>
there is (almost) no standard for IP core generators (SPIRIT is only
used by Actel so far)

in ISE 5.1 it was possible to add custom IP cores to coregen but in
later version this functionality is no longer available :(

Antti


Article: 103301
Subject: Running Xilinx and Altera Tools on Fedora Core 5
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Tue, 30 May 2006 15:37:21 -0400
Links: << >>  << T >>  << A >>
Both Xilinx and Altera make the assumption that their tools are being run
on a ridiculously obsolete versions of Linux. The Quartus tools test to
see if they are running on Redhat 8, if not they set the LD_ASSUME_KERNEL
to 2.4. At one point the Xilinx tools had a requirement that you set the
LD_ASSUME_KERNEL to 2.4.7. This didn't cause any problems in earlier
version of Fedora Core but it does in FC5. If you set the LD_ASSUME_KERNEL
to 2.4 it breaks everything, see below

setenv LD_ASSUME_KERNEL 2.4
ls
ls: error while loading shared libraries: librt.so.1: wrong ELF class:
ELFCLASS32

The good news is that it appears that it's no longer necessary to set the
LD_ASSUME_KERNEL for either tool. Both ISE 8.1sp3 and Quartus 6.0 seem to
work without it. 

Xilinx assumed that the user was setting the LD_ASSUME_KERNEL variable so
those of you who use scripts or set it in their .cshrc should remove it.

Altera put it in one of their own scripts, $QUARTUS/adb/qenv.csh. In
order to run Quartus on FC5 you should comment out the line,

		if ( "$REDHAT_VERSION" != "8" ) then
#			setenv LD_ASSUME_KERNEL 2.4
		endif


Article: 103302
Subject: Re: Aurora sample design: Testing/Eye Diagrams
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 30 May 2006 12:42:39 -0700
Links: << >>  << T >>  << A >>
billu wrote:
> Hi All,
> 
> I have the following issues while trying to test a sample Aurora core.
> I generated a core w/ the following specs:
> HDL: Verilog, Lane: 1, Lane Width: 2, Interface: Streaming, Upper MGT
> Clock: BREF_CLK, Upper MGT clock on GT_X0Y1 (from ucf file, corresponds
> to MGT4 for a ML321 board)
> 
> After using xilperl to compile the design files, I simulated it using
> Modelsim, and uploaded the bit file using Impact to the board.
> 
> I'm trying to test the core by feeding a 3.125Gbps (default data rate
> based on onboard oscillator) PRBS signal onto MGT4(RXP & RXN). I test
> the output signal from MGT4(TXP & TXN) by connecting it(TX ports)to a
> oscilloscope and/or spectrum analyzer. Ideally, you would expect the
> protocol to simply transmit that data that it received at the RX ports,
> but the protocol fails to do that. I get an extremely weak signal on
> the spectrum analyzer and bad eye on the scope. I also tried feeding in
> a clock signal of 50MHz into BREF_CLK and testing the setup w/ 1Gbps
> PRBS signal, but that didnt work either.
> 
> Can you tell me where I might be going wrong?
> 
> Thanks,
> Billu
> 

For starters the Aurora core implements the Aurora Protocol so feeding
the receiver a raw PRBS pattern is seen as garbage as it doesn't match
the protocol.

You didn't mention what other logic you wrapped around the core to
source and sink the Local Link TX/RX interfaces.  If you left these
unconnected in your design, then it's likely that almost everything
has been trimmed.

However you are getting something out of the TX pair so the bitstream
is doing something (probably constantly sending the initialization
portion of the protocol since it never gets a receiver lock). Since
you are getting a bad eye on the scope I would suggest checking your
scopes termination setting and set them to 50 ohm with AC coupling.

You are using the ML321 and these boards are shipped with pre-compiled
BERT designs on the SystemACE CompactFlash card. Have you tried just
using these designs for your initial testing?

Ed McGettigan
--
Xilinx Inc.

Article: 103303
Subject: Re: Running Xilinx and Altera Tools on Fedora Core 5
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Tue, 30 May 2006 15:51:55 -0400
Links: << >>  << T >>  << A >>
> 
> Altera put it in one of their own scripts, $QUARTUS/adb/qenv.csh. In
> order to run Quartus on FC5 you should comment out the line,
> 
> 		if ( "$REDHAT_VERSION" != "8" ) then
> #			setenv LD_ASSUME_KERNEL 2.4
> 		endif


I spoke to soon about Quartus, it doesn't work without the
LD_ASSUME_KERNEL 2.4 variable. The Xilinx tools seem to run fine.


Article: 103304
Subject: Re: IOB IO Standards in Spartan 3
From: "Antti" <Antti.Lukats@xilant.com>
Date: 30 May 2006 13:09:08 -0700
Links: << >>  << T >>  << A >>
the bitstream contains some parameters that are optimized for given
VCCIO standard. the actual VCCIO is supplied externally so settng
iostandard to 1.8V and VCCIO to 3.3 will output 3.3V levels. This will
not burn the FPGA but some parameters will not be optimal, etc..


Article: 103305
Subject: Re: generating IP cores
From: Ben Jackson <ben@ben.com>
Date: Tue, 30 May 2006 16:52:44 -0500
Links: << >>  << T >>  << A >>
On 2006-05-30, Antti <Antti.Lukats@xilant.com> wrote:
> a <= b or c;
>
> the above as example is an IP core, in the matter of fact I have sold
> such a IP core !

I might owe you some royalties.  In the future I will use

a <= ~(~b and ~c);

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Article: 103306
Subject: Re: Mains pick-up on I/O pins
From: Ben Jackson <ben@ben.com>
Date: Tue, 30 May 2006 16:57:24 -0500
Links: << >>  << T >>  << A >>
On 2006-05-30, m_oylulan@hotmail.com <m_oylulan@hotmail.com> wrote:
> Hello,
> I am trying to program an RC-100 demo board, which contains a
> Spartan-II chip. The board is supposed to send three logic outputs to
> external devices through I/O pins provided on an expansion header.

Did you actually set constraints to put the outputs of your top level
module on the specific IO pins you want?

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Article: 103307
Subject: Re: Virtex 5 announced and sampling ... and real!
From: "Love Singhal" <lovesinghal@gmail.com>
Date: 30 May 2006 15:31:25 -0700
Links: << >>  << T >>  << A >>
Hi Austin,
I have some questions about the static power in Virtex 5. You said that
the gate leakage is same for V4 and V5. Could you tell me how is the
sub-threshold leakage in Virtex 5? I have read that subthreshold
leakage will increase at 65nm (distance between source and drain of
transistor will decrease in 65nm). Also, Virtex 5 has lower effective
voltage than Virtex 4 (1.2 V in V4 to 1.0 V in V5). This should
increase the sub-threshold leakage (Vth would be more significant).
Moreover, if we take same sized Virtex 4 and Virtex 5 (which I assume
to mean as  same number of CLBs), then number of gates in Virtex 5
would be higher than Virtex 4, which means more leakage.

I am trying to find out how the static power could be saved in going
from 90nm to 65nm. Did Xilinx do something new to prevent sub-threshold
leakage?
Thanks,
Love Singhal


Article: 103308
Subject: PCI Design
From: "water7" <krbyxtrm@gmail.com>
Date: 30 May 2006 15:53:32 -0700
Links: << >>  << T >>  << A >>
hi, what is the difference for designing a PCI card for a desktop
motherboard and with a Single Board Computer(SBC)? should a PCI card
designed for Desktop PC work on SBC's?

-k-


Article: 103309
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 30 May 2006 15:59:53 -0700
Links: << >>  << T >>  << A >>
Love Singhai,

What we are seeing is that the choice of using triple oxide at 65nm is
again, a requirement.

To have 65nm low Vt (very leaky source drain, leaky gate), 65nm high Vt
(less leaky source drain, just as leaky gate); medium oxide 90nm low Vt
(less leaky source drain, very little leakage gate), medium oxide high
Vt (even less leaky source-drain, very little gate leakage -- these are
used for all config memory, and all pass-gates); and finally both low
and high Vt thick oxide for IO (no leakage at all to speak of) provides
the IC designer with the best choices where they are needed.

So, because we must use the low Vt 65nm and high Vt 65nm transistors for
speed to achieve objectives, we end up with more static leakage for V5
than we would for V4.

By "more" I mean that for the same number of CLBs, we still are seeing
less, but with 65nm, we are doubling the logic per square area, so the
same area chip now sees a similar static current, which now varies much
less over temperature as the gate leakage has no temperature dependency.

As an example, if a V4 chip is taken down to -40C (I grade, of course),
it has practically no leakage at all!

But, take a V5 of the same area, and take it down to -40C, and the
leakage is roughly the same as when it was at room temperature.  At hot,
it is more, but on par with a V4 when it was hot.

V4 was at 1.2V, V5 is at 1.0 volts (core), so the lower voltage on the
core does help keep the leakage under control.

So, in summary, what Xilinx did was specify a triple oxide process to
two foundries that allows designers to use the right transistor for the
right job.  The result is the worlds first 65nm FPGA which still
provides for an overall static savings in power for function, and keeps
on par with static power per area.

Dynamic power is 1.2 squared vs. 1.0 squared for voltage alone (3-0%
less dynamic power) PLUS the use of low K for another ~ 5% less power
(smaller C).  The final dynamic power savings will be characterized and
released with the new power estimation tools, as not all features have
lo-K (for example, clock lines are near the top metal layers, which are
not low-K).

I hope that answers your questions,

Austin

Love Singhal wrote:
> Hi Austin,
> I have some questions about the static power in Virtex 5. You said that
> the gate leakage is same for V4 and V5. Could you tell me how is the
> sub-threshold leakage in Virtex 5? I have read that subthreshold
> leakage will increase at 65nm (distance between source and drain of
> transistor will decrease in 65nm). Also, Virtex 5 has lower effective
> voltage than Virtex 4 (1.2 V in V4 to 1.0 V in V5). This should
> increase the sub-threshold leakage (Vth would be more significant).
> Moreover, if we take same sized Virtex 4 and Virtex 5 (which I assume
> to mean as  same number of CLBs), then number of gates in Virtex 5
> would be higher than Virtex 4, which means more leakage.
> 
> I am trying to find out how the static power could be saved in going
> from 90nm to 65nm. Did Xilinx do something new to prevent sub-threshold
> leakage?
> Thanks,
> Love Singhal
> 

Article: 103310
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 30 May 2006 16:01:48 -0700
Links: << >>  << T >>  << A >>
30% less dynamic power from voltage, excuse the typo...

Austin

Austin Lesea wrote:
> Love Singhai,
> 
> What we are seeing is that the choice of using triple oxide at 65nm is
> again, a requirement.
> 
> To have 65nm low Vt (very leaky source drain, leaky gate), 65nm high Vt
> (less leaky source drain, just as leaky gate); medium oxide 90nm low Vt
> (less leaky source drain, very little leakage gate), medium oxide high
> Vt (even less leaky source-drain, very little gate leakage -- these are
> used for all config memory, and all pass-gates); and finally both low
> and high Vt thick oxide for IO (no leakage at all to speak of) provides
> the IC designer with the best choices where they are needed.
> 
> So, because we must use the low Vt 65nm and high Vt 65nm transistors for
> speed to achieve objectives, we end up with more static leakage for V5
> than we would for V4.
> 
> By "more" I mean that for the same number of CLBs, we still are seeing
> less, but with 65nm, we are doubling the logic per square area, so the
> same area chip now sees a similar static current, which now varies much
> less over temperature as the gate leakage has no temperature dependency.
> 
> As an example, if a V4 chip is taken down to -40C (I grade, of course),
> it has practically no leakage at all!
> 
> But, take a V5 of the same area, and take it down to -40C, and the
> leakage is roughly the same as when it was at room temperature.  At hot,
> it is more, but on par with a V4 when it was hot.
> 
> V4 was at 1.2V, V5 is at 1.0 volts (core), so the lower voltage on the
> core does help keep the leakage under control.
> 
> So, in summary, what Xilinx did was specify a triple oxide process to
> two foundries that allows designers to use the right transistor for the
> right job.  The result is the worlds first 65nm FPGA which still
> provides for an overall static savings in power for function, and keeps
> on par with static power per area.
> 
> Dynamic power is 1.2 squared vs. 1.0 squared for voltage alone (3-0%
> less dynamic power) PLUS the use of low K for another ~ 5% less power
> (smaller C).  The final dynamic power savings will be characterized and
> released with the new power estimation tools, as not all features have
> lo-K (for example, clock lines are near the top metal layers, which are
> not low-K).
> 
> I hope that answers your questions,
> 
> Austin
> 
> Love Singhal wrote:
>> Hi Austin,
>> I have some questions about the static power in Virtex 5. You said that
>> the gate leakage is same for V4 and V5. Could you tell me how is the
>> sub-threshold leakage in Virtex 5? I have read that subthreshold
>> leakage will increase at 65nm (distance between source and drain of
>> transistor will decrease in 65nm). Also, Virtex 5 has lower effective
>> voltage than Virtex 4 (1.2 V in V4 to 1.0 V in V5). This should
>> increase the sub-threshold leakage (Vth would be more significant).
>> Moreover, if we take same sized Virtex 4 and Virtex 5 (which I assume
>> to mean as  same number of CLBs), then number of gates in Virtex 5
>> would be higher than Virtex 4, which means more leakage.
>>
>> I am trying to find out how the static power could be saved in going
>> from 90nm to 65nm. Did Xilinx do something new to prevent sub-threshold
>> leakage?
>> Thanks,
>> Love Singhal
>>

Article: 103311
Subject: Need help reattaching top to FPGA
From: "mike_la_jolla" <mdini@dinigroup.com>
Date: 30 May 2006 16:06:42 -0700
Links: << >>  << T >>  << A >>
We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to
reattach it. The board and FPGA work fine.  For some reason, Xilinx is
refusing to tell us how to reattach the top correctly.  Help please.
What is the proper type of glue and the procedure?


Article: 103312
Subject: PLB transfers: PPC to IP
From: "Joseph" <joeylrios@gmail.com>
Date: 30 May 2006 16:56:11 -0700
Links: << >>  << T >>  << A >>
I have a piece of IP that acts as a slave on the PLB.  I would like
writes to this IP to be 64bits, while reads from it are OK at 32bits.
The sample driver that was generated by the IP wizard gives functions
for reads/writes or 32 bits as expected (by mapping them to
XIo_In/Out32).  Do I need to do writes in two transfers?  If not, how
do I write 64bits?   I've looked over the PPC 405 Block Reference Guide
and it seems that it should be possible to read/write 64 bits all at
once just by virtue of having that wide of a bus coming in and out of
the block.  The cacheline transfers are discussed in that document as
possibly being doublewords. I am a bit confused by all of this (if that
wasn't clear already).  I would probably be able to find my answer
after a good deal of time/pain, but hopefully someone out there can
clarify things a little for me.  Just knowing if it was possible or not
for a user program to do the 64bit write would help me move forward.

I'd appreciate any clarification and/or pointers to relevant
documentation.  I can provide more info about my design or my confusion
if it is useful.

Thanks in advance,
Joey


Article: 103313
Subject: Re: Running Xilinx and Altera Tools on Fedora Core 5
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 31 May 2006 00:03:52 GMT
Links: << >>  << T >>  << A >>
Josh Rosen <bjrosen@polybuspleasedontspamme.com> wrote:
>Both Xilinx and Altera make the assumption that their tools are being run
>on a ridiculously obsolete versions of Linux. The Quartus tools test to
>see if they are running on Redhat 8, if not they set the LD_ASSUME_KERNEL
>to 2.4. At one point the Xilinx tools had a requirement that you set the
>LD_ASSUME_KERNEL to 2.4.7. This didn't cause any problems in earlier
>version of Fedora Core but it does in FC5. If you set the LD_ASSUME_KERNEL
>to 2.4 it breaks everything, see below

The Xilinx tools works fine in respect to this with Linux ELF-32 translated
api under FreeBSD 6.x/i386. Infact the older software makes bugs to have been
ironed out in this particular case.
What works bad is tool integration and driver for hardware. .bit files have
to be downloaded by a seperatly written tool.
Installation precedure is horrible.


Article: 103314
Subject: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: "Mr. Ken" <Mr. Ken@asdf>
Date: Wed, 31 May 2006 09:04:57 +0800
Links: << >>  << T >>  << A >>
My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
best precision possible. Without considering clipping and range issues, I
am using multiplication by 59/16, which gives 0.599% error. What better
approach can I use?

I am going to implement the calculation in ASIC, thus less complexity is
what I am expecting.






Article: 103315
Subject: Re: Virtex 5 announced and sampling ... and real!
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 31 May 2006 13:15:12 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Love Singhai,
> 
> What we are seeing is that the choice of using triple oxide at 65nm is
> again, a requirement.
> 
> To have 65nm low Vt (very leaky source drain, leaky gate), 65nm high Vt
> (less leaky source drain, just as leaky gate); medium oxide 90nm low Vt
> (less leaky source drain, very little leakage gate), medium oxide high
> Vt (even less leaky source-drain, very little gate leakage -- these are
> used for all config memory, and all pass-gates); and finally both low
> and high Vt thick oxide for IO (no leakage at all to speak of) provides
> the IC designer with the best choices where they are needed.
> 
> So, because we must use the low Vt 65nm and high Vt 65nm transistors for
> speed to achieve objectives, we end up with more static leakage for V5
> than we would for V4.
> 
> By "more" I mean that for the same number of CLBs, we still are seeing
> less, but with 65nm, we are doubling the logic per square area, so the
> same area chip now sees a similar static current, which now varies much
> less over temperature as the gate leakage has no temperature dependency.
> 
> As an example, if a V4 chip is taken down to -40C (I grade, of course),
> it has practically no leakage at all!
> 
> But, take a V5 of the same area, and take it down to -40C, and the
> leakage is roughly the same as when it was at room temperature.  At hot,
> it is more, but on par with a V4 when it was hot.
> 
> V4 was at 1.2V, V5 is at 1.0 volts (core), so the lower voltage on the
> core does help keep the leakage under control.
> 
> So, in summary, what Xilinx did was specify a triple oxide process to
> two foundries that allows designers to use the right transistor for the
> right job.  The result is the worlds first 65nm FPGA which still
> provides for an overall static savings in power for function, and keeps
> on par with static power per area.
> 
> Dynamic power is 1.2 squared vs. 1.0 squared for voltage alone (3-0%
> less dynamic power) PLUS the use of low K for another ~ 5% less power
> (smaller C).  The final dynamic power savings will be characterized and
> released with the new power estimation tools, as not all features have
> lo-K (for example, clock lines are near the top metal layers, which are
> not low-K).
> 
> I hope that answers your questions,

  Some real/actual  numbers could be a good idea, as all the info 
released so far seems to skirt this issue very deliberately....

-jg


Article: 103316
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 May 2006 19:00:16 -0700
Links: << >>  << T >>  << A >>
I assume your scaling factor is a constant, and your data is variable.
Now we need to know the available time for one conversion and also the
data rate (which can be significantly higher in a pipelined scheme).
In the digital realm, anything and everything is possible, if there is
enough time...
Peter Alfke, Xilinx
=========================
Mr. Ken wrote:
> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
>
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.


Article: 103317
Subject: Re: Need help reattaching top to FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 30 May 2006 19:34:54 -0700
Links: << >>  << T >>  << A >>
Mike,

That is because there is no known way to re-attach it.

If it fell off because we did something wrong (quality, assembly fault, 
etc.), request to RMA the part, and we will replace it under warranty.

If you removed the top, then you have violated any warranty, and you 
need to get another one.

Sorry, but that is the simple truth.

"All the King's horses, and all the King's men, couldn't put Humpty 
Dumpty together again..."

The lid is a heatsink, and detaching it may have (usually does) damaged 
the die, and certainly can not be replaced such that Xilinx is able to 
stand behind it.  We don't do it ourselves.  We don't ask anyone else to.

I hope you can appreciate this,

Austin


mike_la_jolla wrote:

> We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to
> reattach it. The board and FPGA work fine.  For some reason, Xilinx is
> refusing to tell us how to reattach the top correctly.  Help please.
> What is the proper type of glue and the procedure?
> 

Article: 103318
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: John_H <johnhandwork@mail.com>
Date: Wed, 31 May 2006 03:40:16 GMT
Links: << >>  << T >>  << A >>
Mr. Ken wrote:
> My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> best precision possible. Without considering clipping and range issues, I
> am using multiplication by 59/16, which gives 0.599% error. What better
> approach can I use?
> 
> I am going to implement the calculation in ASIC, thus less complexity is
> what I am expecting.

Use more bits.  If you were looking at simple shift for the division 
you're on the right track but you need more digits such as 3799/10241.

If ASICs have dedicated multipliers as a simple element, you probably 
have what you need with a multiplier.

If you have loads of time, a bit-serial approach can give you tiny.

If you want abstruse, you can do a 115/31 where the divide by 31 is a 
bunch of 5-bit adds and a few conditionals around the digit 31 (and a 
bit of latency).

Where do you want to go?

Article: 103319
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: John_H <johnhandwork@mail.com>
Date: Tue, 30 May 2006 20:40:39 -0700
Links: << >>  << T >>  << A >>

Article: 103320
Subject: Re: Need help reattaching top to FPGA
From: "Bob" <nimby1_NEEDSPAM@earthlink.net>
Date: Wed, 31 May 2006 03:50:36 GMT
Links: << >>  << T >>  << A >>

"mike_la_jolla" <mdini@dinigroup.com> wrote in message 
news:1149030402.633190.15550@u72g2000cwu.googlegroups.com...
> We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to
> reattach it. The board and FPGA work fine.  For some reason, Xilinx is
> refusing to tell us how to reattach the top correctly.  Help please.
> What is the proper type of glue and the procedure?
>

Mike,

It's really no big deal. Apply a dab of silicon grease (or equivalent) to 
the top of the die, but be very careful as this chunk of silicon cracks very 
easily. Apply some epoxy (or similar -- like E6000) along the top edge of 
the plastic case (that surrounds the little pcb and die). Now, just replace 
the little metal lid (the heat spreader) that popped off.

Bob 



Article: 103321
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: "Mr. Ken" <Mr. Ken@asdf>
Date: Wed, 31 May 2006 12:55:53 +0800
Links: << >>  << T >>  << A >>
Well, within a same clock cycle. I am unable to have pipelining at the
moment.
Anyway, pipelined divider will become an option in later stage of my
assignment.





"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1149040816.140172.179410@i39g2000cwa.googlegroups.com...
> I assume your scaling factor is a constant, and your data is variable.
> Now we need to know the available time for one conversion and also the
> data rate (which can be significantly higher in a pipelined scheme).
> In the digital realm, anything and everything is possible, if there is
> enough time...
> Peter Alfke, Xilinx
> =========================
> Mr. Ken wrote:
> > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> > best precision possible. Without considering clipping and range issues,
I
> > am using multiplication by 59/16, which gives 0.599% error. What better
> > approach can I use?
> >
> > I am going to implement the calculation in ASIC, thus less complexity is
> > what I am expecting.
>



Article: 103322
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: "Mr. Ken" <Mr. Ken@asdf>
Date: Wed, 31 May 2006 12:57:58 +0800
Links: << >>  << T >>  << A >>

"John_H" <johnhandwork@mail.com> wrote in message
news:Ae8fg.9896$ho6.9329@trnddc07...
> Mr. Ken wrote:
> > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
> > best precision possible. Without considering clipping and range issues,
I
> > am using multiplication by 59/16, which gives 0.599% error. What better
> > approach can I use?
> >
> > I am going to implement the calculation in ASIC, thus less complexity is
> > what I am expecting.
>
> Use more bits.  If you were looking at simple shift for the division
> you're on the right track but you need more digits such as 3799/10241.
>
> If ASICs have dedicated multipliers as a simple element, you probably
> have what you need with a multiplier.
>
> If you have loads of time, a bit-serial approach can give you tiny.
>
> If you want abstruse, you can do a 115/31 where the divide by 31 is a
> bunch of 5-bit adds and a few conditionals around the digit 31 (and a
> bit of latency).
>
> Where do you want to go?


Thank you John_H. the 115/31 idea is interesting. I will make one and see
how much
resource it consumes. If resource consumption is fine, it will be greatly
increase the
precision of my design!





Article: 103323
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 31 May 2006 17:31:20 +1200
Links: << >>  << T >>  << A >>
John_H wrote:
> Mr. Ken wrote:
> 
>>My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
>>best precision possible. Without considering clipping and range issues, I
>>am using multiplication by 59/16, which gives 0.599% error. What better
>>approach can I use?
>>
>>I am going to implement the calculation in ASIC, thus less complexity is
>>what I am expecting.
> 
> 
> Use more bits.  If you were looking at simple shift for the division 
> you're on the right track but you need more digits such as 3799/10241.

Wow, somehow this spawned ~100 posts, in 2 minutes....

Yes, but if the data starts life as 9 bits, then that's one part in 512,
or 0.2% (2 e-3), so superb precison is not needed ?

I make 475/128 a deviation of 3.33e-4, from the humber above, and
so appx 1/7 the data quantize error ?

-jg


Article: 103324
Subject: Re: How do I scale a 9-b signed 2's complement data by 17/sqrt(21)?
From: Zara <yozara@terra.es>
Date: Wed, 31 May 2006 08:23:58 +0200
Links: << >>  << T >>  << A >>
On Wed, 31 May 2006 09:04:57 +0800, "Mr. Ken" <Mr. Ken@asdf> wrote:

>My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the
>best precision possible. Without considering clipping and range issues, I
>am using multiplication by 59/16, which gives 0.599% error. What better
>approach can I use?
>
>I am going to implement the calculation in ASIC, thus less complexity is
>what I am expecting.
>

5316/1433
Error=0.0001133%



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