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 144150

Article: 144150
Subject: Re: New blog post on alphas in packagin
From: austin <austin@xilinx.com>
Date: Fri, 13 Nov 2009 11:29:07 -0800 (PST)
Links: << >>  << T >>  << A >>
Gabor,

Those ceramic packages had been contaminated in a bath of nitric acid
that had been used to dissolve some lead, so it bathed them in the
actinides, and plutonium decay isotopes...famous story.

If manufactured from low, or ultra low alpha materials, ceramics can
be as good as anything else.

Basically, if it ever got close to lead, you have 4.5 billion years of
decaying uranium and plutonium to deal with.

If people smoke cigarettes, you have Polonium 210 in the fertilizer
used, so the smoke is radioactive (one reason why people get cancer
from smoking).  Get that smoke into the chips, and you are in
trouble...upset rates go up by a factor of ten (I have measured it).

So, today, we buy laser separated lead for bumping (ultra low alpha
lead), and epoxies, mold compounds, etc all of the highest purity.

So does (most) everyone else who cares about alpha particles.  Tested
before the material is shipped, tested again before we use it.
Assembled in a line that has no non-pure materials, only on their own
dedicated machines, never used for a "regular" material assembly
lot....and no smoking.

There are lots of chips out there where the manufacturer doesn't care
how they get manufactured/assembled, as the application has such buggy
software, that soft errors are the least of their problems.

