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
2017JanFebMarApr2017

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 24975

Article: 24975
Subject: Re: create a RAM in a Virtex
From: Ray Andraka <ray@andraka.com>
Date: Wed, 23 Aug 2000 11:58:54 GMT
Links: << >>  << T >>  << A >>
Each block ram is up to 16 bits wide, at which point is 256 words deep.  Is
there a reason you can't use 13 block RAMs to get your 200 bit width?  Each of
course would need an identical address, which depending on your speed
requirements might dictate duplicated address and control logic. Another
'trick', which is useful if you only need a single port memory and 128 words is
deep enough, is to use both ports to get an effective width of 32 bits.  In that
case, you tie the upper address bit on one port to '1' and the same address bit
on the other port to '0'.  The remaining address bits as well as the controls
are common, and presto, you've got a single port 32 bitx128 word memory in one
block ram.  That will get you up to 256 bits wide in an XCV50, without any fancy
addressing or double access garbage.

I find the COREGen to be more of a hinderance than a help for the BRAMs.  It's
not like it adds any useful logic, all it does is instantiate the required
number of BRAMs.  I think it is easier, and frankly, more intuitive to just
instantiate the BRAMs directly.

Gerhard Griessnig wrote:
> 
> I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool.
> 
> My problem is that my RAM has a width of  200 bits.
> 
> Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a
> complex addressing.
> 
> Futhermore i tryed to create a RAM with the XILINX Coregenerator but i got an
> error message
> 
> Error   L-44/C0 : #0 Error:
> D:/programs/xilinx/active/projects/grieda02/ram.vhd  line -44   Library
> logical name XILINXCORELIB is not mapped to a host directory. (VSS-1071)
> (FPGA-dm-hdlc-unknown)
>  Error   L48/C0 : #0 Error:
> D:/programs/xilinx/active/projects/grieda02/ram.vhd  line 48   No selected
> element named C_MEM_SP_BLOCK_V1_0 is defined for this prefix.  (VSS-573)
>  2 error(s) 0 warning(s) found
> 
> Does anyone has an idea, or does anyone has a vhdlcode ?
> 
> THANKS Gerhard
> 

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 24976
Subject: Re: Metastability and antifuze
From: rk <stellare@nospamplease.erols.com>
Date: Wed, 23 Aug 2000 08:05:14 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> What sort of metastability data is available for antifuze parts?

[1] "Metastability Report for FPGAs," Quicklogic Data
    Book, 1994, pp. 523-526.

    They show the circuit used, the formulas, and give
    tables of taw and w.  This is for pASIC 1.  They
    also give a graph comparing metastable performance
    of Quicklogic, Actel, and Xilinx.

[2] Actel Data Book, 1992, pp. 5-1 to 5-2.

    This was how the data was referenced in the
    Quicklogic report.  I remember that in the 1992
    book there was a report on Act 1 metastable state
    performance.  Stretching the memory cells, I believe
    it was on the older versions of this.  I think
    there were two volumes of the book in 1992, one of
    which was a designer's guide consisting of application
    notes.  I'll dig out the reference if anyone is
    interested.

================================

> How do ASIC vendors get metastability data?

I have data books from Chip Express handy for the QYH500, CX2000, and
the CX3000 series.  I only found metastability information in the CX2000
book - perhaps the eyes aren't quite working yet.  They do supply a nice
discussion of the effect and a comprehensive table of values for each of
their flip-flops. The text doesn't describe any test circuits or how the
values were obtained.  Using the search engine on their www site for
"metastable," I received 0 hits.

================================

Here's a definition of "fuze" from www.dictionary.com:

     fuze n : any device by which an explosive charge is ignited
     [syn: fuse, fusee, fuzee, primer]

:-)

rk

Article: 24977
Subject: Re: timing simulation vs functional one
From: Ray Andraka <ray@andraka.com>
Date: Wed, 23 Aug 2000 12:05:40 GMT
Links: << >>  << T >>  << A >>
As I mentioned earlier, I've run into this too.  You can also solve the problem
by just setting the TimingChecksOn generic in the unisim clocked logic elements
to FALSE when you instantiate the component.  I automatically just add the
generic in the component declaration and it is done.  For example:

Architecture mixed_structural_and_RTL of doomsday_machine is
	-- Component declaration of the "SRL16E(SRL16E_V)" unit
	-- File name contains "SRL16E" entity: .\src\unisim_VITAL.vhd
	component SRL16E
	-- synthesis translate_off
	generic(
		TimingChecksOn : BOOLEAN := FALSE);	
	--synthesis translate_on
	port(
		D : in std_ulogic;
		CE : in std_ulogic;
		CLK : in std_ulogic;
		A0 : in std_ulogic;
		A1 : in std_ulogic;
		A2 : in std_ulogic;
		A3 : in std_ulogic;
		Q : out std_ulogic);
	end component;
	attribute syn_black_box of SRL16E : component is true;

	-- Component declaration of the "FDE(FDE_V)" unit
	-- File name contains "FDE" entity: .\src\unisim_VITAL.vhd
	component FDE
	-- synthesis translate_off
	generic(
	TimingChecksOn : BOOLEAN := FALSE);	
	--synthesis translate_on
	port(
		Q : out std_ulogic;
		D : in std_ulogic;
		C : in std_ulogic;
		CE : in std_ulogic);
	end component;
 	attribute syn_black_box of FDE : component is true;

	--other declarations
