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 110300

Article: 110300
Subject: Re: multithreaded Synthesis and Place and route... Finally!
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Fri, 13 Oct 2006 16:56:27 +0200
Links: << >>  << T >>  << A >>
I hoped, after reading the headline and the first sentence, that we get it 
in 6.1... Look like we have to wait another year...

BTW: Regarding best CPU, I think that cache-size matters.

Thomas

"wallge" <wallge@gmail.com> schrieb im Newsbeitrag 
news:1160750978.838935.193430@b28g2000cwb.googlegroups.com...
> So I asked Altera when they would release a version of Quartus that
> would support multi-threaded
> place and route (this takes the most time on the designs I have worked
> on)
> I also asked them about the best (fastest) PC to run quartus on.
> here's my questions followed by their answers.
> -------------------------------------------------------------------------------------------------------------
> Q:
> at the end of year I am thinking of purchasing a new PC to do my
> quartus
> and EDA development on. I was wondering how the system requirements
> will change with the release of vista, and what the ideal system
> configuration for
> running fast synthesis and place and route will be. Right now I am
> having to wait between
> 15 minutes and two hours for various designs to compile. What system
> components will most contribute to faster place and route and synthesis
> (eg, more ram, more processors, faster ram, faster processors, 32 vs 64
> bit
> architecture?,  any specific CPU more highly rated then others?)
>
> A:
> Altera does not have recommendations for CPUs/Mother Board. About the
> choice for AMD or Intel processor, Altera does not have testcases to
> show one way or another.
>
> However, the compile time is mostly related to CPU speed and physical
> memory size. For detailed information on memory requirements for
> compilation targeting different device architectures, please refer to
> the readme file by clicking Quartus II menu "Help -> Readme File".
>
> If system memory is enough and Quartus II don't use hard disk as
> virtual memory, you could try to upgrade your CPU speed for good
> performance. However, if memory is not enough and hard disk virtual
> memory is frequently used, the compilation time will increase more.
> Therefore, I think we could firstly satisfy the physical memory
> requirement of Quartus II compilation and then try to upgrade CPU
> speed.
>
> Multi processor system or multi-thread CPU will help you run other
> applications at the same time as running the Quartus II compile, but
> not necessarily will help with the compile time.
>
> Quartus II can support 64 bit system. Generally, 64 bit Quartus II can
> run faster than 32 bit if memory is adequately large (> 2G). However,
> the performance upgrade is dependent on specific design project and we
> can't provide detailed benchmark.
>
> 64-bit Quartus II version 6.0 can be installed in UNIX Workstations
> (64-bit) (Solaris 8 and 9 only) or Linux Workstations (64-bit
> AMD64/EM64T processors) (Red Hat Enterprise Linux 3.0/4.0 WS 64-bit for
> AMD64/EM64T only).
> -------------------------------------------------------------------------------------------------------------------
> Q:
> when will quartus be certified as being windows vista compatible, and
> is a 64 bit windows/vista version planned?
>
> secondly, with the rise of multicore and multiprocessor systems,
> is work being done to parallelize the algorithms for synthesis and
> place and
> route in order to achieve speed benefits available through
> multiprocessor systems as they become the norm in the PC market.
>
> A:
> I can't provide the exact schedule about Quartus II certification on
> Windows Vista. It's also due to the maturity of the OS. However,
> Altera software surely can support those operations systems if they are
> popular.
>
> Our roadmap for Quartus II software also includes multi thread or
> multiprocessor system support. However, the release schedule is also
> not determined by now. But it might be no later than the end of next
> year. Thanks for your understanding.
> --------------------------------------------------------------------------------------------------------------------------
> 



Article: 110301
Subject: Re: Are you ready for Virtex-5? We are...
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Oct 2006 08:41:35 -0700
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:

> Just to clarify the situation:
> Antti had ordered the evaluation board for Virtex-5, and Xilinx has
> acknowledged and I suppose has shipped the order on Sept 27.
> Now let's see how soon it reaches Antti in Munich, Germany,
> (Antti please report to the newsgroup when it arrives.
> It should not take weeks, the airplane hasn't that much fuel!)
> Also, the present version of EDK already supports that board (with
> minor wrinkles).
> Let's then listen to the continuation of this story...
> Peter
> ======================
I have ML501 on the desk here!

a


Article: 110302
Subject: Re: New Electronic Design Web site
From: ElectronicDesignNet <webmaster@ElectronicDesignNet.com>
Date: Fri, 13 Oct 2006 11:50:04 -0400
Links: << >>  << T >>  << A >>
Hi Jacko,

We have a list of engineering consulting companies that might be 
helpful.  It's here:

http://www.electronicdesignnet.com/cms/component/option,com_ebg/Itemid,92
/task,cos/eid,21312.19328.19442/

You do need to register to get their contact info from 
ElectronicDesignNet, or alternatively you could just Google for their 
web site.

Although they appear under the "Test & Measurement" category, I believe 
that some of them are more general.

Let me know if that's at all helpful.  If not, I may be able to come up 
with some other ideas.

Best,
Patrick
Webmaster, http://www.ElectronicDesignNet.com

Article: 110303
Subject: Re: Are you ready for Virtex-5? We are...
From: "Peter Alfke" <peter@xilinx.com>
Date: 13 Oct 2006 08:54:02 -0700
Links: << >>  << T >>  << A >>
On Oct 13 (Friday the thirteenth) Antti reports that he has the ML501
board on his desk in Munich.
That makes it just a bit over 2 weeks after placing the order. Not bad!
Peter Alfke
======================================
Peter Alfke wrote:
> Just to clarify the situation:
> Antti had ordered the evaluation board for Virtex-5, and Xilinx has
> acknowledged and I suppose has shipped the order on Sept 27.
> Now let's see how soon it reaches Antti in Munich, Germany,
> (Antti please report to the newsgroup when it arrives.
> It should not take weeks, the airplane hasn't that much fuel!)
> Also, the present version of EDK already supports that board (with
> minor wrinkles).
> Let's then listen to the continuation of this story...
> Peter
> ======================
> Antti wrote:
> > Antti schrieb:
> >
> > > Peter Alfke schrieb:
> > >
> > > > You can order Virtex-5 devices from your distributor now, and he will
> > > > offer short delivery times.
> > > [...]
> > > > Peter Alfke, who has been working on and with these parts for over a
> > > > year.
> > >
> > [my own ***** snipped]
> > > until both the silicon AND tools are available there is no supprort.
> > > So no matter how ready we may be for Virtex-5, and belive me some
> > > of us really are - we are not really able todo any real work until
> > > tools support is also made available by Xilinx.
> > >
> >
> > EDK 8.1 SP1 has Virtex-5 MicroBlaze 5.00.a and 5.00.b in it
> > it is just labelled as "early access" but its readily available.
> > there is some minor mess with MPD files like FSL bus is not
> > supported (eg requires manual edit of the MPD) but otherwise
> > the Virtex-5 can be targetted ok on EDK 8.1 SP1, eg no need
> > to wait for SP2
> >
> > here is the picture of the EDK system with Virtex-5
> >
> > http://www.microfpga.com/joomla/index.php?page=shop.browse&category_id=12&option=com_virtuemart&Itemid=26
> > 
> > Antti


Article: 110304
Subject: Re: Virtex-5 LXT orderable?
From: "Peter Alfke" <peter@xilinx.com>
Date: 13 Oct 2006 08:56:44 -0700
Links: << >>  << T >>  << A >>
Nobody would make a major product announcement on Friday the
thirteenth... ;-)
Peter Alfke
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
GaLaKtIkUs=99 wrote:
> Most onnounces are made by Xilinx on monday, perhaps next monday?
>
> Antti wrote:
> > Antti schrieb:
> >
> > > http://www.sierraic.com/pnresults.asp?part=3DXC5VLX50T1FF1136CES
> > >
> > > there is status "available" - and full order code as well !
> > >
> > > surprisingly Xilinx website doesnt even list device codes for V5LX(T)
> > > devices yet.
> > >
> > > to what I understand all T parts (LXT, SXT and FXT) have 4 TEMACs and=
 1
> > > PCIe MAC
> > >
> > > Antti
> >
> > !? virtex-5 LXT PCIe has passed PCISIG compliance testing as well !!
> > see here
> >
> > http://www.pcisig.com/developers/compliance_program/integrators_list/pc=
ie/
> >
> > so I assume the parts are actually obtainable already?
> >=20
> > Antti


Article: 110305
Subject: Re: Are you ready for Virtex-5? We are...
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Oct 2006 08:57:30 -0700
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:

> On Oct 13 (Friday the thirteenth) Antti reports that he has the ML501
> board on his desk in Munich.
> That makes it just a bit over 2 weeks after placing the order. Not bad!
> Peter Alfke
> ======================================
Peter,

the order wasnt placed immediatly so that the actual delivery
time was below 2 weeks actually.

Antti
PS but ML505 is still not orderable or is it?


Article: 110306
Subject: Re: Virtex-5 LXT orderable?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Oct 2006 09:00:32 -0700
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:

> Nobody would make a major product announcement on Friday the
> thirteenth... ;-)
> Peter Alfke
> ========================