The recent paper by google is pretty scary, and typical of this market
(PC's).

http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

So, bad signal integrity, poor design, is thousands of times more
errors than alpha particles....but, maybe some of these are alphas?

Regardless, there are those that do care, and we do spend a lot of
effort to keep the bad isotopes at bay, and out of the process, but it
is impossible to remove all of them altogether.

As is typical of alpha contamination, NO ONE will confess to having
the problem, and they bury their dead quickly, and quietly.

But, the stories leak out:  an ASSP this year (recall), an ASIC
packaged wrongly (another recall), a 'bad' DRAM chip (another very
quiet wholesale recall).

Like I say, we "been there, done that" and have no intention of having
that happen ever again.

Honesty (still) is the best policy.

Oh, and verify, test, qualify.

Austin

Article: 144151
Subject: Re: An incomplete Mux and Latch?
From: johnp <jprovidenza@yahoo.com>
Date: Fri, 13 Nov 2009 11:45:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 13, 8:34=A0am, jay <heavenf...@gmail.com> wrote:
> On Nov 13, 10:58=A0pm, johnp <jprovide...@yahoo.com> wrote:
>
>
>
> > On Nov 13, 6:19=A0am, jay <heavenf...@gmail.com> wrote:
>
> > > Hello,
>
> > > I have an ASIC design using internal tri-state multi-sources buses
> > > like below:
> > > assign tbus =3D a_en ? a : Hiz;
> > > assign tbus =3D b_en ? b : Hiz;
>
> > > When implementing to FPGA, I found I can't strobe the right data from
> > > the bus. After analyze the code, I think it's because the strobe
> > > signal comes later than the enable signals for each source. For a rea=
l
> > > tri-state bus, the value can still float on the bus so the ASIC can
> > > work.
>
> > > For the FPGA, I think I need convert the bus using latch to contain
> > > the value when the enable signal has gone, so I designed the code lik=
e
> > > below:
> > > always @(*)
> > > begin
> > > =A0 if (a_en)
> > > =A0 =A0 tbus <=3D a;
> > > =A0 else if (b_en)
> > > =A0 =A0 tbus <=3D b;
> > > end
>
> > > However the circuit doesn't work as I expected, I examined the
> > > synthesis result, looks like my code is translated to a mux and a
> > > latch like below:
> > > assign temp =3D a_en ? a : b;
> > > always @(*)
> > > =A0 if (a_en | b_en)
> > > =A0 =A0 tbus <=3D temp;
>
> > > It seems Verilog doesn't accept an incomplete Mux, so b is set as
> > > default.
>
> > > Can anyone gives me some advise?
>
> > > Thanks
>
> > What is your setup/hold of the data and the enables? =A0You may need to
> > code this as
> > latches followed by a mux and not a mux followed by a latch.
>
> > always @(*)
> > =A0 if (a_en | (a & a_hold)
> > =A0 =A0 =A0a_hold =3D a;
>
> > always @(*)
> > =A0 if (b_en | (b & b_hold)
> > =A0 =A0 b_hold =3D b;
>
> > assign t_bus =3D a_en ? a_hold : b_hold;
>
> > Make sure that the synthesizer infers the latches properly, you may
> > need to use the simpler:
> > =A0 always @(&)
> > =A0 =A0 =A0if (b_en)
> > =A0 =A0 =A0 =A0 =A0b_hold =3D b;
>
> > Adding the extra term in the "if" solves a race condition when the
> > latch enable is removed and you're
> > making the latch out of discrete gates. =A0This is probably not needed
> > since the latch inferred by synthesis
> > should alreay take care of this.
>
> > I hope this helps!
>
> > John Providenza
>
> I haven't seen "always @(&)" before, a new syntax?

No, a typo.  It should have been always @(*)

John P

Article: 144152
Subject: Re: An incomplete Mux and Latch?
From: "maurizio.tranchero" <maurizio.tranchero@gmail.com>
Date: Sat, 14 Nov 2009 00:32:02 -0800 (PST)
Links: << >>  << T >>  << A >>
When I had to implement tri-state buffers onto FPGAs I've always
used FPGA-specific gates, e.g., "tri" buffers on Altera. I could
suggest you to look at the logic family you are using, probably
they have a solution for your issue.

Regards,
m

Article: 144153
Subject: Re: An incomplete Mux and Latch?
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 14 Nov 2009 16:02:05 +0100
Links: << >>  << T >>  << A >>
Am 13.11.2009 15:19, schrieb jay:

> always @(*)
> begin
>   if (a_en)
>     tbus <= a;
>   else if (b_en)
>     tbus <= b;
> end

This is a muxed latch. The latch-enable and the mux-selector are driven
by the same signal.

> assign temp = a_en ? a : b;
> always @(*)
>   if (a_en | b_en)
>     tbus <= temp;

You exactly have pointed out the problem with this alternative
description. Nevertheless it does not solve the problem.

To be more precise: Let's say a_en==1'b1 then signal a is selected and
the latch is open. Now with the falling edge of a_en the mux may change
it's output value AND the latch becomes inactive. No one can say witch
one is faster. A hold time violation is the result in simulation and
unpredictable results are the result in hardware.

Don't use muxed latches! Don't do it in ASICS or in FPGAs.
Find a new signal that drives the mux-selector!

Ralf

Article: 144154
Subject: OT: Moderator Vacancy Investigation: comp.arch.hobbyist
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 14 Nov 2009 16:40:54 +0000 (GMT)
Links: << >>  << T >>  << A >>
[Please note, followups set to news.groups]

The newsgroup comp.arch.hobbyist was created some years ago for the
discussion of recreational hardware design.  The activity when it was
created was (for example) people wirewrapping their own microprocessor
boards at home, but the scope in the charter (below) is a bit broader than
that.

It was created as a moderated group because the community previously
inhabited alt.comp.hardware.homebuilt which was filled with off-topic posts
like 'How do I plug in SIMMs to my PC?'.  That was probably a mistake, as
I'm not sure moderation was needed in comp.arch.*

Anyway, for some years the moderator has been AWOL and as a result the group
was been dead.  So the Big 8 Management Board are currently seeing if
there's any interest in replacing the moderator, or whether the group should
be deleted.

Is there any interest in a newsgroup for non-commercial electronics/hardware
design?  That might have a slightly different feel from, say,
comp.arch.embedded where the emphasis is on commercial development. 
Hardware, software, FPGAs (and more) would be covered.  It might not be a
particularly high-traffic group, as long as there are some people interested
in reading and posting.

If there's interest, the group is already carried by many news servers so
moderation just needs to be arranged - either on a simple automatic approval
system or, if manpower is available, with human moderators.  I'm willing to
set this up if people think it's worthwhile.  But I'm also happy for the
group to be deleted if no-one is interested.

So please followup to this posting (followup will go to news.groups not
comp.arch.* or sci.electronics.*) if you have an opinion.

Theo
(original proponent of comp.arch.hobbyist 1997-8)



Here's the official Moderator Vacancy Investigation posting (from
news.groups.proposals):

In news.announce.newgroups Alexander Bartolich <alexander.bartolich@gmx.at> wrote:
>               MODERATOR VACANCY INVESTIGATION (MVI)
>               moderated group comp.arch.hobbyist
> 
> This is a formal Moderator Vacancy Investigation (MVI), begun because
> moderated newsgroup comp.arch.hobbyist is not functioning, and may have
> been abandoned by its moderator(s).
> 
> This investigation will attempt to verify the reasons for non-function,
> and may result in the removal of the group or the selection and instal-
> lation of a new moderator.  In practice, the Big-8 Management Board
> considers the third alternative--changing the status of the group from
> moderated to unmoderated--as likely to cause more harm than good.
> 
> NEWSGROUPS LINE:
> 
> comp.arch.hobbyist      Homebrew digital electronics design. (Moderated)
> 
> DISTRIBUTION:
> 
> news.announce.newgroups
> news.groups.proposals
> comp.arch.hobbyist
> 
> PROPONENT:
> 
> Alexander Bartolich <alexander.bartolich@gmx.at>
> 
> CHARTER OF COMP.ARCH.HOBBYIST
> 
> A moderated forum to exchange ideas, techniques, problems, solutions,
> and other information concerning the hobby of electronics design and
> construction, specifically related to digital machines and their
> peripherals.
> 
> Commercial advertisements (except when non-repetitive and directly
> relevant to the topic of the group) are expressly forbidden; it is up
> to the moderation group to make individual exceptions.
> 
> Binary postings in this group are unwelcome.  No postings containing
> 10K or more of binary content will be accepted.  Postings containing
> less than 10K of binary content should only be used where no other
> reasonable method is available to convey the information they contain.
> All postings containing binary content of more than 10 lines or 300
> bytes, whichever is the smaller, shall be forwarded to the daily
> moderators for inspection in the same manner as articles from unknown
> authors.
> 
> Posters wishing to post binaries that do not fit the above criteria
> should upload this data to an FTP or WWW site and instead post a
> pointer to that site.  The binary regulations do not apply to the
> posting of ASCII schematics.
> 
> A 'bot moderator will be used, which will reject articles by authors
> who have not read the posting guidelines. Articles rejected by the
> 'bot will be forwarded to a group of three daily moderators for
> review. These daily moderators will be appointed by a moderation group
> of at least eight and at most twelve members who will decide on
> moderation policy in general and the workings of the 'bot in
> particular. Moderation will follow the scheme outlined below:
> 
> The 'bot:
> 
> - auto-approves articles that match all of these:
>   - known author
>     OR keyword/phrase in article
>     OR reply to approved article to the same set of newsgroups
>   - article with less than 300 bytes or 10 lines of binary
>     content, whichever is the smaller
>   - plain text, without markup encoding
> - mails notification of non-approval to original authors,
>   without an attempt to circumvent spamblocks
>   - notification message explains moderation system,
>     and points poster to relevant posting guidelines
> - sends non-approved articles to the daily moderators
> - uploads non-approved articles to a WWW site, and
>   regularly posts a pointer to them
> - scans for forged approvals and cancels
> 
> 
> The daily moderators:
> - individually check articles the 'bot rejected;
>   - if at least one of the daily moderators think the
>     article is on-topic, it gets posted
>   - if it is reposted, the original author is notified
> 
> The moderation group:
> - appoints the daily moderators
> - deals with group abuse that's not caught by the 'bot
>   - it has the power to bar persistent abusers by
>     unanimous decision for a period of up to
>     30 days at a time
> - deals with long-term moderation policy
> - is obliged to post details of all moderation group
>   decisions to the newsgroup
> - if a moderation group member does not express an opinion
>   on a matter, then their silence shall not be taken as
>   supporting either side of a decision
> 
> Moderators of news.announce.newgroups and successor groups are
> allowed blanket crossposting at their discretion.
> 
> RATIONALE:
> 
> Probe posts to this group resulted in bounces.
> 
> <comp-arch-hobbyist@moderators.isc.org>: host
>     moderators.switch.ch[130.59.10.10] said: 550 Unrouteable address
>     (in reply to RCPT TO command)
> 
> HISTORY OF THE GROUP:
> 
> comp.arch.hobbyist is a moderated newsgroup which passed its vote for creation
> by 199:15 as reported in news.announce.newgroups on 30 Jun 1998.
> 
> PROCEDURE:
> 
> Those who wish to comment on this moderator vacancy investigation should
> subscribe to news.groups.proposals and participate in the relevant
> threads in that newsgroup.  
> 
> To this end, the followup header of this RFD has been set to 
> news.groups.proposals.
> 
> For more information on the MVI process, please see 
> 
> http://www.big-8.org/dokuwiki/doku.php?id=policies:mvi
> 
> CHANGE HISTORY:
> 
> 2009-10-29      Probe post bounced
> 2009-11-01      Moderator Vacancy Investigation
> 

Article: 144155
Subject: Re: New blog post on alphas in packagin
From: Mike Treseler <mtreseler@gmail.com>
Date: Sat, 14 Nov 2009 09:50:29 -0800
Links: << >>  << T >>  << A >>
austin wrote:

> Those ceramic packages had been contaminated in a bath of nitric acid
> that had been used to dissolve some lead, so it bathed them in the
> actinides, and plutonium decay isotopes...famous story.

And there were white ceramic packages that let in light.
I once heard a story of product that worked on the
bench, but not in the box.
For rev 1.0 the workaround was a light bulb inside the box
near the custom chip in the white ceramic package.

    -- Mike Treseler

Article: 144156
Subject: Old EDK versions
From: Alexey <trenkoff@gmail.com>
Date: Sat, 14 Nov 2009 10:16:36 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I have an old project that was designed in EDK 7.1. Is there anywhere
I can download old versions of EDK; the new one , EDK 11, failed to
open the project stating incompatible cores.


Article: 144157
Subject: Re: New blog post on alphas in packagin
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 14 Nov 2009 18:34:33 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <cc88c220-c479-403e-a0ff-7a21d5317d4c@y10g2000prg.googlegroups.com>,
austin  <austin@xilinx.com> wrote:
>So, today, we buy laser separated lead for bumping (ultra low alpha
>lead), and epoxies, mold compounds, etc all of the highest purity.

Cool, I hadn't realised that was a commercial product.

http://www.osti.gov/bridge/servlets/purl/231307-yFE5Be/webviewable/231307.pdf
is a reprint of a (rather content-free) thirteen-year-old LLNL paper
about setting up to make the stuff.

>The recent paper by google is pretty scary, and typical of this market
>(PC's).
>
>http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

That very explicitly says that hard errors are more common than soft
errors; I've certainly had, of the couple of dozen RAM modules that
I've bought, one on which a sense amp died and every 4096th bit
started reading back as zero.  Wish I'd figured out that this was what
was happening before defragmenting a disc on that system!

The big recent packaging embarrassment is nVidia's inadequate bumping
in very hot graphics processors, which seems to have cost them a few
hundred million dollars and a lot of goodwill with Apple.

Tom

Article: 144158
Subject: Re: New blog post on alphas in packagin
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 14 Nov 2009 18:38:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Treseler <mtreseler@gmail.com> wrote:
(snip)
 
> And there were white ceramic packages that let in light.
> I once heard a story of product that worked on the
> bench, but not in the box.
> For rev 1.0 the workaround was a light bulb inside the box
> near the custom chip in the white ceramic package.

One I heard some years ago (2708 days) was an EPROM that worked
in the light, not in the dark.  It was part of a movie camera
controller that had to work in the dark.  Debugging in the dark
can be hard, though.

-- glen

Article: 144159
Subject: Altera Stratix IV GX Dev.Kit: PCI-E x4 device doesn't work in x8 slot
From: Michael S <already5chosen@yahoo.com>
Date: Sat, 14 Nov 2009 15:18:08 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi
We have a problem with Altera Stratix IV GX FPGA Development Kit.
Specifically, we build a PCI Express design based on Altera's own
"hard" PCI-E core configured for Gen.1 x4 operation. The design works
(more or less, but that's behind the scope of this message) when it is
plugged into x8 mechanical/x4 electrical slot. However when plugged in
x8 or x16 mechanical slots which are electrically x8 the design not
only doesn't work but not even recognized by the host as valid PCI-E
device. Exactly the same happens when we are trying to build x1
device.
We validated (by plugging off-the-shelf x1 and x4 PCI-E cards) that
it's not a host issue.
My only PCI-E book (Mindshare "PCI Express System Architecture") tells
virtually nothing about width negotiation so right now I am totally
lost.

Any ideas to help?

Article: 144160
Subject: Interconnecting 3v3 LVDS transmitter to 2V5 Receiver
From: "saijayram" <saijayram@gmail.com>
Date: Sun, 15 Nov 2009 07:37:24 -0600
Links: << >>  << T >>  << A >>
Hi.
Is there any harm in connecting 3V3 LVDS transmitter to 2V5 Receiver..?
I am using cyclonII fpga for a receiver in which LVDS inputs are connected
to 2V5 powered bank.

will the FPGA be damaged with such interconnection..?
I am using these lines for clock (26MHz) interconnecting two boards
separated by a distance of 6 inches thru mother board.

Thank you in advance

sai



Article: 144161
Subject: Re: Interconnecting 3v3 LVDS transmitter to 2V5 Receiver
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Sun, 15 Nov 2009 06:55:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On 15 Nov., 14:37, "saijayram" <saijay...@gmail.com> wrote:
> Hi.
> Is there any harm in connecting 3V3 LVDS transmitter to 2V5 Receiver..?
> I am using cyclonII fpga for a receiver in which LVDS inputs are connected
> to 2V5 powered bank.
>
> will the FPGA be damaged with such interconnection..?
> I am using these lines for clock (26MHz) interconnecting two boards
> separated by a distance of 6 inches thru mother board.
>
> Thank you in advance
>
> sai

shouldn't be a problem, lvds is lvds regardless of what supply voltage
the reciever/transmitter is using

-Lasse

Article: 144162
Subject: Re: New blog post on alphas in packagin
From: Gabor <gabor@alacron.com>
Date: Sun, 15 Nov 2009 10:16:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 14, 1:38=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Mike Treseler <mtrese...@gmail.com> wrote:
>
> (snip)
>
> > And there were white ceramic packages that let in light.
> > I once heard a story of product that worked on the
> > bench, but not in the box.
> > For rev 1.0 the workaround was a light bulb inside the box
> > near the custom chip in the white ceramic package.
>
> One I heard some years ago (2708 days) was an EPROM that worked
> in the light, not in the dark. =A0It was part of a movie camera
> controller that had to work in the dark. =A0Debugging in the dark
> can be hard, though.
>
> -- glen

Getting a bit further off-topic, at my first job we made a LORAN
receiver with planar-gas-discharge display (those bright orange
seven- or fourteen-segment displays you probably saw on
pinball machines).  The first winter after product release we
started getting calls from the field that the display would not
come on on dark, cold nights.  We finally reproduced the
problem in the screen-room with all lights off.  The instant the
fluorescent lamps were turned on, the displays started up.

Apparently the 900V or so was not enough to get the lamp
started without some help from external radiation.  The
solution came from the PGD manufacturer:  add a bit of
radioactive Kr-85 to the gas in the tubes.

Regards,
Gabor

Article: 144163
Subject: Re: New blog post on alphas in packagin
From: Gabor <gabor@alacron.com>
Date: Sun, 15 Nov 2009 10:17:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 15, 1:16=A0pm, Gabor <ga...@alacron.com> wrote:
> On Nov 14, 1:38=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>
>
> > Mike Treseler <mtrese...@gmail.com> wrote:
>
> > (snip)
>
> > > And there were white ceramic packages that let in light.
> > > I once heard a story of product that worked on the
> > > bench, but not in the box.
> > > For rev 1.0 the workaround was a light bulb inside the box
> > > near the custom chip in the white ceramic package.
>
> > One I heard some years ago (2708 days) was an EPROM that worked
> > in the light, not in the dark. =A0It was part of a movie camera
> > controller that had to work in the dark. =A0Debugging in the dark
> > can be hard, though.
>
> > -- glen
>
> Getting a bit further off-topic, at my first job we made a LORAN
> receiver with planar-gas-discharge display (those bright orange
> seven- or fourteen-segment displays you probably saw on
> pinball machines). =A0The first winter after product release we
> started getting calls from the field that the display would not
> come on on dark, cold nights. =A0We finally reproduced the
> problem in the screen-room with all lights off. =A0The instant the
> fluorescent lamps were turned on, the displays started up.
>
> Apparently the 900V or so was not enough to get the lamp
> started without some help from external radiation. =A0The
> solution came from the PGD manufacturer: =A0add a bit of
> radioactive Kr-85 to the gas in the tubes.
>
> Regards,
> Gabor

Oops...  that should have been 90V, not 900V...

Article: 144164
Subject: who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
From: water <water9580@yahoo.com>
Date: Mon, 16 Nov 2009 04:06:53 -0800 (PST)
Links: << >>  << T >>  << A >>
who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?

Article: 144165
Subject: Re: who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
From: Antti <antti.lukats@googlemail.com>
Date: Mon, 16 Nov 2009 04:42:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 2:06=A0pm, water <water9...@yahoo.com> wrote:
> who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?

oh no again the same topic!

Antti

Article: 144166
Subject: Re: Interconnecting 3v3 LVDS transmitter to 2V5 Receiver
From: austin <austin@xilinx.com>
Date: Mon, 16 Nov 2009 08:08:15 -0800 (PST)
Links: << >>  << T >>  << A >>
Sai,

LVDS is a standard.  The Vcco is immaterial (does not matter).

Yes, they are designed to interconnect (3.3 to 2.5, 2.5 to 3.3).

Austin

Article: 144167
Subject: Re: Old EDK versions
From: LittleAlex <alex.louie@email.com>
Date: Mon, 16 Nov 2009 08:30:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 14, 10:16=A0am, Alexey <trenk...@gmail.com> wrote:
> Hi,
>
> I have an old project that was designed in EDK 7.1. Is there anywhere
> I can download old versions of EDK; the new one , EDK 11, failed to
> open the project stating incompatible cores.

ISE, yes.  EDK, unknown.

I found this post from about a year and a half ago:
<http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/
e6e08f8679c3a5ce>

AL

Article: 144168
Subject: Re: Having trouble with Xilinx timing constraints
From: rickman <gnuarm@gmail.com>
Date: Mon, 16 Nov 2009 12:10:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 11, 11:38=A0am, Paragon <paragon.j...@gmail.com> wrote:
> Hello all,
>
> I have having trouble figuring out how to properly define some timing
> constraints for an interface between two Xilinx Virtex-4 LX100's. =A0If
> anybody has any insight on the best way to solve this problem, it
> would be appreciated.
>
> Here are the fixed system parameters (these cannot be changed no
> matter how much easier it would make the design).
>
> 1) Each FPGA is provided with an identical 384 MHz clock.
> 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96
> MHz.
> 3) There are some control signals which need to be sent back and forth
> between the FPGAs which are generated in the 96 MHz clock domain.
> 4) Between the FPGAs there are pins which are connected directly,
> including 2 pins in each direction which are capable of driving
> differential clocks if needed. =A0All of these signals are in 2.5 V
> banks.
> 5) There is a worst case of 0.95 ns propagation time on the lines
> between the two FPGAs.
>
> The problem is that due to the 96 MHz clock being derived in each
> FPGA, there is not a defined phase relationship between the two 96 MHz
> clocks (there could be any one of 4 relative phases), so data can not
> just be sent back and forth as if it were synchronous.
>
> I have tried constraining with OFFSET IN and OFFSET OUT constraints
> that can handle these 4 relative phases (basically constrain as if it
> were a 384 MHz clock) but this appears to be too much for the FPGA to
> handle.
>
> Here are the constraints I defined in this case:
>
> NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> NET "outputData<*>" OFFSET =3D 0.6 ns AFTER "clk_384mhz_p";
> NET "inputData<*>" OFFSET =3D IN 1 ns VALID 1.6 ns BEFORE
> "clk_384mhz_p";
>
> Another idea I have tried is to use source synchronous design to
> forward the 96 MHz clock (as a differential clock) with the data and
> then use a FIFO to move it into the "receiving" 96 MHz clock domain
> after clocking it in with the "originating" =A096 MHz. =A0Once again
> though, the design has trouble meeting timing.
>
> Here are the constraints I defined in this case:
>
> NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> NET "originatingClk_p" TNM_NET =3D"originatingClk_p";
> TIMESPEC "TS_originatingClk_p" =3D PERIOD "originatingClk_p" 10.4 ns
> HIGH 50%;
>
> NET "outputData<*>" OFFSET =3D 5 ns AFTER "clk_384mhz_p";
> NET "inputData<*>" OFFSET =3D IN 4 ns VALID 4 ns BEFORE
> "originatingClk_p";
>
> Does anybody have any insight into the best way to solve this problem?
>
> Thanks!