begin
	U1:SRL16E port map(
		D=>t_in(i),
		CE=> ce,	   
		A0=>dqa(0),
		A1=>dqa(1),
		A2=>dqa(2),
		A3=>dqa(3),
		Q=>ff_d,
		clk=>clk); 	 
	U2:FDE port map(
		Q=>t(i),	   
		D=>ff_d,
		C=>clk,
		CE=> ce);	  



"K. Orthner" wrote:
> 
> Regarding functinoal simluations that fail, but timing simulations that
> pass; there may be another problem.
> 
> (I ran into this a while back, and had to scratch my head for quite a while
> to figure it out.)
> 
> Often, the libraries that come with a simulator for a given target part
> contain minimum timing delays.  An example is the "Unisim" library that
> comes with the Aldec VHDL simulator, for Xilinx parts.  In many cases, it
> assumes a "minimum" delay of 0.01 ns, or something.
> 
> If you happen to instantiate some parts, but infer others, you can run into
> problems with your functional simulation.
> 
> In my case, I inferred an IBUFG for my clock inputs, but just left the
> other inputs as regular inputs, letting the place-and-route software add
> the IBUF/OBUFs automatically.  When I ran my simulation, my data would
> arrive inside the chip 0.01 ns before my clock signals.
> 
> If I did the post-timing simulation, it was okay, since at that time, all
> of the inputs used IBUFs with non-zero delays.
> 
> I solved this by recompiling a copy of the unisim library with all of the
> timing parameters set to zero, and then using *that* library when
> simulating.
> 
> I hope this helps.
> 
> -Kent

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 24978
Subject: Re: Non-disclosures in job interviews, Round One
From: frank_mckenney@mindspring.com
Date: 23 Aug 2000 12:51:02 GMT
Links: << >>  << T >>  << A >>
In <39A29BC5.949D50D1@pacbell.net>, Neil Nelson <n_nelson@pacbell.net> writes:
--snip--
><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
><html>
>  <head>
>    <title>Anonymous Remailers</title>
>  </head>
--snip--

Neil,

Please don't post HTML, particularly irrelevant HTML.

Thank you.


Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
E-mail: frank_mckenney@mindspring.com

Article: 24979
Subject: run time doubled with Xilinx 3.1i upgrade
From: "Dan Kuechle" <dan_kuechle@i-tech.com>
Date: Wed, 23 Aug 2000 13:17:56 GMT
Links: << >>  << T >>  << A >>
My Virtex 400 design that placed and routed in 2 - 2.5 hours with 2.1i
(on a 350 mhz PC) is now taking 4 - 5 hours with 3.1i (with service pack 
2 installed).  The routing delays and timing look no better or no worst
than 2.1i.
Is anyone else seeing these longer run times?
Article: 24980
Subject: Re: Non-disclosures in job interviews, Round Two
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 23 Aug 2000 09:38:19 -0400
Links: << >>  << T >>  << A >>
Jon Kirwan wrote:
> 
> On Wed, 23 Aug 2000 01:25:53 -0400, rickman <spamgoeshere4@yahoo.com>
> wrote:
> >A Background questionnaire release form,
> 
> Release form for exactly what?

For a background check by a private investigator! The investigating
company is PROFILES PLUS, INC. I have to authorize all "corporations,
companies, credit agencies, financial institutions, educational
institutions, persons, law enforcement agencies, former employers and
the Military services to release all written and verbal information
about me to PROFILES PLUS, INC." I also have to release these sources
from liability. The agreement survives for "future reports or updates
that may be requested". 

 
> >Then they want me to leave behind a urine sample for drug testing.
> 
> As a condition of employment, this has gotten to be quite common.
> I've been through that several times, although I keep reminding myself
> how much I absolutely love poppy seed strudel at about this time.  I
> keep wondering if the rumors are true...
> 
> But before you have completed negotiations???  No offer?  No pee.
> Their only argument is, once again, they'd like to save time on you if
> you fail.  Frankly, I don't care.  They will just have to invest a bit
> in me and expect the best.

I had to do this once before when I interviewed with a DOD contractor.
After talking with them about the avenues of recourse in the event that
I failed, I realized that 

1) there was no recourse,

2) they did not acknowledge that a drug test can be wrong. It can be
wrong for a large number of reasons; poppy seeds (yes that is true),
prescription drugs, and many "medicinal" herbs sold in health food
stores.

3) to make sure that I could not dispute the result of the test it was
given at the interview so that if it was failed they would simply not
make an offer. You would never know that you failed the drug test.

 
> >And more importantly, I will not provide such an authorization to use
> >this information without an opportunity for me to dispute any erroneous
> >information contained in these reports.
> 
> They probably don't even have a policy, other than not continuing
> discussions.  The two times I asked, I was told that they do NOT
> provide another opportunity to be tested and that the results, false
> positive or otherwise, are invariably accepted as final.  But never
> was this asked as part of the interview.

