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 131575

Article: 131575
Subject: Re: Survey: FPGA PCB layout
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Fri, 25 Apr 2008 10:11:20 -0700
Links: << >>  << T >>  << A >>
JosephKK wrote:
> On Sat, 19 Apr 2008 20:47:57 -0400, krw <krw@att.bizzzzzzzzzz> wrote:
> 
>> In article <PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com>, 
>> notthisjoergsch@removethispacbell.net says...
>>> Joel Koltner wrote:
>>>> "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message 
>>>> news:tq7Oj.1556$FF6.588@newssvr29.news.prodigy.net...
>>>>> All I know from here (CA) is that their benefits are mind-boggling...
>>>> Well, it's entirely reasonable to have retirement benefits for public 
>>>> employees be comparable to what private companies offer... I just hope that 
>>>> public employee salaries will then become comparable as well (which implies a 
>>>> pay raise), since otherwise  I don't see how the gov't. expects they'll get 
>>>> comparable quality out of their workers.
>>>>
>>> Private companies generally offer zilch in retirement benefits. Those 
>>> days are long gone.
>> I don't know about "gone".  The age of the "defined benefit" is 
>> pretty much gone in private industry but several still have "defined 
>> contribution" plans.  Now, 401Ks make up for a lot of what's been 
>> lost and are portable.  
>>
>>>> One problem with the government seems to be that they don't expect their 
>>>> employees to be agile over time.  See this article: 
>>>> http://www.gcn.com/print/24_30/37174-1.html -- Someone the government ends up 
>>>> with a bunch of 70 year old programmers and therefore has to hire IBM to build 
>>>> them the modernized e-filing systems?  Surely there must be some new hires in 
>>>> the past, say, 40 years who could have been working on this and hence, on 
>>>> average, would only be middle-aged today!?
>>>>
>>> A 70 year old programmer can be better than a 40 year old. At least 
>>> that's my impression when I see all the "modern" bloatware ;-)
>> Maybe.  There are better things to do at 70, though.  ;-)
>>>>> Oh, and then lots of jobs have the retirement benefit tied to the last work 
>>>>> year.
>>>> I expect that was implemented to help people who were *forced* to move?
>>>>
>>>> It seems like it needs reworking to differentiate between cases where the 
>>>> government wants to move you vs. you just voluntarily wanting to do so.
>>>>
>>> Or you just have to have the right connections to make that happen ...
>>>
>>> Anyhow, why should retirement checks be based on the last year of 
>>> service? IMHO that's wrong. For everyone else it sure doesn't work that way.
>> The last years' is indicative of the final salary.  Most "defined 
>> benefit" plans do take the last year, or last couple of years into 
>> account.  What most private pensions *don't* do, that public plans 
>> do is include overtime in the formula.  It's not hard to double 
>> one's income for a couple of years.  There is no way the tax payer 
>> should pay that forever.
> 
> So you say.  While there are classes where that is easily done it is
> usually in the mid range hourly and low range salaried that it is
> reasonably possible.  But how may 50+ year olds do you know that can
> and will work significant overtime?
>  