I would use the 384 MHz clock to move the data across the interface
with a clock enable.  This gives you the full 10.4 ns cycle of the 96
MHz clock to move the data across and only the enable signal needs to
operate at the full 384 MHz rate.  Inside the receiving chip the data
then needs to be synchronized to the internal 96 MHz clock.
Internally the sync circuit will need to operate at the full 384 MHz
rate, but that shouldn't be a problem.  The clock enable might want to
be a differential signal.

Rick

Article: 144169
Subject: Re: Having trouble with Xilinx timing constraints
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 16 Nov 2009 14:01:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 11, 11:38=A0am, Paragon <paragon.j...@gmail.com> wrote:
> Hello all,
>
> I have having trouble figuring out how to properly define some timing
> constraints for an interface between two Xilinx Virtex-4 LX100's. =A0If
> anybody has any insight on the best way to solve this problem, it
> would be appreciated.
>

>
> Does anybody have any insight into the best way to solve this problem?
>

Send identical 96 MHz clocks to each FPGA and multiply up internally
to get the 384 MHz.

KJ

Article: 144170
Subject: Re: who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
From: water <water9580@yahoo.com>
Date: Mon, 16 Nov 2009 19:22:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On 11=D4=C216=C8=D5, =CF=C2=CE=E78=CA=B142=B7=D6, Antti <antti.luk...@googl=
email.com> wrote:
> On Nov 16, 2:06 pm, water <water9...@yahoo.com> wrote:
>
> > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
>
> oh no again the same topic!
>
> Antti