ROTFL, sure !

only Virtex-5 boards may arrive in some countries where the post still
works ;)

Antti


Article: 110307
Subject: Xilinx FPGAs in battery-powered scenarios
From: "Manny" <mloulah@hotmail.com>
Date: 13 Oct 2006 09:06:34 -0700
Links: << >>  << T >>  << A >>
Hey,

I've been reluctant recently on envisaging a Virtex-4 device as being
operational in a battery-powered situation. The inrush configuration
current, high static power consumption, and the non-uniform power
exhibited subject to temperature rise are amongst few to name about the
shortcomings of SRAM FPGAs in general. Having said that, the
unprecedented versatile reconfigurable processing power is yet the
decisive factor in prototyping intensive DSP operations. My question
is: has any body come across a scenario in which a large FPGA was
battery-powered. I'm in the phase of deciding on solutions to employ
for my active research so it's quite critical. I don't want to start my
research with a major gap in my rationale. Can any veteran in here
comment on the topic please. Is it really ridiculous to think about
powering a large SRAM FPGA from a battery? Would really appreciate all
comments. What's the cheapest price ever a smallest Virtex-4 device was
reported?

Cheers,
-Manny


Article: 110308
Subject: DDR SDRAM static timing analysis
From: pinku1979@gmail.com
Date: 13 Oct 2006 09:14:06 -0700
Links: << >>  << T >>  << A >>
Hi,
I need a help in static timing analysis for DDR interface to network
processor . Processor say that its timing is as per JEDEC standard.

For Read i will be use
tSD (avg.) =3D (tDQSQ + tDV) =F7 2
 and able to find the setup margin and the hold margin.

But in the Write i am not able to calculate the same. Controller and
DDR SDRAM say that it will provide/need 0.45 ns setup and hold time. I
donot have any margin in that case. Can you let me know how do the do
timing analysis for the write cycle.
=20
Thanks and regards
Pinku


Article: 110309
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Oct 2006 09:19:57 -0700
Links: << >>  << T >>  << A >>
Manny schrieb:

> Hey,
>
> I've been reluctant recently on envisaging a Virtex-4 device as being
> operational in a battery-powered situation. The inrush configuration
> current, high static power consumption, and the non-uniform power
> exhibited subject to temperature rise are amongst few to name about the
> shortcomings of SRAM FPGAs in general. Having said that, the
> unprecedented versatile reconfigurable processing power is yet the
> decisive factor in prototyping intensive DSP operations. My question
> is: has any body come across a scenario in which a large FPGA was
> battery-powered. I'm in the phase of deciding on solutions to employ
> for my active research so it's quite critical. I don't want to start my
> research with a major gap in my rationale. Can any veteran in here
> comment on the topic please. Is it really ridiculous to think about
> powering a large SRAM FPGA from a battery? Would really appreciate all
> comments. What's the cheapest price ever a smallest Virtex-4 device was
> reported?
>
> Cheers,
> -Manny

I was considering V4 lately for portable battery powered gadget
and did not see it feasible (different reasons).

for you it all depends
1) how much battery power you have
2) what else except FPGA takes power
3) required battery operation time
4) what FPGA is doing

the best for battery is V4-FX12 when used with PPC (less power than
MB!)
every other Virtex4 or Virtex5 means more static power to the extent
that
it drains the battery on static current only!