Plenty around here. Usually in law enforcement.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Article: 131576
Subject: Re: Survey: FPGA PCB layout
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Fri, 25 Apr 2008 10:19:34 -0700
Links: << >>  << T >>  << A >>
JosephKK wrote:
> On Thu, 17 Apr 2008 17:13:27 -0400, "Steve" <sjburke1@comcast.net>
> wrote:
> 
>> "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message 
>> news:U5MNj.6956$GE1.6193@nlpi061.nbdc.sbc.com...
>>> qrk wrote:
>>>> On Thu, 17 Apr 2008 09:43:09 -0700 (PDT), Dave <dhschetz@gmail.com>
>>>> wrote:
>>>>
>>>>> Does anybody out there have a good methodology for determining your
>>>>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean?
>>>>> The brute force method is fairly maddening. I'd be curious to hear if
>>>>> anybody has any 'tricks of the trade' here.
>>>>>
>>>>> Also, just out of curiosity, how many of you do your own PCB layout,
>>>>> versus farming it out? It would certainly save us a lot of money to
>>>>> buy the tools and do it ourselves, but it seems like laying out a
>>>>> board out well requires quite a bit of experience, especially a 6-8
>>>>> layer board with high pin count FPGA's.
>>>>>
>>>>> We're just setting up a hardware shop here, and although I've been
>>>>> doing FPGA and board schematics design for a while, it's always been
>>>>> at a larger company with resources to farm the layout out, and we
>>>>> never did anything high-speed to really worry about the board layout
>>>>> too much. Thanks in advance for your opinions.
>>>>>
>>>>> Dave
>>>> Sure wish there was a slick way of doing FPGA pinouts. I usually use
>>>> graph paper and figure out the FPGA pinout to other parts to minimize
>>>> routing snarls.
>>>>
>>>> I do pcb layouts on my own and other folks designs. Our boards have
>>>> high-speed routing, switching power supplies, and high-gain analog
>>>> stuff; sometimes all on the same board. Unless the service bureau has
>>>> someone who understands how to lay out such circuitry and place
>>>> sensitive analog stuff near digital junk, it is more trouble to farm
>>>> out than do it yourself if you want the board to work on the first
>>>> cut.
>>>>
>>> Or find a good layouter and develop a long-term business relationship. My 
>>> layouter knows just from looking at a schematic which areas are critical. 
>>> He's a lot older than I am and that is probably one of the reasons why his 
>>> stuff works without much assistance from me. Nothing can replace a few 
>>> decades of experience.
>>>
>>>
>>>> Doing your own layout will take a lot of learning to master the PCB
>>>> layout program and what your board vendor can handle. It will take 5
>>>> to 10 complicated boards to become mildly proficient at layout. I
>>>> don't know about saving cost. Your time may be better spent doing
>>>> other activities rather than learning about layout and doing the
>>>> layouts. ...
>>>
>>> Yep, that's why I usually do not do my own layouts. Occassionally I route 
>>> a small portion of a circuit and send that to my layouter. No DRC or 
>>> anything, just to show him how I'd like it done.
>>>
>>>
>>>>     ... The upside to doing your own layout - you control the whole
>>>> design from start to finish. If you have a challenging layout, you'll
>>>> have a much higher probability of having a working board on the first
>>>> try which has hidden savings (getting to market earlier <- less
>>>> troubleshooting + less respins).
>>>>
>>>> ---
>>>> Mark
>>>
>>> -- 
>>> Regards, Joerg
>>>
>>> http://www.analogconsultants.com/
>>>
>>> "gmail" domain blocked because of excessive spam.
>>> Use another domain or send PM.
>> I agree with Joerg. Good high speed or mixed signal PCB layout is a career 
>> choice, and we electrical engineers already chose our career. A good layout 
>> requires someone who understands not just the software package, but the 
>> details of how the manufacturing operation is going to proceed, what the 
>> limits of the processes are, what the assembly operations require of the 
>> board, and is anal about things like footprint libraries and solder mask 
>> clearances and a thousand other details that I'm only partially aware of. 
>> The more complex your design, the more critical these things become.
>>
>> I have two good local outfits for farming out boards. For complex stuff, 
>> they know I'll come to their place and sit next to the designer for a good 
>> bit of the initial placement. While we are doing placement, we are also 
>> discussing critical nets, routing paths, layer usage, etc.  That gives us 
>> direct face to face communication and avoids spending lots of time trying to 
>> write/draw everything in gory detail (which gets ignored or misunderstood a 
>> lot of the time). That investment pays big dividends in schedule and board 
>> performance.
>>
>> Don't be fooled by the relatively low cost of the software. That's not where 
>> the big costs are.
>>
>> I once laid off my entire PCB layout department and sent all the work 
>> outside, because although my employees all knew how to use the software, 
>> none of them could tell me what their completion date would be, or how many 
>> hours it would take, and they certainly weren't interested in meeting 
>> schedules. The outside sources would commit to a cost and a delivery date. 
>> And we already knew they could meet our performance objectives. Fixed price 
>> contracts are great motivators. Missing an engineering test window, or 
>> slipping a production schedule because of a layout delay can be enormously 
>> expensive.
>>
>> Of course, if I had let my engineers do their own layouts, the motivation 
>> would have been present, but the technical proficiency would not. How 
>> proficient can anyone become if they only do layout a few times a year? 
>> Also, on many projects engineers use the layout period for other important 
>> things like documentation, test procedures, writing test code, etc. Doing 
>> your own layout serializes these tasks and will stretch your schedule.
>>
>> So my advice is to keep doing what you have been doing. Its far more likely 
>> that its the cheapest approach, even though you occasionally have to write a 
>> big check.
>>
>> Steve
>>
> 
> Pretty much honest responses.  Almost all of good value. 
> 
>  Mark hinted and Joerg mentioned one of the foremost subjects,
> floorplanning.  This will impact everything you do.  From the original
> schematic drawing to the FPGA  VHDL/Verilog coding and optimizing to
> PWB layout , documentation, and testing.  Each of these activities
> requires floorplanning to get good results.  To achieve the best PWD
> layout results make several different versions for your first few
> boards and route them all to completion.  It will make huge
> improvements in your understanding.
>  