Can you help me write a wrapper?

I can pay $$$.

Article: 144171
Subject: Re: who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
From: Muzaffer Kal <kal@dspia.com>
Date: Mon, 16 Nov 2009 21:00:52 -0800
Links: << >>  << T >>  << A >>
On Mon, 16 Nov 2009 19:22:53 -0800 (PST), water <water9580@yahoo.com>
wrote:

>On 11??16??, ????8??42??, Antti <antti.luk...@googlemail.com> wrote:
>> On Nov 16, 2:06 pm, water <water9...@yahoo.com> wrote:
>>
>> > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
>>
>> oh no again the same topic!
>>
>> Antti
>
>Can you help me write a wrapper?
>
>I can pay $$$.

What if someone develops the wrapper and licenses to you? 
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144172
Subject: Re: who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
From: water <water9580@yahoo.com>
Date: Mon, 16 Nov 2009 23:25:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On 11=D4=C217=C8=D5, =CF=C2=CE=E71=CA=B100=B7=D6, Muzaffer Kal <k...@dspia.=
com> wrote:
> On Mon, 16 Nov 2009 19:22:53 -0800 (PST), water <water9...@yahoo.com>
> wrote:
>
> >On 11??16??, ????8??42??, Antti <antti.luk...@googlemail.com> wrote:
> >> On Nov 16, 2:06 pm, water <water9...@yahoo.com> wrote:
>
> >> > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?
>
> >> oh no again the same topic!
>
> >> Antti
>
> >Can you help me write a wrapper?
>
> >I can pay $$$.
>
> What if someone develops the wrapper and licenses to you?
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
> http://www.dspia.com