smallest power an V4FX12 based system takes is about 1W
so if your battery has 3w/hr then it will operate 3 hours.

pricing - thumb guess ia that if you are would be able to get prices
below 70USD you would not be asking. So expect pricing between 70 and
100

Antti


Article: 110310
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Peter Alfke" <peter@xilinx.com>
Date: 13 Oct 2006 09:25:34 -0700
Links: << >>  << T >>  << A >>
Manny, here would be my order of concern:
1. How much, and what type of, logic do I need
2. How fast should it run (can I time-division multiplex?)
3. What is the smallest and cheapest device that fits those
requirements
4. How much power does it draw while working, and in stand-by
5. In-rush current is not a concern anymore, and batteries are actually
very good at supplying lots of current for a very short time.

Virtex-4 LX 15 and '25 and '40 are the smallest, for Virtex-5 it is
presently the LX50
Really small devices with Virtex-like features and performance are not
in high demand.
Most low-end applications do not require that many features and that
much performance, and they use Spartan-3 devices. For very low
complexity and power consumption, use CoolRunner CPLDs.
Peter Alfke, Xilinx Applications
===============
Manny wrote:
> Hey,
>
> I've been reluctant recently on envisaging a Virtex-4 device as being
> operational in a battery-powered situation. The inrush configuration
> current, high static power consumption, and the non-uniform power
> exhibited subject to temperature rise are amongst few to name about the
> shortcomings of SRAM FPGAs in general. Having said that, the
> unprecedented versatile reconfigurable processing power is yet the
> decisive factor in prototyping intensive DSP operations. My question
> is: has any body come across a scenario in which a large FPGA was
> battery-powered. I'm in the phase of deciding on solutions to employ
> for my active research so it's quite critical. I don't want to start my
> research with a major gap in my rationale. Can any veteran in here
> comment on the topic please. Is it really ridiculous to think about
> powering a large SRAM FPGA from a battery? Would really appreciate all
> comments. What's the cheapest price ever a smallest Virtex-4 device was
> reported?
> 
> Cheers,
> -Manny


Article: 110311
Subject: more than 90% occupancy in an Actel FPGA
From: alessandro basili <alessandro.basili@cern.ch>
Date: Fri, 13 Oct 2006 18:27:18 +0200
Links: << >>  << T >>  << A >>
Hi to everyone,
I'm using an Actel fuse A54SX72A, which has 2012 sequential cells and at 
the moment I filled it up to more than 90%.
There can be the need more triple-redundant registers in it and I'm 
afraid I will have routing problems with that.
Has anyone here experienced this? Can I rely on the Actel Designer 
backannotate to have a close-to-reality simulation?

Thanks a lot

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Article: 110312
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "John_H" <newsgroup@johnhandwork.com>
Date: Fri, 13 Oct 2006 16:29:04 GMT
Links: << >>  << T >>  << A >>
"Manny" <mloulah@hotmail.com> wrote in message 
news:1160755594.427130.118490@m73g2000cwd.googlegroups.com...
> Hey,
>
> I've been reluctant recently on envisaging a Virtex-4 device as being
> operational in a battery-powered situation. The inrush configuration
> current, high static power consumption, and the non-uniform power
> exhibited subject to temperature rise are amongst few to name about the
> shortcomings of SRAM FPGAs in general. Having said that, the
> unprecedented versatile reconfigurable processing power is yet the
> decisive factor in prototyping intensive DSP operations. My question
> is: has any body come across a scenario in which a large FPGA was
> battery-powered. I'm in the phase of deciding on solutions to employ
> for my active research so it's quite critical. I don't want to start my
> research with a major gap in my rationale. Can any veteran in here
> comment on the topic please. Is it really ridiculous to think about
> powering a large SRAM FPGA from a battery? Would really appreciate all
> comments. What's the cheapest price ever a smallest Virtex-4 device was
> reported?
>
> Cheers,
> -Manny

Keep in mind that non-nuclear submarines are run on batteries and they tend 
to use significantly more power than a Virtex-4.  What you're willing to use 
for batteries will determine whether you can achieve your goals.