Right. The same goes for code, especially micro controllers. Without 
spending a lot of time on a floor plan chances are it won't fit in or 
it'll become a hodge-podge of code snippets somehow stitched together. 
Seen a lot of that :-(

There seems to be a huge software company up north that has in part lost 
the art of good floorplanning ...

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Article: 131577
Subject: Re: ATF750 for Proteus
From: ghelbig@lycos.com
Date: Fri, 25 Apr 2008 10:20:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 24, 5:28 pm, "Julio Espada" <news...@jmo.biz> wrote:
> Hi!
>
> I'm looking for the Atmel ATF750C library for Proteus but I'm unable to find
> it on both Atmel & Labcenter sites. Does anyone know where can I find this ?
> Or perhaps, any other application that can simulate the ATF750C ?
>
> Thanks in advance for any help.

The ATF750 is an odd beast that (AFAIK) is only supported by Atmel
tools.  I believe the reason you can't find Proteus for the part is
because it does not exist.

Sorry,
G.

Article: 131578
Subject: Breaking News ... Accellera Verification Working Group Forming
From: HairyTheASICGuy@gmail.com
Date: Fri, 25 Apr 2008 10:35:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Read All About It at http://synopsysoc.org/thestandardsgame/?p=3D64!

On her Standards Game Blog today, Karen Bartleson announced that
Accellera formed a subcommittee to define a standard for verification
interoperability.

That is, Synopsys is stepping up to an industry leadership position to
settle the VMM / OVM war.

This is the right move to do this in Accellera because it gives us
input into the process, rather than just the EDA vendors controlling
the process for their own benefit.  Karen points out in her blog that
it was user pressure they heard that made them open up VMM.  That's
us!

If you want to get your copy of the open VMM code that the new
Accellera working group will use you will need to wait until they get
the working group web landing page created.  Karen did not say who
would chair the group, but if you want her to pass your name on to the
new chair, you can email her at karenb @ synopsys . com.

I can't wait to get my copy of open VMM!

Of course, Synopsys is telling us that they are just doing the right
thing.  But having them donate VMM to Accellera as the basis of a
single methodology library opens the next question.

How will Cadence and Mentor respond?  Hopefully they=92ll join the
effort to add OVM features not found in VMM.  Let=92s keep the pressure
on them.

Article: 131579
Subject: Re: Xilinx is cancelling the Virtex-E XCV1000E-FG860
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 25 Apr 2008 10:38:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 24, 7:39=A0am, Alan Nishioka <a...@nishioka.com> wrote:
> Symon wrote:
> > Alan Nishioka wrote:
> >> Xilinx is canceling the Virtex-E XCV1000E-FG860.
>
> > Maybe an interposer would work? Mount the FG900 on that, mount the
> > interposer on your board? Something like this...
> >http://advanced.com/pdf/AIC_BGA_Interposer_DataSheet_revJun07.pdf
> > HTH., Syms.
>
> I fear that an interposer won't work at 75MHz. =A0It was hard enough to
> get to work as it is. =A0But it is worth some thought. =A0I wonder how muc=
h
> it costs?
>
> Thank you everyone for your responses. =A0I figured it was worth a shot if=

> anyone had a radical idea.
>
> Alan Nishioka

Alan, let's all agree:
You do not have any problem in 2008, not a problem in 2009, and only
an economical issue in 2010 and 2011. Let's not panic!
Peter Alfke

Article: 131580
Subject: Re: Breaking News ... Accellera Verification Working Group Forming
From: BestInSoC@gmail.com
Date: Fri, 25 Apr 2008 10:48:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Your link to a Synopsys "like" web address appears real.  But I doubt
this is really Synopsys.  And looking at the Accellera website, there
is *NO* mention of this.  I hardly believe it is true that Accellera
has created this group and that Synopsys has donated VMM.

Synopsys has spent years on VMM development and has been working on
the second version of VMM that this makes absolutely no sense.

Great spoof on the Synopsys website, that must have taken a lot of
time to do to spew this disinformation.

Synopsys will NEVER let their VMM source out since it requires special
calls to proprietary simulator functions that they have kept as a
trade secret so others are not able to build a system than can compete
with them.

Now go back to your cave and keep your dreams to yourself.

Article: 131581
Subject: Re: -. . ..- ... --. .-. --- ..- --- .--.
From: austin <austin@xilinx.com>
Date: Fri, 25 Apr 2008 10:54:58 -0700
Links: << >>  << T >>  << A >>
Syms,

Thanks!  Wonderful.

In all seriousness, I would suggest we treat the newbies with a little
more patience.  It isn't easy starting out in this field.  I know these
folks will not become your customers, but they might someday be mine.

Austin

Article: 131582
Subject: Re: Breaking News ... Accellera Verification Working Group Forming
From: Jason Zheng <Xin.Zheng@jpl.nasa.gov>
Date: Fri, 25 Apr 2008 11:05:19 -0700
Links: << >>  << T >>  << A >>
Not so fast. On the contrary, synopsysoc.org does belong to synopsys:

$ whois synopsysoc.org
<snip>
Domain ID:D149040000-LROR
Domain Name:SYNOPSYSOC.ORG
Created On:04-Sep-2007 18:24:52 UTC
Last Updated On:04-Nov-2007 03:48:07 UTC
Expiration Date:04-Sep-2009 18:24:52 UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR)
Status:CLIENT DELETE PROHIBITED
Status:CLIENT RENEW PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:GODA-037023796
Registrant Name:Synopsys Hostmaster
Registrant Organization:Synopsys, Inc.
Registrant Street1:700 East Middlefield Road
Registrant Street2:
Registrant Street3:
Registrant City:Mountain View
Registrant State/Province:California
Registrant Postal Code:94043
Registrant Country:US
Registrant Phone:+1.6505841507
Registrant Phone Ext.:
Registrant FAX:+1.6505841908
Registrant FAX Ext.:
Registrant Email:hmaster@synopsys.com
Admin ID:GODA-237023796
Admin Name:Synopsys Hostmaster
Admin Organization:Synopsys, Inc.
Admin Street1:700 East Middlefield Road
Admin Street2:
Admin Street3:
Admin City:Mountain View
Admin State/Province:California
Admin Postal Code:94043
Admin Country:US
Admin Phone:+1.6505841507
Admin Phone Ext.:
Admin FAX:+1.6505841908
Admin FAX Ext.:
Admin Email:hmaster@synopsys.com
Tech ID:GODA-137023796
Tech Name:Synopsys Hostmaster
Tech Organization:Synopsys, Inc.
Tech Street1:700 East Middlefield Road
Tech Street2:
Tech Street3:
Tech City:Mountain View
Tech State/Province:California
Tech Postal Code:94043
Tech Country:US
Tech Phone:+1.6505841507
Tech Phone Ext.:
Tech FAX:+1.6505841908
Tech FAX Ext.:
Tech Email:hmaster@synopsys.com
Name Server:EXDNS1.SYNOPSYS.COM
Name Server:EXDNS2.SYNOPSYS.COM
Name Server:EXDNS3.SYNOPSYS.COM
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 
Name Server: 