I can pay $$$.

Article: 144173
Subject: Too Easy: Actel FPGA's! :)
From: Antti <antti.lukats@googlemail.com>
Date: Tue, 17 Nov 2009 04:02:53 -0800 (PST)
Links: << >>  << T >>  << A >>
5 minutes video
http://www.youtube.com/watch?v=hnmSJJOD86A

from vhdl to the programming files, and programming without actel
programmer
using DirecC and usb-jtag cable

Antti
PS i messed up alter-actel in the video a few times :(

Article: 144174
Subject: Error:Place:645 on a non-clock pin.
From: Griffin <captain.griffin@gmail.com>
Date: Tue, 17 Nov 2009 09:41:44 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

I have an EDK 11.1 project with a single custom peripheral containing
exterior ports. After assigning said ports in the .ucf file to buttons
on my FPGA board (for debugging purposes), I can generate the netlist
but I receive the following error when I try to generate the
bitstream:

"Error:Place:645 - A clock IOB clock component is not placed at an
optimal clock IOB site. The clock IOB component <my_pin<0>> is placed
at site <E7>. The clock IO site can use the fast path between the IO
and the Clock buffer/GCLK if the IOB is placed in the master Clock IOB
Site. If this sub optimal condition is acceptable for this design, you
may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to
demote this message to a WARNING and allow your design to continue.
However, the use of this override is highly discouraged as it may lead
to very poor timing results. It is recommended that this error
condition be corrected in the design. A list of all the COMP.PINs used
in the clock placement rule is listed below. These examples can be
used directly in the .ucf file to override this clock rule. < NET
"my_pin<0>" CLOCK_DEDICATED_ROUTE = FALSE; >."

I get a similar message for my_pins<1>...<5> (I have 5 of such pins).

The issue here is that the said ports are not clocks, and has nothing
to do with a clock anywhere. Has anyone seen this before?

Thanks.



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