It seems that increasing battery technology has a practical upper limit for 
ultra-portables.  If you have a battery-powered cell phone, running 60 watts 
through the device would make it unusuable because of the heat genereated in 
the confined footprint.  If you're not going for ultra-portable or single 
AA-cell powered devices, your options are wide open.  Consider that a small 
Virtex-4 has lower power requirements than the laptop's processor alone. 



Article: 110313
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 13 Oct 2006 09:31:22 -0700
Links: << >>  << T >>  << A >>
Manny,

Just one comment:

There has been no "in rush" or "bonus" current needed since Virtex II
(V2, V2P, V4, V5 have no "inrush" for Vccint, the datasheet specifies
the minimum Iccint required to power on and configure).

What you describe was common for Virtex E, and older families.  However,
we decided that was unacceptable, so we fixed it (a long time ago, now).

Austin

Manny wrote:
> Hey,
> 
> I've been reluctant recently on envisaging a Virtex-4 device as being
> operational in a battery-powered situation. The inrush configuration
> current, high static power consumption, and the non-uniform power
> exhibited subject to temperature rise are amongst few to name about the
> shortcomings of SRAM FPGAs in general. Having said that, the
> unprecedented versatile reconfigurable processing power is yet the
> decisive factor in prototyping intensive DSP operations. My question
> is: has any body come across a scenario in which a large FPGA was
> battery-powered. I'm in the phase of deciding on solutions to employ
> for my active research so it's quite critical. I don't want to start my
> research with a major gap in my rationale. Can any veteran in here
> comment on the topic please. Is it really ridiculous to think about
> powering a large SRAM FPGA from a battery? Would really appreciate all
> comments. What's the cheapest price ever a smallest Virtex-4 device was
> reported?
> 
> Cheers,
> -Manny
> 

Article: 110314
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 13 Oct 2006 09:38:52 -0700
Links: << >>  << T >>  << A >>
Manny,

Further:

http://www.xilinx.com/prs_rls/2006/end_markets/0644_gendynamics.htm

It seems that GD has selected V4 for a software defined radio, and it is
portable (battery operated).

One nice thing about a radio application is that it is not operating
continuously (as they are shooting at one another on the battlefield).

Another useful element of the JTRS SDR radio is that is does not even
load the configuration for a particular modulator or demodulator until
it receives, or wishes to transmit in that mode.  Only one "waveform" is
ever active at a time, and only as transmit, or as receive, and other
than that, the FPGA is (probably) powered down and waiting.

(I profusely apologize for any marketing contained in this posting:  any
such marketing content should be considered as such, and treated
accordingly.)

Austin


Manny wrote:
> Hey,
> 
> I've been reluctant recently on envisaging a Virtex-4 device as being
> operational in a battery-powered situation. The inrush configuration
> current, high static power consumption, and the non-uniform power
> exhibited subject to temperature rise are amongst few to name about the
> shortcomings of SRAM FPGAs in general. Having said that, the
> unprecedented versatile reconfigurable processing power is yet the
> decisive factor in prototyping intensive DSP operations. My question
> is: has any body come across a scenario in which a large FPGA was
> battery-powered. I'm in the phase of deciding on solutions to employ
> for my active research so it's quite critical. I don't want to start my
> research with a major gap in my rationale. Can any veteran in here
> comment on the topic please. Is it really ridiculous to think about
> powering a large SRAM FPGA from a battery? Would really appreciate all
> comments. What's the cheapest price ever a smallest Virtex-4 device was
> reported?
> 
> Cheers,
> -Manny
> 