On Fri, 25 Apr 2008 10:48:50 -0700 (PDT)
BestInSoC@gmail.com wrote:

> Your link to a Synopsys "like" web address appears real.  But I doubt
> this is really Synopsys.  And looking at the Accellera website, there
> is *NO* mention of this.  I hardly believe it is true that Accellera
> has created this group and that Synopsys has donated VMM.
> 
> Synopsys has spent years on VMM development and has been working on
> the second version of VMM that this makes absolutely no sense.
> 
> Great spoof on the Synopsys website, that must have taken a lot of
> time to do to spew this disinformation.
> 
> Synopsys will NEVER let their VMM source out since it requires special
> calls to proprietary simulator functions that they have kept as a
> trade secret so others are not able to build a system than can compete
> with them.
> 
> Now go back to your cave and keep your dreams to yourself.


-- 
Don't take life so serious, son, it ain't nohow permanent.
		-- Walt Kelly


Article: 131583
Subject: Spartan3 "commercial" temperature range
From: dalai lamah <antonio12358@hotmail.com>
Date: Fri, 25 Apr 2008 18:25:49 GMT
Links: << >>  << T >>  << A >>
Spartan3 family has two operating temperature options, "commercial" and 
"industrial". This usually means 0/+70 °C and -40/+85 °C, but in Xilinx 
case the ranges are actually 0/+85 °C and -40/+100 °C.

Do you have any idea on how these different ranges were actually decided? 
It is mainly a curiosity that I have, but it could be useful too to know; 
I've tested a lot of 0/+70 parts with very low temperatures, and it's quite 
uncommon that they can't work flawlessly at least at -20 °C (frequently 
they are still fine at -60). Therefore I could speculate that S3 production 
cycle was too good, too many parts passed the -40/+85 °C test so they were 
deliberately "demoted" to 0/+85 °C for commercial reasons.

Of course Xilinx won't never confirm this, but knowing the "official" 
version could give some hints. ;)

-- 
emboliaschizoide.splinder.com

Article: 131584
Subject: How to arrange these SRL16 in a straight column
From: fl <rxjwg98@gmail.com>
Date: Fri, 25 Apr 2008 11:50:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I want to put a column of independent SRL16 in a Virtex 4 xc4vlx15
continuously. For even number, there is no problem. For odd number, I
cannot make them continuously even though these SRL16s are parallel,
independently with each other, see below code. I tried BEL attribute
without success. It seems ISE9.2i has to put "G" first, again here
does not require these SRL16 serially connected. Is it possible to put
independent SRL16 in a straight column? Thanks in advance.







........
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
library UNISIM;
use UNISIM.VComponents.all;

entity srl16TMP is
  generic (
    WIDTH  : in  natural := 5;
    DELAY_DEPTH  : in  natural := 3);
  port (
    S_IN     : in  std_logic_vector(WIDTH-1 downto 0);
    CLK      : in  std_logic;
    Q15      : out std_logic_vector(WIDTH-1 downto 0);
    S_OUT : out std_logic_vector(WIDTH-1 downto 0));
end;

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
library UNISIM;
use UNISIM.VComponents.all;
architecture DELAY_COMPONENT of srl16TMP is
attribute RLOC: string;
attribute BEL:  string;
attribute INIT: string;

signal TMP0: INTEGER;
CONSTANT SRL16_WIDTH : integer := 4;
signal TMPVECS: STD_LOGIC_VECTOR (SRL16_WIDTH-1 downto 0);
begin
	TMP0 <= DELAY_DEPTH;
	TMPVECS  <= CONV_STD_LOGIC_VECTOR(TMP0, SRL16_WIDTH);