This is exactly the problem. You lose all control over the results of
the tests. In fact, they don't even promise to keep the results
confidential!

 
> >I have heard of people who were fired from their jobs based on incorrect
> >credit information from fradulent use of their identities by other
> >people.
> 
> Hopefully, this isn't too serious of a problem.  I've heard those
> stories, too.  Probably on some "news" program.

I have heard this on several of the "investigative" television programs
like 20-20. Some are due to mistakes in the credit report that were hard
to have removed. Others were due to another person impersonating the
worker and commiting crimes. This resulted in a police file which said
that warrents were outstanding. Even after clearing the matter up with
the police and getting it in writing, the worker was dismissed from the
job. It really ruined their life. 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24981
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: David Kessner <davidk@free-ip.com>
Date: Wed, 23 Aug 2000 08:26:45 -0600
Links: << >>  << T >>  << A >>
Dan Kuechle wrote:
> My Virtex 400 design that placed and routed in 2 - 2.5 hours with 2.1i
> (on a 350 mhz PC) is now taking 4 - 5 hours with 3.1i (with service pack
> 2 installed).  The routing delays and timing look no better or no worst
> than 2.1i.
> Is anyone else seeing these longer run times?

I've seen multiple problems with 3.1i that I'm still trying to sort
out.  Some of the problems are:

	- FF's not being put into IOB's when F2.1i successfully put 
	  them there (Spartan-II).  This was not fixed with SP2.
	- More logic resources being taken up (separate than what 
	  was covered in one of their "Answers" Database).
	- PAR times 2 to 4 times longer.

The first one is amusing, since it is very obvious but somehow
slipped through their QA.  Unfortunately that's where the amusement
ends.  I have a project that is in limbo because of that bug.  I've
been trying to create a work-around, but it is difficult given the 
much longer PAR times (1 hour vs 15 minutes).

David Kessner
davidk@free-ip.com
Article: 24982
Subject: Re: Non-disclosures in job interviews, Round Two
From: Neil Nelson <n_nelson@pacbell.net>
Date: Wed, 23 Aug 2000 08:10:35 -0700
Links: << >>  << T >>  << A >>
Jon Kirwan wrote:

> >Now I have been giving a suggesting/question of which the response is
> >as yet absent: why do we not post the company names with the behavior
> >we have a problem with?

>  You want to start?

I have not yet indicated that there is a company whose behavior I have a
problem with, unlike others in this thread.  Why are they so determined not
to disclose company names that they surely must know?

I would not, of course, suggest signing anything without reading it, but how

many of us read the fine legalistic print, though we perhaps should, on
every
agreement and rather depend on a common understanding with a reputable
person or company.

Because we not giving company names and, as we are apparently concerned
with the details of these agreements, the specific passages of the
agreements
about which we are concerned, it tends to reduce the credibility that there
are
any such companies or problem agreements.  We maybe concerning
ourselves with some extremely rare or imaginary conditions.

Rick Collins wrote:

> A completed application,
>
> A "consumer report" (otherwise known as a credit check) authorization,
>
> A Background questionnaire release form,
>
> Then they want me to leave behind a urine sample for drug testing.
>
> I can see the potential need for all of these things even if I don't
> agree that they should be used for employment screening. But I strongly
> disagree with the requirement to authorize them prior to an interview.
> And more importantly, I will not provide such an authorization to use
> this information without an opportunity for me to dispute any erroneous
> information contained in these reports. In fact I am not given any idea
> of how the information will be evaluated. Finally the company retains
> the right to perform further checks in the future (if hired) for
> "deciding whether to continue your employment", and " when making other
> employment related decisions directly affecting you".
>
> I have heard of people who were fired from their jobs based on incorrect
> credit information from fradulent use of their identities by other
> people.
>
> I am sure that this will get responses both pro and con to the reasons
> that a company may feel the need to "protect" themselves against harm
> from an employee. But these agreements go far beyond "protecting" a
> company and can very easily be used against an employee to permit
> dimissal without recourse or even explanation.