Article: 110315
Subject: Re: VGA timing
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Fri, 13 Oct 2006 10:52:53 -0600
Links: << >>  << T >>  << A >>
icegray@gmail.com wrote:
> Hi everbody,
> I wanna implement VGA core at 1024x768x75Hz (15" LCD Monitor) on
> Spartan3E starter kit. I have got a few question. I have tried to find
> some detialed documents for VGA timing But I can't. There are 640x480
> and 800x600 but there is no document for more resolution and refresh
> rate.
> - Front porch time, back porch time, and sync pulse times are same at
> every resolution (I think it's standard because VGA cards can change
> resulation and refresh rate for every value and every monitor??? But
> There are different values for 640x480 and 800x600 on the documents???)
> - What is hsync and vsync polarisation? What must I do if it's negative
> or positive? (invert the sync signal???) Why it is different for
> different resolution?
> - Any body can give me timing values or recommend any source? ( I can't
> a right document on the Vesa web page)
> 
> Thanks
> 

I know this doesn't answer the question exactly, but here are the 
parameters I used in my VGA controller for a 60Hz refresh rate:

     "1024x768_60Hz": // pixel clk 65MHz
       begin
                           H_FRONT_PORCH=24;   HSYNC_WIDTH=136;
         H_BACK_PORCH=160; LEFT_BORDER=0;      LINE_WIDTH=1024;
         RIGHT_BORDER=0;   V_FRONT_PORCH=3;    VSYNC_WIDTH=6;
         V_BACK_PORCH=29;  TOP_BORDER=0;       FRAME_HEIGHT=768;
         BOTTOM_BORDER=0;  SYNC_POLARITY=0;
       end

You can probably use the same parameters but just bump up the pixel 
clock frequency to 80MHz or so.
-Kevin

Article: 110316
Subject: Re: Last ISE version that supports XC95xxXL ?
From: avionion@gmail.com
Date: 13 Oct 2006 10:04:20 -0700
Links: << >>  << T >>  << A >>
Thanks Antti, already thought so but i was not sure if thats the good
approach. i was puzzled because of the fact that it was working fine
with 6.3i. thanks for the help

Antti wrote:
> avion...@gmail.com schrieb:
>
> > Hi,
> > though not directly releated to the topic but i have similar problem
> > with webpack ise.
> > the follow code runs ok on 6.3i but fails on 8.2i. can anyone help me
> > out why its so and whats the solution?
> >
> > addr_r       <= unsigned(addr_nxt(15 downto 1));
> > addr_r is declared unsigned(22 downto 0) while  addr_nxt is
> > std_logic_vector(15 downto 0)
> > i have also included libraries as :
> >  library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_arith.all;
> > use ieee.std_logic_unsigned.all;
> > use ieee.numeric_std.all;
> > with exactly the same files, this code compiles ok on ise 6.3i but
> > gives error on 8.2i, the error is that actual size is 23 while the
> > operand on right hand side has size 16.
> >
>
> thats correct (by ISE 8.2) it does more checks -
> just add the (15 downto 0) to the lefthand operand
> should work then
> 
> Antti


Article: 110317
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Manny" <mloulah@hotmail.com>
Date: 13 Oct 2006 10:11:43 -0700
Links: << >>  << T >>  << A >>
Thanks a lot guys, all comments are really useful and I'm definitely
gonna reason much about them.

My application is definitely gonna be DSP intensive. The bad news is
that it's basically a CDMA application so many things have to run in
parallel in a multiple access system, the more things can run in
parallel the more robust the model is and thus yielding in terms of
performance. The good news is that we'r not talking about RF signals in
here, so things doesn't need to run real fast. My major concern is that
things are quite coupled at the moment i.e. lots of things depends on
stuff that are yet to be fully characterized. As we might have settle
for less perfect hardware (not talking digital in here), our model
would grow more complicated as to accommodate for these imperfections.
The online reconfigurability of the system  is also highly desirable as
functionality can change in time. So a CPLD won't do, not even a
low-cost spartan although ultimately we might have to sacrafice
reconfgurability. The only bright side in this mess is that I might be
able to argue, once the system has been fully developed, that certain
functionalities have to be ported to ASIC. I'm keen on having as much
DSP power as possible as there are advanced issue on the agenda such as
Doppler Effective and AOA estimation. So there is no doubt that I'll
end up time sharing the available DSP slices. For prototyping, I think
it always make sense to get a bit more than what you expect to use.
Virtex-4 FX12 seems a reasonable start with the open possiblity to
migrate to V-5 once the rest of the family is introduced.

Cheers,
-Manny


Article: 110318
Subject: Re: Last ISE version that supports XC95xxXL ?
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 13 Oct 2006 10:13:58 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
> Stepping back ISE history and installing 7.x then 6.x ...etc and
> retesting in the hope that maybe
> some older version works is really painful :(

VMware Server is gratis and once you've gotten your first Windows VM,
the next 1,000,000 are easy :-) VMware can use the host filesystem,
thus you can just set up a VM for each version of ISE etc. and try them
one by one.

Tommy


Article: 110319
Subject: Re: VGA timing
From: cs_posting@hotmail.com
Date: 13 Oct 2006 10:16:18 -0700
Links: << >>  << T >>  << A >>
icegray@gmail.com wrote:

> Also do you have any idea for polarization???

At a certain point you just need to try and see what the result is.
When you get close, you can probably figure out the error from the sort
of distortion you see.

Also most modern monitors (and all LCD's) do a lot of interpretation of
the incoming signal, so things like polarity are likely either
autodetected or available in a settings menu.  (Though depending on how
the on screen display is done, you may not be able to see the settings
menu if you have an input signal that is close enough to be recognized
as a signal, but not good enough to produce a stable picture.)


Article: 110320
Subject: Re: DDR SDRAM static timing analysis
From: PeteS <peter.smith8380@ntlworld.com>
Date: Fri, 13 Oct 2006 17:24:15 GMT
Links: << >>  << T >>  << A >>
pinku1979@gmail.com wrote:
> Hi,
> I need a help in static timing analysis for DDR interface to network
> processor . Processor say that its timing is as per JEDEC standard.
> 
> For Read i will be use
> tSD (avg.) = (tDQSQ + tDV)  2
>  and able to find the setup margin and the hold margin.
> 
> But in the Write i am not able to calculate the same. Controller and
> DDR SDRAM say that it will provide/need 0.45 ns setup and hold time. I
> donot have any margin in that case. Can you let me know how do the do
> timing analysis for the write cycle.
>  
> Thanks and regards
> Pinku
> 

Tell us:

1. The exact processor
2. The memory you are using
3. The speed you desire to run at

and then we might be able to help.

I do know that write cycle timing is easier to meet than read for 
standard DDR memory.

Cheers

PeteS

Article: 110321
Subject: Re: LatticeMico32 extremly poor performance without caches
From: "Avion" <avionion@gmail.com>
Date: 13 Oct 2006 10:32:26 -0700
Links: << >>  << T >>  << A >>
:)
Antti wrote:
> avionion@gmail.com schrieb:
>
> > Thanks Antti it works!
> > but i still wonder what the lattice people are doing. no response in
> > more than a month time.
> > Antti wrote:
> > > avionion@gmail.com schrieb:
> 
> maybe their webmaster is learning at Xilinx?
> 
> Antti


Article: 110322
Subject: Re: [ISE8.2] DIFF_TERM and unused pin
From: yttrium <yttrium@telenet.be>
Date: Fri, 13 Oct 2006 19:51:38 +0200
Links: << >>  << T >>  << A >>

Indeed, that was what i was doing until now ... i just hoped that 
somewhere there was a constraint that you could use to keep it 
unoptimized ....

thanks anyway ...

kind regards,

Tim

Antti wrote:
> Tim Verstraete schrieb:
> 
>> Hey,
>>
>> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM
>> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them
>> ... now i want both buffers to stay in my design and not optimized
>> away. Is there a constraint that i can place on that buffer? i guess
>> that it should be a UCF constraint since when i look into the RTL
>> viewer of planahead and ISE i still see the buffer.
>>
>> I know that there is an option in NGBuild -u which keeps the unused
>> logic, but i do not want to use it just for that 1 buffer ...
>>
>> thanks in advance,
>>
>> kind regards,
>>
>> tim
>>
>> p.s. i'm using ISE8.2SP2 and a V4SX55-FF1148C
> 
> the best thing possible is to use it without using it :)
> 1) like route the unused input to non-bonded IO,
> 2) or use in some net in way that the signal isnt really used but XST
> fails to optimize it out
> 3) or if you dont use BSCAN you can also route it to TDO pin
> 
> all those tricks would keep the net alive. sure it would use
> some interconnect resources.
> 
> Antti
> 