INST_DLY : for i in 0 to WIDTH-1 generate
  type bel_lut_type is array (0 to 1) of string (1 to 1);
  constant bel_lut : bel_lut_type := ("F", "G");

--  attribute BEL  of S16_inst  : label is bel_lut"F"; -- ((WIDTH-1-i)
mod 2);--
  attribute RLOC of S16_inst  : label is "X0" & "Y" &
integer'image((WIDTH-1-i)/2); --(i);
  attribute INIT of S16_inst  : label is "0006";

  begin
	S16_inst : SRL16
	generic map (INIT => X"0006")
	port map (
		Q   => Q15(i),
		A0  => TMPVECS(0),
		A1  => TMPVECS(1),
		A2  => TMPVECS(2),
		A3  => TMPVECS(3),
		CLK => CLK,
		D   => S_IN(i));
  end generate;
end DELAY_COMPONENT;

Article: 131585
Subject: Re: Spartan3 "commercial" temperature range
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 25 Apr 2008 11:54:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
I can answer this, because I was the one who "did it".
This is not a Spartan issue, it was established about 15 years ago,
and applies to all Xilinx FPGAs, and it would not surprise me if
Altera now uses the same reasoning.

In the distant past, commercial was defined as 0 to 70 degrees C
ambient.
We soon realized that "ambient" is a meaningless number for a
progarmmable part, where the self-heating power consumption can vary
by several orders of magnitude. The decisive limitation is junction
temperature, no chip really cares about ambient temperature per se.

So we decided, against some customer complaints, to define
"commercial" byits junction temperature, and we raised the top by 15
degrees, to allow for power dissipation and thermal resistance.
We told our customers that "ambient" was obviously more easy to
control and measure, but was meaningless as a chip limitation for
programmable logic.

So, that's why we have 85 degrees fro commercial, and 100 degrees for
industrial.
The military specs had always used 125 degree case as their max limit.
Peter Alfke, Xilinx

Article: 131586
Subject: Virtex-4 inrush power-on current
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 25 Apr 2008 15:24:56 -0400
Links: << >>  << T >>  << A >>
I am replacing a V4FX20 chip with a V4FX40 on a board. I am a little bit 
concerned with the power-on requirements of the bigger chip. The existing 
core voltage power supply is designed for 1A. The datasheet says that 
Iccintmin is 244 mA typically, but can be as big as 1.65A under worst 
process, voltage and temperature conditions. It also says that the actual 
current consumed depends on the power-on ramp rate of the power supply. I 
wonder if there is some more precise information on how it actually depends 
on it?... Also, the board is never going to see worst ambient temperature or 
voltage conditions. Am I safe with 1A of continious current? Unfortunately, 
replacing the regulator is not easy due to very limited space and some other 
issues...


Thanks,
/Mikhail 



Article: 131587
Subject: Re: -. . ..- ... --. .-. --- ..- --- .--.
From: none <""doug\"@(none)">
Date: Fri, 25 Apr 2008 12:26:25 -0700
Links: << >>  << T >>  << A >>
austin wrote:
> Syms,
> 
> Morose vode?
> 
> Austin
Your code says newsgrouop. I always thought that
we spelled things the same in morse and in english.

I got my license fifty years ago next month but it
has been a long time since I received code.

Article: 131588
Subject: Re: Very simple VHDL problem
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Fri, 25 Apr 2008 13:31:31 -0600
Links: << >>  << T >>  << A >>
KJ wrote:
> On Apr 21, 1:11 pm, Kevin Neilson
> <kevin_neil...@removethiscomcast.net> wrote:
> 
>> Yes, my son--you are quickly learning the lameness of VHDL.  A number
>> isn't a number--sometimes it must be in single quotes, sometimes in
>> double quotes, and most often expressed in binary, just as the ancients
>> used to write.  And almost never can you use a number directly, but must
>> convert it from one arcane type to another.  -Kevin- Hide quoted text -
>>
> 
> On the first day, the VHDL gods created 'integer', 'natural', etc. and
> created ways to easily specify such numbers in any base, and saw that
> it was good...and the VHDL gods said, go forth and use these types for
> they are of my creation and they are good....but the unbelievers who
> think every number will potentially be bigger than 32 bits on each and
> every design that they create and the scallywags that created
> std_logic_arith refused to use 'integer' and instead used
> std_logic_vectors to perform arithmetic and then cursed the VHDL
> language for the numerous type conversions that they themselves
> brought down upon themselves....
> 
> KJ
There is some truth to that.  I am usually hamstrung by requirements 
such as "all ports must be std_logic_vectors", which is a human failing 
and not technically a shortcoming of the language.  Nonetheless, I 
prefer a language which never requires cumbersome conversions and yet 
will simulate x's and z's if I need it to.  -Kevin

Article: 131589
Subject: Re: -. . ..- ... --. .-. ..- --- .--.
From: austin <austin@xilinx.com>
Date: Fri, 25 Apr 2008 13:04:42 -0700
Links: << >>  << T >>  << A >>
None,

I can proficiently miss-spell at close to 18 WPM!

My wife and I got our licenses not long after October 17, 1989...