I disagree.  These requests do not create a continuing liability on the
employee as against the case of a long term NDA that may be expected to
continue beyond employment.  There will likely be, as indicated,
subsequent requests for credit reports and urine samples, but these are not
particularly onerous.  But primarily, each requirement or screen placed on
an applicant reduces the effective number of people that may be accepted
with the result that the supply of labor is reduced (in what has been said
is
already a job seeker's market) such that some reward would flow to that
reduced supply.  Or more generally, if you want a higher quality product,
you are going to pay more.  Whether or not this company is overbearing,
confused, or just doing what would be expected will be better determined
once we have more information about the company.  And though I would
not be combative about these things if you decide to go to the interview, it

seems quite appropriate and expected as a normal process of interviewing
the company to ask them why they have these requirements on applicants
that other companies to not.

We seem to be making an assumption that all companies should have the
same requirements in these indicated categories for all employees.  This is
obviously not the case.

These fears that some terrible thing may happen because we essentially
become less private for some purposes I suggest, as above, needs to be
given a concrete, objective basis.  I am sure that all manner of crazy,
illegal,
or unethical actions have been taken by some companies and/or individuals
at some time, but what is their effective relevance in the current case?
(And this is another reason why we need specific names and actions so that
we can deal with that apparently smaller proportion that is a problem
instead
of globally characterizing a large number for which there is no problem.)
A meteorite may strike any one of us dead today, but we do not worry
about it.

Regards,

Neil Nelson


Article: 24983
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 23 Aug 2000 11:13:50 -0400
Links: << >>  << T >>  << A >>
David Kessner wrote:
> 
> Dan Kuechle wrote:
> > My Virtex 400 design that placed and routed in 2 - 2.5 hours with 2.1i
> > (on a 350 mhz PC) is now taking 4 - 5 hours with 3.1i (with service pack
> > 2 installed).  The routing delays and timing look no better or no worst
> > than 2.1i.
> > Is anyone else seeing these longer run times?
> 
> I've seen multiple problems with 3.1i that I'm still trying to sort
> out.  Some of the problems are:
> 
>         - FF's not being put into IOB's when F2.1i successfully put
>           them there (Spartan-II).  This was not fixed with SP2.
>         - More logic resources being taken up (separate than what
>           was covered in one of their "Answers" Database).
>         - PAR times 2 to 4 times longer.
> 
> The first one is amusing, since it is very obvious but somehow
> slipped through their QA.  Unfortunately that's where the amusement
> ends.  I have a project that is in limbo because of that bug.  I've
> been trying to create a work-around, but it is difficult given the
> much longer PAR times (1 hour vs 15 minutes).
> 
> David Kessner
> davidk@free-ip.com

I am not trying to be dense, but why can't you go back to the 2.1 tools
if this is holding up your project?


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24984
Subject: Re: Metastability and antifuze
From: rk <stellare@nospamplease.erols.com>
Date: Wed, 23 Aug 2000 11:25:26 -0400
Links: << >>  << T >>  << A >>
Elftmann wrote:

> Actel set out on the same mission to characterize metastability
> characteristics in our newer devices, but ran into the same problem as the
> Xilinx team did.  I'll check back with Product Engineers next week and see
> where it sits on the priority list these days.  As a result of past
> discussions in this group I continue to push on Product Engineering to make
> metastability characterization standard operating procedure.

Yes, please continue to PUSH.  This should be part of the product
specification.  If an exact number can not be found, than a bounded limit
should be specified so that designers can do a bounded analysis.

Going through a lot of companies' data books and application notes, some are
quite good, others do a little, others do none.  Up to date information is
critical.  As some of the manufacturer's produce products for the
high-reliability applications, that information is really required.

----------------------------------------------------------------------
rk                               History will remember the twentieth
stellar engineering, ltd.        century for two technological
stellare@erols.com.NOSPAM        developments: atomic energy and
Hi-Rel Digital Systems Design    space flight. -- Neil Armstrong, 1994

Article: 24985
Subject: Re: Metastability and antifuze
From: rk <stellare@nospamplease.erols.com>
Date: Wed, 23 Aug 2000 11:27:35 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Metastability is caused by the (limited) gain bandwidth product of the
> master latch in the flip-flop. As such it has nothing to do with the
> programming technology. Xilinx ( and Altera :-) ) flip-flops are
> hard-implemented, optimized structures that contain no programming
> elements in the critical path.
> I suppose the same is true of most ASICs. The original Actel devices
> composed their latches out of multiplexers, and we always pointed out
> their (theoretically) poor metastable performance. I assume that Actel
> now also has "hard-coded" flip-flops. (?)

As Dan replied, they do have "hard-coded" flip-flops although one can make
"soft-coded" flip-flops in any of the other familes using logic resources.

Now, my question:  Is "hard-coded" the standard term?  I have been using
"hard-wired" and "routed" to describe flip-flops in programmables.

Comments?

Thanks,

rk

Article: 24986
Subject: Re: Some notes on metastability
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 23 Aug 2000 15:28:50 GMT
Links: << >>  << T >>  << A >>


Jim Granville wrote

>  Does that mean these chips are getting worse / degraded to the point
> you are then able to measure metastable events again ;-)
> ( I know it's not what you meant, but it's {almost} what you said )

That's obviously not what I meant, and not what I said.  :-(

Are the summer doldrums getting to us? Nothing meaningful to say, so we
start posting about line breaks, create deliberate silly misunderstandings
and have a hundred posts about NDAs during job interviews. And Moore vs
Mealy ad infinitum...
Must mean that there are no more serious subjects to talk about.

Peter


Article: 24987
Subject: Re: Metastability and antifuze
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 23 Aug 2000 15:38:07 GMT
Links: << >>  << T >>  << A >>


rk wrote:

> Elftmann wrote:
>
> >  This should be part of the product
> specification.  If an exact number can not be found, than a bounded limit
> should be specified so that designers can do a bounded analysis.
>

As long as we understand:
There is no limit, and there will not be any limit, ever.
It is a statistical thing, and we can only promise an MTBF.

I have published Xilinx metastability test circuits and results in every data
book since 1989.
And we will, again, for the newer parts (Virtex).
For the reasons that I described, they got a little long in the tooth in recent
years.