Article: 110323
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Antti" <Antti.Lukats@xilant.com>
Date: 13 Oct 2006 11:13:45 -0700
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:

> Manny,
>
> Just one comment:
>
> There has been no "in rush" or "bonus" current needed since Virtex II
> (V2, V2P, V4, V5 have no "inrush" for Vccint, the datasheet specifies
> the minimum Iccint required to power on and configure).
>
> What you describe was common for Virtex E, and older families.  However,
> we decided that was unacceptable, so we fixed it (a long time ago, now).
>
> Austin
>
Austin,

please check Xilinx publication EN049(v 1.3) page 2
for Virtex-5 power requirements during configuration

Antti


Article: 110324
Subject: Re: OT: Internships?
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Fri, 13 Oct 2006 18:19:40 GMT
Links: << >>  << T >>  << A >>
Hello Isaac,

> 
> I am currently in my 3rd year of Electrical Engineering undergrad at
> Ryerson University in Toronto, Ontario, Canada. The internship (if
> acquired) is slated to start right after this academic year.
> This effectively delays my graduation by 1 yr, but I think that is a
> really small price to pay for the experience.
> 

Absolutely! We need grads that have practical skills. I have seen many 
(far too many) who can't even solder. It's pathetic these days.

> 
> Here is a rudimentary list of my skills, a more thorough one will be
> submitted w/ my resume:
> 
> Programming Languages: C, Java, Visual Basic, Assembly, Win32
> programming, Python
> 
> Compilers/Environment: GNU tools, Microsoft Visual Studio
> 
> Microprocessors/Microcontrollers: M680x0, Z80, x86, 8051, PIC, MSP430,
> ARM7, HC11, Renesas SuperH series
> 
> proemulator.sf.net
> 
> I ported my Z80 emulator to this app some time ago. My M68000 emulator
> is working and is tested to be quite accurate, but the author no longer
> maintains it or updates it so I decided against porting it (even though
> I can still get into the CVS).
> 
> 
> Programmable Logic: Xilinx Spartan3 series FPGA w/ Xilinx ISE WebPack
> 
> I designed a simple VGA frambuffer 320x240x2-bit and a simplistic
> 16-bit CPU in VHDL.
> 
> 
> Electronics: Basic analog electronics (FET's, OpAmps, BJT's, etc.)
> Here all I did was some school projects. Simple stuff: VCO's, FET amps,
> etc.
> 
> Operating Systems: Linux, MS-DOS, Windows (effective w/ all).
> Been doing installs on all OS's for quite some time now. Used MS-DOS
> while I was growing up (had it first running on a 16Mhz 386SX).
> 
> Most the stuff I have learned was from buying products containing the
> previously mentioned items and playing around with them and their
> associated tools and reading my dads old college books (he studied
> electronics engineering technology at NAIT. They did extensive course
> work in digital electronics).
> 
> I really do not have any related engineering experience. I did work for
> GO Transit this past summer,  a major transportation company here in
> Ontario, as general help. I was called on one day to look over some
> computer scans of microfilm schematics of the trains (and electrical
> systems) to make sure they were up to par.
> 
> I would like to shadow some teams in the engineering sector to get a
> feel of what you guys do in the industry. I would like to see how you
> guys solve problems, tackle issues or shortcomings you come up in
> development and the like. I'd also like to learn from the people
> working in this industry in general since they have a wealth of
> knowledge and experience. Sometthing I think can be invaluable to me in
> my career.
> 
> They have some listings at my school, but they are not exactly what I
> am interested in. Thanks for listening to my story!
> 
> Any companys you know of in Toronto?


Just a suggestion: Post again under the subject "Looking for internship 
near Toronto". And also post in sci.electronics.design. There are a few 
Canadians who know the industry up there. Monster might be another 
avenue (though I don't know if that one is free).

Relocation: I wouldn't exclude other places. All my vacation jobs during 
my university time were actually in other countries. Sometimes I pooled 
my available rent money with a few others and then we found we were able 
to rent a nice big house. Almost cost me less than my apartment near the 
university. And you don't have to live off cans and ramen noodles. It is 
amazing what you can cook out of fresh ingredients, from scratch, if you 
have critical mass (enough cash contributing eaters). We took turns 
shopping and usually cooked together. Pizzas, casseroles and what not, 
all from scratch and for little money. Yep, we made our own dough. I 
never ate any fast food from the first day at the university until they 
handed me my masters. Still don't :-)

-- 
Regards, Joerg

http://www.analogconsultants.com



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