The Loma Prieta earthquake fault line is ~ 1.5 miles due south of my house.

I didn't get home for 12 hours, and then once home, the secondary
faulting and collapse of roads and bridges left us alone for five days.

No electricity (no water, no heat, no A/C).

I just told the kids it was an extended camping trip (kerosene lanterns,
picnic table in the garage, along with the white gas camp stove).  My
wife's parents sent by UPS bottled water, tp, and some other incidentals
(remember UPS and FedEx are allowed through to deliver in a disaster
zone, and they will deliver if they can!).

1 in 5 of my neighbors lost their homes.

We just lost all the dishes.

My wife's description was "first the wall hit me, then the floor hit me,
and then the wall hit me again."

So, a ham license had been on my list since I was 14, and I finally
learned the code, and got it.  My wife got the "tech Plus" no-code
license (now code is not required for any license class).

Where we live, we get 'Biblical' proportion disasters: fire, flood
(mud-slide), windstorm (127 MPH this last January), snow (since it
hardly ever snows, this can be a disaster), earthquake, ... let's see,
so far no plague, and no pestilence.  Maybe next year?

Just remember:  the first thing to go out in ANY emergency, is the cell
phone system.  The Department of Homeland Defense strongly recommends a
ham license, for anyone serious about being ready for a disaster (or
working with disaster response professionals).  The DHS has provided
funds for local repeaters, training, etc.  They certainly recognize a
good thing when they see it.

http://www.arrl.org/FandES/field/pscm/sec1-ch1.html

Hams aren't stupid, we know we get our many MHz of spectrum at the
pleasure of our country, so many of us actively give back by
volunteering for emergencies, and supporting our local agencies.

In my "ham life" I have trained people to be professional communicators
in the event of an emergency for Santa Cruz ARES, and I have volunteered
for the County Sheriff's Department since I was licensed as a "Net
Command" (what they call their radio dispatch for an "incident").

I encourage everyone to think about a ham license, anywhere you are in
the world, as when all else fails, we get through.

http://norfolk-ares.org/news.htm

(typical of what hams do every time the lights and phones go out)

Austin, AB6VU (QTH: CM97fb)

Article: 131590
Subject: Re: How to arrange these SRL16 in a straight column
From: Duane Clark <user@domaininvalid.com>
Date: Fri, 25 Apr 2008 20:10:42 GMT
Links: << >>  << T >>  << A >>
fl wrote:
> Hi, I want to put a column of independent SRL16 in a Virtex 4 xc4vlx15
> continuously. For even number, there is no problem. For odd number, I
> cannot make them continuously even though these SRL16s are parallel,
> independently with each other, see below code. I tried BEL attribute
> without success. It seems ISE9.2i has to put "G" first, again here
> does not require these SRL16 serially connected. Is it possible to put
> independent SRL16 in a straight column? Thanks in advance.

Okay, I'll byte. Is there some reason you want to do that? It sure looks 
like a lot of trouble. Why won't a CLK timing constraint work for you? 
Why do you care about the exact geometry?

And while here, why do all that code rather than inferring a shift 
register. A shift register is a single line of vhdl code (assuming you 
already have a process to stick it in) plus a variable declaration and a 
couple of output port assignments. And it simulates a lot faster.

Article: 131591
Subject: Re: Virtex-4 inrush power-on current
From: austin <austin@xilinx.com>
Date: Fri, 25 Apr 2008 13:12:54 -0700
Links: << >>  << T >>  << A >>
Mikhail,

Per the data sheet, the worst case possible Iccint is 1.65 amperes, yes.

If you do not have this available, you risk not powering on, and not
configuring.

Now, that said, that specification if for a 85C or 100C junction
temperature (C or I grade), highest voltage, fastest silicon.

It is up to you to gage the risk.  If the ambient is never that hot,
then the max current is a lot less.  If the Vccint is not 5% high, the
max current is less.  If the process is closer to typical, the current
is a lot less.

The FX20 had a max of 1.1 amperes, so you were violating that spec (with
only 1.0 amperes) before, and you seemed to be OK with that...

Perhaps if you test every pcb prior to ship at hot, you could by
testing, guarantee the power on?

Austin

MM wrote:
> I am replacing a V4FX20 chip with a V4FX40 on a board. I am a little bit 
> concerned with the power-on requirements of the bigger chip. The existing 
> core voltage power supply is designed for 1A. The datasheet says that 
> Iccintmin is 244 mA typically, but can be as big as 1.65A under worst 
> process, voltage and temperature conditions. It also says that the actual 
> current consumed depends on the power-on ramp rate of the power supply. I 
> wonder if there is some more precise information on how it actually depends 
> on it?... Also, the board is never going to see worst ambient temperature or 
> voltage conditions. Am I safe with 1A of continious current? Unfortunately, 
> replacing the regulator is not easy due to very limited space and some other 
> issues...
> 
> 
> Thanks,
> /Mikhail 
> 
> 