Peter Alfke

Article: 24988
Subject: Re: Non-disclosures in job interviews, Round One
From: Neil Nelson <n_nelson@pacbell.net>
Date: Wed, 23 Aug 2000 09:00:38 -0700
Links: << >>  << T >>  << A >>
frank_mckenney@mindspring.com wrote:

> In <39A29BC5.949D50D1@pacbell.net>, Neil Nelson <n_nelson@pacbell.net> writes:
> --snip--
> ><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
> ><html>
> >  <head>
> >    <title>Anonymous Remailers</title>
> >  </head>
> --snip--
>
> Neil,
>
> Please don't post HTML, particularly irrelevant HTML.
>
> Thank you.
>
> Frank McKenney, McKenney Associates
> Richmond, Virginia / (804) 320-4887
> E-mail: frank_mckenney@mindspring.com

I can avoid the HTML.  As to relevancy, I would say it is very
relevant, the reasons of which were given in that post.  Would
you care to give an argument as to why it is not relevant?

Regards,

Neil Nelson


Article: 24989
Subject: Re: Non-disclosures in job interviews, Round One
From: Neil Nelson <n_nelson@pacbell.net>
Date: Wed, 23 Aug 2000 09:21:41 -0700
Links: << >>  << T >>  << A >>
"Paul E. Bennett" wrote:

> In article <39A375B6.1BC937B9@pacbell.net>
>            n_nelson@pacbell.net "Neil Nelson" writes:
>
> > I think I have said that NDAs for the purpose of an interview are of
> > little material relevance one way or the other such that it should not
> > be a critical factor in interviewing with a company.  I.e., if I
> > understood that the NDA was for the purpose of the interview I would
> > sign it.
>
> Many legally binding documents have a much longer term associated than
> you realise. My legal guides always tell me to read the document and
> understand its implications before I sign it. If the terms do not seem
> fair to both parties then do not sign the document until it has been
> corrected to reflect such fairness.
>
> We as logicians (I would hope all of us here are anyway) we can often
> be better placed than legal counsel at spotting when the logic of an
> agreement is broken. As I stated before, I live just 3 miles from one
> establishment where the visitors register contains a (very fair) NDA.
> I have no problem signing theirs when visiting them (I still read it
> every time before signing though). I have, however, massively carved
> other NDA's about when the emphasis was too much in favour of the other
> party. So that is the test. Is the document fair to both parties.

I have not said: do not read the document before signing it.  But I am
wondering specifically what passages should we be concerned with to
a degree that would cause us to not sign it?  I understand that an NDA
for the purposes of an interview to be that if the company divulges during
the interview company specific information of a nature that would damage
the company if made widely known or known to another company, that this
information should not be made widely known or known to another
company.

Perhaps what we are calling an NDA consists, in our different
interpretations,
of a variety of things that might be better labeled differently.

Does anyone have a document with a specific passage that they hold
objectionable and can post?

Regards,

Neil Nelson


Article: 24990
Subject: Re: timing simulation vs functional one
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 23 Aug 2000 16:31:28 GMT
Links: << >>  << T >>  << A >>
I think Xilinx needs to fix the Unisims library. I can't think of any
reason why it should contain default timing information, given that
it's meant for functional sims. IIRC, the problem didn't exist before
DLLs were added to the library. Before DLLs, you could set a timing
resolution of nanoseconds in your sim, and all the sub-nanosecond
default delays in the library were magically truncated to zero, which
is required for a functional sim. DLL functional sims require a
picosecond timing resolution, and suddenly all those 10ps defaults in
the library become real requirements, which you can't meet in a
unit-delay simulation. So, if you haven't got a DLL in your design,
the simple fix is to set your sim to nanosecond resolution. If you
have got a DLL, then my own preference is to turn off timing checks on
the simulator command line or GUI - for ModelSim it's 'vsim
+notimingchecks', for example.

Evan
Article: 24991
Subject: Re: xdl documentation
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 23 Aug 2000 16:31:50 GMT
Links: << >>  << T >>  << A >>
On Mon, 21 Aug 2000 17:09:14 -0700, Philip Freidin
<philip@fliptronics.com> wrote:

>
>Send a request to
>    xdl_support@xilinx.com
>
>On Mon, 21 Aug 2000 21:19:14 GMT, William Chow <choww@eecg.utoronto.ca> wrote:
>>I'm looking for documentation on the Xilinx xdl file format. I've tried
>>looking for it off Xilinx's support page. Can't get to it. Can someone
>>help me out?

I seem to remember this resulting in a response that it wasn't
supported. You can get the docs by installing the userware option if
you haven't already done so, and looking for
$XILINX/userware/doc/xdl.html.

Evan 
Article: 24992
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: David Kessner <davidk@free-ip.com>
Date: Wed, 23 Aug 2000 10:33:30 -0600
Links: << >>  << T >>  << A >>
rickman wrote:
> I am not trying to be dense, but why can't you go back to the 2.1 tools
> if this is holding up your project?

If Xilinx doesn't resolve this issue within the next day or two 
then I will return to 2.1i.  As will many other Xilinx users, I'm
sure.