Article: 131592
Subject: Re: will there be any problem with diffrent version of sysgen & EDK
From: ghelbig@lycos.com
Date: Fri, 25 Apr 2008 13:20:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 24, 9:54 pm, Narendra Sisodiya <narendra.sisod...@gmail.com>
wrote:
> On Apr 25, 4:01 am, Narendra Sisodiya <narendra.sisod...@gmail.com>
> wrote:
>
>
>
> > On Apr 24, 11:17 pm, ghel...@lycos.com wrote:
>
> > > On Apr 24, 6:14 am, Narendra Sisodiya <narendra.sisod...@gmail.com>
> > > wrote:
>
> > > > hi, I have ISE 9.1 + EDK 9.1 (all updates)
> > > > Now i have downloaded the xilinx sysgen 10.1 (60 day trial) as 9.1 is
> > > > not available
> > > > also I have matlab R2006b
> > > > will threre be any problem with versions , in near future --
> > > > othrewise i will search 9.1 ,
>
> > > > Thanks n Regards
>
> > > In my experience, all the Xilinx components absolutely had to be of
> > > exactly the same revision.  Because of this, I would not even try
> > > using Sysgen-10.1 with ISE/EDK-9.1
>
> > > Either update ISE/EDK, or ask "pretty-please" to Austin or Peter and
> > > see if they will find you a sysgen-91.
>
> > > G.
>
> > Actually,, I have 9.2 sysgen exe file and My friend reported that he
> > has done his project with it and worked fine , He got some problem
> > with 9.1 -- Actually I do not have registration id for 9.2 version. on
> > xilinx website they give registration of 10.1 ,
> > So from where I can get registration id (60 day trial) for 9.2 sysgen
>
> problem solved , Thanks, my friend has given me sysgen 9.1 + reg-id
> also
> Thanks

Good that you solved it yourself.  It is highly unlikely that you
would have gotten manufacturer support for your pirated software.

G.

Article: 131593
Subject: Re: Spartan3 "commercial" temperature range
From: austin <austin@xilinx.com>
Date: Fri, 25 Apr 2008 13:29:48 -0700
Links: << >>  << T >>  << A >>
dalai,

It is no secret that the low temperature range parts really have the
same mask set as the extended range parts.

So what makes the I grade cost more?

I grade is tested, so that the specifications are guaranteed.

If you take a C grade part, and test it yourself at -40, and +100
(junction, not ambient), and it works for you, then you take the
responsibility, and you are paying for its testing.

Simple as that.

Pay Xilinx, or pay the price yourself: TANSTAAFL

But, if a part doesn't work, you will not be able to get Xilinx to help
you, as we didn't do the test, hence, we do not guarantee the junction
temp to be anything other than what the part is marked as (C).

It is also no secret that since the days of "hollow state" devices
(tubes like the 12AX7 family...),

http://cydathria.com/fdm/12AX7_sub.html

If a component tests and meets a higher performance target, it gets
marked as such, and you pay more for it.  That means that ordering the
slowest, or lowest performing component means you have parts that are a
mix, from the best, to the just passing (look at the specs for a 2N2222).

http://www.supplyframe.com/partsearchservlet/search.do?partNum=2n2222

You turn on the tester, put the parts in the hopper, and they fill the
bins on the other side: from highest speed grade Industrial, all the way
down to lowest speed grade commercial.  Remember that your lowest speed
grade commercial bin may have the fastest and widest temp parts in it
too, as once the orders are filled for the fast parts, you keep on
filling the bins below that until the orders are all filled.

Austin

Article: 131594
Subject: Re: Very simple VHDL problem
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 25 Apr 2008 13:32:05 -0700
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:

> There is some truth to that.  I am usually hamstrung by requirements
> such as "all ports must be std_logic_vectors", which is a human failing
> and not technically a shortcoming of the language.

I use std_logic_vector on top ports,
but never inside.
This is not much extra work.

> Nonetheless, I
> prefer a language which never requires cumbersome conversions and yet
> will simulate x's and z's if I need it to. 

For me, it's worth some trouble to
to be able to do integer, signed and unsigned
math in the same module.

             -- Mike Treseler

Article: 131595
Subject: Re: Problem writing quadrature decoder
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 25 Apr 2008 12:41:02 -0800
Links: << >>  << T >>  << A >>
-jg wrote:
(snip)

> I have heard of very high apparent edge rates in mechanical systems,
> caused by shock propogations (certainly enough to stress a Software
> Solution) - so a 50MHz+ clock is not as silly as it may sound :)

The clocked decoder latches the inputs on each clock cycle and
updates the counter appropriately.  It works as long as the clock
is faster than the time between actual edges (including any bounce).

If the signals can bounce long enough for the encoder to get
to the next edge, it is not possible to uniquely decode the
signal.   If the encode sits right on an edge, continually
bouncing, the counter may miss some back transitions, but it
also won't count the matching forward transition.

If you worry about metastability in the latch, add a second
latch.

-- glen


Article: 131596
Subject: Re: the order in which some switches are turned on
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 25 Apr 2008 12:49:32 -0800
Links: << >>  << T >>  << A >>
laura wrote:

> I have an array of N switches . Initially all are OFF.

> Somebody turns them ON in some order. It is possible that more
> switches are turned ON in the same moment.

Depending on your definition of 'the same moment', and realizing
that real switches often bounce.

> I need a device which shows me the order in which the switches were
> turned ON. For instance the device should give me: 4,3,1,5,2 (this is
> the order in which the switches were turned ON).

Latch the switch inputs, latch the latch output, and compare them.
(Use XOR gates.)   A priority encoder will tell you which one
changed.   More logic will detect any multiple switch transitions,
but if you have a fast enough clock, those should be rare.

> The way in which the output is shown in not important. It must be
> simple to read (by a human, computer, etc).

> It is important that the device is able to handle the turned ON (in
> the same moment) of the multiple switches.

Are you only detecting ON transitions, and ignoring any that go OFF,
then on again?  In that case, have the second latch only detect
ON transitions.  You will need a reset signal to start over again.

My favorite switch/logic puzzle from many years ago:

You have a long hallway with N lights.  There is a switch at each
end, and one between each light (N+1 switches total), such that you
can walk down the hall flipping switches.  Each one will turn on the
light in front of you, and turn off the light behind.

Assuming only switches, light bulbs, and a power source (no computers
or logic gates), what is the simplest switch configuration needed
to make this work.  (For example, SPST, SPDT, DPST, DPDT, etc.)
How should the switches and lights be wired up?

-- glen


Article: 131597
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 25 Apr 2008 13:59:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 9:24=A0am, Peter Alfke <pe...@xilinx.com> wrote:
> Well, this is a challenge.
>
> I am working on a design that uses 4 LUTs and 4 flip-flops,
> takes in raw A and B inputs plus a clock
> and outputs synchronously decoded CE and U/D signals to control a
> binary counter.
> There are 3 configuration options: 1, 2, or 4 counts per 360 degree
> contact cycle.
> And bounce is suppressed, and kept away from the counter =A0:-)
>
> "Everything you always wanted to have in a quadrature detector'"
> Peter

The design is done, we are finishing documentation, and Ken Chapman
has graciously agreed to give it a thorough hardware test net week:
4 LUTs, 4 flip-flops, insensitive to contact bounce or any type of
erratic mechanical movement.
1, 2, or 4 counts per encoder cycle (i.e. 90, 180 or 360 degrees
between counts, as a config option)
"The end of all discussions about quadrature encoders, mechanical or
optical."
Peter Alfke

Article: 131598
Subject: Re: -. . .-- ... --. .-. --- ..- .--.
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 25 Apr 2008 14:01:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Austin,

It's great the things that you do outside Xilinx (also).  I just feel
for anyone trying to understand your dots and dashes since you
corrected your "neusgrouop" to "neusgruop."  :-)

Your wife's description of that quake was hysterical!

.... .- .--. .--. -.--
..-. .-. .. -.. .- -.--
- John_H

Article: 131599
Subject: Re: Spartan3 "commercial" temperature range
From: dalai lamah <antonio12358@hotmail.com>
Date: Fri, 25 Apr 2008 21:05:31 GMT
Links: << >>  << T >>  << A >>
Un bel giorno Peter Alfke digitò:

> I can answer this, because I was the one who "did it".
> This is not a Spartan issue, it was established about 15 years ago,
> and applies to all Xilinx FPGAs

For some reason I was convinced that Spartan II were still codified with
the "traditional" ambient temperature ranges, but you are right: even S2
are codified with Tj.

> and it would not surprise me if
> Altera now uses the same reasoning.

I've never used Altera parts, but I know for sure that all the Actel parts
(CPLD and FPGA, either flash and antifuse) are specified with the
traditional temperature ranges, 0/+70 and -40/+85 ambient.

Even Xilinx still does it for the CPLDs: for example XC9500* are available
in 0/+70 and -40/+85 ambient temperature.

> We soon realized that "ambient" is a meaningless number for a
> progarmmable part, where the self-heating power consumption can vary
> by several orders of magnitude. The decisive limitation is junction
> temperature, no chip really cares about ambient temperature per se.
> 
> So we decided, against some customer complaints, to define
> "commercial" byits junction temperature, and we raised the top by 15
> degrees, to allow for power dissipation and thermal resistance.
> We told our customers that "ambient" was obviously more easy to
> control and measure, but was meaningless as a chip limitation for
> programmable logic.

I was genuinely convinced that -40/+100 °C was the working ambient
temperature for a "typical" design, and the +125 °C reported in the maximum
ratings was the maximum working Tj. Until now I've always used FPGAs in
designs with high logic densities but very low clock frequencies, therefore
I've rarely had to extimate the power generated by the FPGA. I'm not
surprised that I've never noticed this problem: in my designs Ta and Tj are
very close.

Now if I've understood correctly, you are saying that I need to use Tj=+85
or +100 instead of the +125 maximum rating, and therefore the meaning of
this maximum rating is something like: "at 125 °C the part won't fry, but
won't work either"? :-)

-- 
emboliaschizoide.splinder.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