Take a look at the following code:

	entity test is
	  port (reset	:in    std_logic;
	        clk	:in    std_logic;
	        din	:in    std_logic_vector (7 downto 0);
	        dout	:out   std_logic_vector (7 downto 0)
	       );
	end test;
	
	architecture arch_test of test is
	  signal a	:std_logic_vector (din'range);
	  signal b	:std_logic_vector (din'range);
	  signal c	:std_logic_vector (din'range);
	begin
	  process (reset, clk)
	  begin
	    if reset='1' then
	      a <= (others=>'0');
	      b <= (others=>'0');
	      c <= (others=>'0');
	    elsif clk'event and clk='1' then
	      a <= din;
	      b <= a;
	      c <= b;
	    end if;
	  end process;
	
	  dout <= c;	
	end arch_test;

Essentially there are three 8-bit wide registers.  The tools should 
place two of these registers in the IOB's.  When compiling for a
5 volt Spartan it does.  But when compiling for Spartan-II or Virtex
it will not use the IOFF's.  

I can't speak for everyone, but I can say that _ALL_ of my designs
do something similar to the above code so _ALL_ my my designs would
have problems with 3.1i.  It would be a safe guess that at least a
significant percentage of the FPGA designers out there would also
have problems.  It's <insert your favorite verb> that this type of 
bug wasn't found by Xilinx's own internal test suite and/or QA
department.

David Kessner
davidk@free-ip.com
Article: 24993
Subject: Re: Metastability and antifuze
From: rk <stellare@nospamplease.erols.com>
Date: Wed, 23 Aug 2000 12:34:52 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> rk wrote:
>
> > Elftmann wrote:
> >
> > >  This should be part of the product
> > specification.  If an exact number can not be found, than a bounded limit
> > should be specified so that designers can do a bounded analysis.
> >
>
> As long as we understand:
> There is no limit, and there will not be any limit, ever.
> It is a statistical thing, and we can only promise an MTBF.
>
> I have published Xilinx metastability test circuits and results in every data
> book since 1989.
> And we will, again, for the newer parts (Virtex).
> For the reasons that I described, they got a little long in the tooth in recent
> years.

Oops, perhaps I didn't write quite clearly enough.

If we can get numbers that specify at least how good the devices will be, then that
would be beneficial.  The limits I specify are on the parameters to plug into the
equations for MTBF, which some manufacturers provide for engineer's use in
calculating MTBF for their circuit.  So, even if the calculated MTBF is wrong, as
long as it is wrong in the conservation direction, I would be happy.  With
measurements that I make at day job, even when getting a null response, because of
the statistical nature of the measurements, a bound is provided.  For example, for
SEU measurements, which apply equally to Xilinx and Actel parts, for example, a
test is frequently run with a certain fluence, measured in particals/sq. cm.  One
can get a perfect measurement if one exposes the part to a VERY LARGE number of
particles per sq. cm.  But how much is enough?  10^6 p/cm^2?  Many have used that
as a standard.  How large is your flip-flops?  Pretty small, I'm sure, particularly
at the lower feature sizes.  Is 10^7 p/cm^2 enough?  Much more than that and the
measurements become not that practical to run.  While there are many flip-flops and
that helps with the measurements, in some cases one can't count on that, like a
reset state flip-flop, TAP controller flip-flops, etc.  In any event, in those
types of measurements, it is standard, when a null result is observed, it is
assumed that a single event could have occurred and that is used for the
calculation of the estimated bound, with a note attached (or by use of a special
symbol) that no errors were detected.  That's sort of what I was looking for here.
Then we can do bounded calculations for a particular sitiuation and then hopefully
say: "We got plenty of margin and we knot that Peter's or Dan's number were
conservative on top of that."  That works better than saying, Peter and Dan say
their flip-flops are GREAT! <in the tone of Tony the Tiger> and we won't have any
problem.

Yes, metastable state resolution time is a statistical thing and no one has shown a
circuit to bound that, that has been accepted by the general community.  There,
that should prevent us from re-opening that can of worms!  :-)

Thanks!

rk

Article: 24994
Subject: Re: Some notes on metastability
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 23 Aug 2000 12:56:58 -0400
Links: << >>  << T >>  << A >>
Ben Franchuk wrote:
> 
> Peter Alfke wrote:
> 
> > Are the summer doldrums getting to us? Nothing meaningful to say, so we
> > start posting about line breaks, create deliberate silly misunderstandings
> > and have a hundred posts about NDAs during job interviews. And Moore vs
> > Mealy ad infinitum...
> > Must mean that there are no more serious subjects to talk about.
> 
> Yes - we have to get back to "Use only Xlinix Parts"
> "No open source of FPGA's" "No Free software tools" "My latest RISC cpu"
> "My latest Forth cpu" "Why suppliers can't supply products" "Who has the
> fastest chip (Not counting routing delays)".

You've got a Forth cpu???  Tell us all about it! 

;)


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24995
Subject: Re: Mealy vs Moore FSM model
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 23 Aug 2000 10:01:45 -0700
Links: << >>  << T >>  << A >>
"Jimmy Roberts" <j_robby@hotmail.com> writes:

> Hi Folks,
> 
> What are the advantages and disadvantages of using Mealy model of FSMs vs
> Moore model, on FPGA.
> In Mealy model, the outputs depends on the states only, whereas in Moore
> model, the outputs depend on the states and the actual inputs. I presume
> Mealy model is better (less combinatorial logic). Do you agree? Any other
> thoughts.

Since in a Mealy state machine the output vector depends both on the state
and the inputs, usually you need less states to achieve your goal compared to
a Moore machine. The price that you pay is going through the additional
combinational logic from the inputs to the outputs, which may add
delay to the critical timing path.

-Arrigo

Article: 24996
Subject: Re: run time doubled with Xilinx 3.1i upgrade
From: bob_42690@my-deja.com
Date: Wed, 23 Aug 2000 17:11:32 GMT
Links: << >>  << T >>  << A >>
David,
  When I looked at 3.1i for virtex under implementation, option,
optimize and map, in program options, there was a choice pack  I/O
registers into IOB's for Inputs, outputs, both or none.  The default on
my set-up is none.  Have you tried this, or are you saying it does not
work?

Bob

In article <39A3FCDA.D7749279@free-ip.com>,
  davidk@free-ip.com wrote:
> rickman wrote:
> > I am not trying to be dense, but why can't you go back to the 2.1
tools
> > if this is holding up your project?
>
> If Xilinx doesn't resolve this issue within the next day or two
> then I will return to 2.1i.  As will many other Xilinx users, I'm
> sure.
>
> Take a look at the following code:
>
> 	entity test is
> 	  port (reset	:in    std_logic;
> 	        clk	:in    std_logic;
> 	        din	:in    std_logic_vector (7 downto 0);
> 	        dout	:out   std_logic_vector (7 downto 0)
> 	       );
> 	end test;
>
> 	architecture arch_test of test is
> 	  signal a	:std_logic_vector (din'range);
> 	  signal b	:std_logic_vector (din'range);
> 	  signal c	:std_logic_vector (din'range);
> 	begin
> 	  process (reset, clk)
> 	  begin
> 	    if reset='1' then
> 	      a <= (others=>'0');
> 	      b <= (others=>'0');
> 	      c <= (others=>'0');
> 	    elsif clk'event and clk='1' then
> 	      a <= din;
> 	      b <= a;
> 	      c <= b;
> 	    end if;
> 	  end process;
>
> 	  dout <= c;
> 	end arch_test;
>
> Essentially there are three 8-bit wide registers.  The tools should
> place two of these registers in the IOB's.  When compiling for a
> 5 volt Spartan it does.  But when compiling for Spartan-II or Virtex
> it will not use the IOFF's.
>
> I can't speak for everyone, but I can say that _ALL_ of my designs
> do something similar to the above code so _ALL_ my my designs would
> have problems with 3.1i.  It would be a safe guess that at least a
> significant percentage of the FPGA designers out there would also
> have problems.  It's <insert your favorite verb> that this type of
> bug wasn't found by Xilinx's own internal test suite and/or QA
> department.
>
> David Kessner
> davidk@free-ip.com
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24997
Subject: Re: Non-disclosures in job interviews, Round Two
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Wed, 23 Aug 2000 10:14:34 -0700
Links: << >>  << T >>  << A >>
On Wed, 23 Aug 2000 08:10:35 -0700, Neil Nelson <n_nelson@pacbell.net>
wrote:

>These requests do not create a continuing liability on the
>employee as against the case of a long term NDA that may be expected to
>continue beyond employment.

Didn't rickman say the following?

>>Finally the company retains
>>the right to perform further checks in the future (if hired) for
>>"deciding whether to continue your employment", and " when making other
>>employment related decisions directly affecting you".

You might dispute rickman's interpretation, but I believe you have no
basis for doing so from his post.  Certainly, you have absolutely no
evidence from rickman's post that would allow you to properly say,
"these requests do not create a continuing liability..."

I'd consider any document that suggests to rickman that they can use
his permission at a later time, as rickman suggests it would do, as
being a "continuing liability."  If not "liability", then at least it
should be a concern of his.

We can argue the semantics of this word and that, but the essence is
simply that there is no good reason for a company to ask anyone to
sign such a document, particularly if it seems to allow the other side
to use its power from time to time, at their discretion.  Further,
such things may make sense as a condition of employment, but can't
possibly be justifiable as a condition of further talks.


>There will likely be, as indicated,
>subsequent requests for credit reports and urine samples, but these are not
>particularly onerous.  But primarily, each requirement or screen placed on
>an applicant reduces the effective number of people that may be accepted
>with the result that the supply of labor is reduced (in what has been said
>is already a job seeker's market) such that some reward would flow to that
>reduced supply.

Hehe.  There's a point in there.  The set of applicants willing to
sign idiotic arrangements that give away all manner of self-control
and place their trust and faith in people they little know must indeed
be a select group!  I do believe that their just rewards will be
forthcoming, too.  hehe.

But the essence of your point is simply that anything a company does
that reduces the set, is a good thing for those willing to cooperate?
That's the basis for your argument here, that this is an okay thing?

I love it when people argue as you do.


>Or more generally, if you want a higher quality product,
>you are going to pay more.

Hehe.  Somehow, I don't consider this a measure of a "higher quality
product," but rather a measure of business idiocy.  Probably a good
way to get people who are "technical hot house plants," gawking around
without a clue about what is reasonable and what isn't.

If you call that "higher quality," fine.  Good luck to you.


>Whether or not this company is overbearing,
>confused, or just doing what would be expected will be better determined
>once we have more information about the company.

More information is always helpful.  Tossing out a softball like this
doesn't make the rest you said sound any better to me, though.


>And though I would
>not be combative about these things if you decide to go to the interview, it
>seems quite appropriate and expected as a normal process of interviewing
>the company to ask them why they have these requirements on applicants
>that other companies to not.
>
>We seem to be making an assumption that all companies should have the
>same requirements in these indicated categories for all employees.  This is
>obviously not the case.

I don't think rickman suggested that a company shouldn't make requests
that other companies haven't, on that basis alone.  The fact that some
companies may have some requirements that other companies do not and
that such requirements may in fact be reasonable, something we can all
agree on, has absolutely no bearing on whether this particular issue
is reasonable or not.

This kind of arguing from you doesn't deal with the requests rickman
mentioned at all.  It just says that if some are okay, maybe this one
is okay too.  In effect, you throw away everything rickman said in his
post by way of information and then argue from a position of complete
ignorance of his points.

Such statements from you could just as well be applied to any request
from any company at any time.  It would explain any action or none of
them, equally well.  And it's exactly zero, in terms of making your
point, I believe.


>These fears that some terrible thing may happen because we essentially
>become less private for some purposes I suggest, as above, needs to be
>given a concrete, objective basis.

Is this the kind of vapid arguments I hear from folks who say, "Why
worry about your rights?  If you aren't guilty, you have nothing to
worry about?"  I can't believe may be tredding down this path!


>I am sure that all manner of crazy, illegal,
>or unethical actions have been taken by some companies and/or individuals
>at some time, but what is their effective relevance in the current case?

You seem to be saying that if you don't have evidence of specific
wrong-doing on the part of the company you hope to intervew at, that
you should just sign anything they ask you to?  Do you really think
so?


>(And this is another reason why we need specific names and actions so that
>we can deal with that apparently smaller proportion that is a problem
>instead of globally characterizing a large number for which there is no problem.)

Who exactly argued a global characterization, what is that
characterization you refer to and where is it?

So far as I can tell, we've been discussing specific requests and
actions, not companies.


>A meteorite may strike any one of us dead today, but we do not worry
>about it.

Is this one of your finer points?

Jon

Article: 24998
Subject: Re: Non-disclosures in job interviews, Round One
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Wed, 23 Aug 2000 10:29:09 -0700
Links: << >>  << T >>  << A >>
On Wed, 23 Aug 2000 09:21:41 -0700, Neil Nelson <n_nelson@pacbell.net>
wrote:

>I have not said: do not read the document before signing it.  But I am
>wondering specifically what passages should we be concerned with to
>a degree that would cause us to not sign it?

Rickman's original post says:

>>One of the paragraphs was a brief, but broadly worded NDA. Words
>>to the effect that I would not divulge any information that I obtained
>>while at this facility. 

I thought that's what we were discussing.

Jon
Article: 24999
Subject: Re: Mealy vs Moore FSM model
From: "Marc Klingelhofer" <marckEATSSPAM@omneon.com>
Date: Wed, 23 Aug 2000 17:43:44 GMT
Links: << >>  << T >>  << A >>
Surprisingly, I don't recall having seen one point throughout this entire
thread of 22 (now 23) messages:

The big problem with true Mealy machines is when you cascade them. An input
that affects outputs
which then become inputs to a second machine, affecting  its outputs, to a
third, and so on is a pain
to manage from a timing perspective. Good tools will find the long paths,
but then it's too late and the
designer needs to redesign those Mealy machines or do lots of path analysis.

When the outputs are registered, or at least are combinational from
registered state, the longest paths
are from one machine to the next, and you don't have to worry about outputs
which eventually
propagate through two or more machines.

I think this is a common problem when engineers say "I synthesized my
modules separately and the
slowest one ran at 92MHz but then when I hook them together my rate drops to
55MHz." The tools
are smart enough to recognize the multi-machine paths.

By the way, Rickman (since I know you read all of these posts), I hope you
appreciate that I formatted
this email to fit within your viewer's constraints. I know I wasn't the
poster to whom you were referring,
but I understand your issue. Indeed, I had the same problem with Alliance
2.1i: I have a number of
pulldowns on IOs and the translater's output log (I use Design Manager)
concatenated all of the messages
into one line:

Added a PULLDOWN primitive on net PLB_SCLKAdded a PULLDOWN primitive on net
PLA_SCLKAdded a PULLDOWN primitive on net PLA_D[13]Added <snipped about 40
more of these...>

I must apologize. That previous line wasn't wrapped! :^)

What newsreader do you use? OE5 wraps lines for me automatically. But it has
other problems, including
the OS it comes with.


Marc





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
2017JanFebMarApr2017

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