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 49100

Article: 49100
Subject: Re: Quartus LogicLock problem
From: garys@altera.com (Gary Sugita)
Date: 31 Oct 2002 15:37:00 -0800
Links: << >>  << T >>  << A >>
stephen.busch@web.de (stephen) wrote in message news:<6643d19f.0210300556.2952775b@posting.google.com>...
> Hi Gary
> 
> garys@altera.com (Gary Sugita) wrote in message news:<a2058d2c.0210291941.371a89c7@posting.google.com>...
> > Hi Stephen,
> > 
> > Without seeing your .ESF file itself it is hard to definitely pinpoint
> > the problem  However, here are some questions and suggestions.
> > 
> > 
> > 1) Have you tried to move the regions at all through TCL?  You mention
> > this later on in your posting (just changing the ll_origin assignment
> > does NOT refresh the node locations.  Currently this must be done
> > through the GUI).  Changing the LL_ORIGIN statement through TCL is an
> > almost sure-fire way to break things.
> 
> I noticed this. Here is a way I figured out to move LogicLock regions
> from a Tcl script.
>   . Import the existing logicLock regions from .esf files
>   . For the ones you need to move : 
>     . create a new region of the same size that the one you need 
>       to move (fixed size)
>     . set the position of the new region (fixed position)
>     . use this region as a parent for the one you want to move.
> This way the fitter moves the region to the right place and the cells
> are inside. This method isn't very elegant but it works.
> 
That's a creative way of doing it :)  I agree this is not elegant, but
there will be a TCL move command in Quartus 3.0.


> > 2) Have you tried changing the LL_PARENT assignment through TCL? 
> > Changing the parent may require the region to be moved.  The GUI knows
> > how to handle this, but the TCL interface does not.  As a result, some
> > regions may not be within their parent region.  This will also
> > generate messages like the ones you are seeing.  Again, do not change
> > the LL_PARENT from TCL.
> 
> Changing the LL_PARENT seems to work when I first import the region
> and then change the assignment. I got the results I expected when I
> opened the project from the gui. I guess it works because the regions
> are converted to FLOATING and moved to the right place by the fitter.

Yes, its only because the regions were floating did this work
correctly.  The fitter made the move.  This won't work with fixed
location regions.

> > 3) It is always a good idea to have registered boundaries between
> > modules.
> 
> I did. 
> 
> 
> > Some things you can check to help you narrow down what is going wrong
> > are:
> > 
> > 1) Use the GUI to do the same steps that you are trying to do from
> > TCL.  Does it work there?  (if it does, I would guess that your
> > problems are related to number 1 or 2 above)  Do the regions show up
> > RED in the Logiclock Window after you import them?  Or does everything
> > look okay and you still get these error messages when compiling? (in
> > this case I would say #3 above is part of your problem)
> > 
> > 2) Use the GUI in the lower level to see if the regions are okay (ie
> > all nodes are within the region boundaries)
> > 
> 
> I followed your advice. It seems that things become difficult at the 3rd
> level of imbrication. Some of the cells, but not all, are moved outside 
> lower level regions. They are still inside the parent region but not any more
> in the child region. 
> 
So things start to break down on the third level, so that's the second
import right?  When you did the import, did you have the AB.esf AND
the ABA.esf in the project directory of A?  Were there any
LL_IMPORT_FILE options in the A.esf file?  Can you try this again with
ONLY the AB.esf in the project directory of A (and using no
LL_IMPORT_FILE options)?  This may be a problem we are already aware
of.

> > 
> > On a side note, here are some comments about your methodology:
> > 
> > You say that multiple people are working co-operatively on this
> > design.  I assume that you need the TCL script because people may
> > change the placement of lower level modules and you want to have an
> > automatic merge and update of the top-level design.
> 
> Right. I also want them to be able to integrate their modifications
> without my help. For exemple we have a person working on a memory
> controller which interacts with the rest of the design. During the 
> debug phase he often changes his code. To recompile he only has to run the 
> makefile, without knowing to much about how quartus works. So he 
> could focus on his design.
> Doing things on a makefile / script basis make it possible to reproduce
> the same result on each resynthesis. Using the gui people often didn't
> remember what they did and where unable to know why things worked yesterday
> and not today.

I agree that you will want to use a script based approach to
integrating everything.  But what I was proposing was that set things
up using the GUI initially, and then use a script for everyone to do
their merging easily.
> 
> > I would recommend you go about doing this as follows:
> > 
> > Do your initial merge using the GUI.  Do your importing, moving,
> > changing parents etc. all through the GUI the first time.  Now that
> > you have a "good" top level design where everything works and makes
> > sense, you are are ready to use the TCL script to "update" any of the
> > regions that need changing.
> > 
> > Using the cmp logiclock_import 0 1 0 1 0 "region_name" 
> > Where region_name is the name of the region you want to update, and in
> > your case you would run this command once for every region.  This
> > command preserves the placement of the region in the top level, and
> > the LL_PARENT settings.
> > 
> > With this flow, you can do all of your top-level floorplanning, and
> > only update the contents of the regions.  As an additional benefit, it
> > also eliminates the need to try to move regions around using TCL,
> > while only forcing you to use the GUI once.
> 
> I changed I bit my aproach because I noticed that compilation times of
> intermediate LogicLock level are very long. Here is an exemple : lets
> say I have 3 regions AAA AAB AAC which should be grouped together into
> region AA. There are almost no more LE than the ones contained in
> AAA AAB AAC. So, as the position of almost every LE is known fitting of
> AA should be very fast. This is not what happens. I guess the reason
> it that quartus redoes the routing each time. As the result of the routing
> couldn't be locked down things are redone at every level, right ?
> 
> So now I only create the lowest level logic lock regions (AAA ...)
> and I directly place them into the top level. This is much faster than
> creating the regions AA and A first. This way the others problems also
> disappear.
> 
> Here is an other question. Is there a way to lock down the routing or is
> it redone in every case. If for exemple only one (small) LogicLock region
> changes is quartus redoing the hole routing ? Is there a way to only change
> the content of a ROM without redoing a complete fit ?


> Can you send me the archived project of the level at which you first saw problems when you imported?  I want to try to recreate the error on my end.


> Thank you very much for your help
> 
> Stephen
> 
> > 
> > Hope this helps.
> > 
> > -Gary Sugita
> > 
> > 
> > 
> > stephen.busch@web.de (stephen) wrote in message news:<6643d19f.0210240712.62595be2@posting.google.com>...
> > > Hi,
> > >   I'm using the LogicLock design flow to incrementally place and route
> > > a design on a APEX1500KE device. Several people work on the project
> > > and I
> > > need to automate the compilation flow, so everything is done with tcl
> > > scripts.
> > > 
> > >   I followed the instructions from Altera but I still have some
> > > problemes. The structure of the design is something like this :
> > >  top +-- A
> > >      |   +--- AA
> > >      |   +--- AB
> > >      |        +---ABA
> > >      |        +---ABB
> > >      +-- B
> > >      |   +--- BA
> > >      |   +--- BB
> > >      |        +---BBA
> > >      |        +---BBB
> > > 
> > > Here is what I do :
> > >   . I generate a edf file for each module (AA, BA, ABA, ABB, BBA, BBB)
> > >     with Leonardo.
> > >   . I run quartus for each submodule (AA, BA, ABA, ABB, BBA, BBB) to 
> > >     generate the esf and vqm files. Each submodule contains one or
> > > more
> > >     LogicLock regions.
> > >   . to generate the esf and vqm file of bloc AB I use the vqm and esf
> > > files
> > >     generated for ABA and ABB plus an additional edf file. To enforce
> > > the
> > >     hierarchie I use the LL_PARENT assignment. I change this
> > > assignment
> > >     after importing the lower level .esf files, otherwise it doesn't
> > > work.
> > >   ...
> > >   . for the final place and route I use the files A.vqm A.esf B.vqm
> > > B.esf and
> > >     top.edf. The LogicLock regions defined are visible and have the
> > > correct
> > >     size at the top level. The position is chosen automaticly by
> > > quartus
> > >     for the moment.
> > >  
> > > For the lower levels everything is fine but I get some problems at the
> > > top
> > > level. I get a lot of messages like the one : 
> > >   Warning: Ignored back-annotated location assignment on node 
> > > bmicro:bmicro_inst|i2c:i2c_enabled_i2c_inst|i2c_intermediaire:i2c_intermediaire_inst|i2c_reste:reste|modgen_eq_445_ix46~I_I
> > > assigned to LogicLock region
> > > i2c_i2c:i2c_enabled_i2c_inst_bmicro:bmicro_inst because location is
> > > outside region boundaries
> > > How could this happen ? At the lower levels all the cells where inside
> > > the
> > > logiclock region and I didn't get the message. For the moment I didn't
> > > try
> > > to move manually the regions.
> > > 
> > > Quartus also complains about carry chains it couldn't place inside a
> > > low level
> > > logiclock region. But I didn't get this message when it fitted this
> > > region or
> > > the next higher level.
> > > 
> > > My next problem is that I need to chose the position of the logiclock
> > > regions
> > > because of timing issues. I can do this using the quartus gui but I
> > > want to
> > > move them from a tcl script. When I only change the LL_ORIGIN
> > > assignment
> > > the LL_LOCATION assignments aren't updated. Does anyone know which
> > > command
> > > I need to run ?
> > > 
> > > thanks for you help
> > > stephen

Article: 49101
Subject: Re: Simple question on Xilinx CPLD 9500
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 31 Oct 2002 16:30:21 -0800
Links: << >>  << T >>  << A >>
It is CMOS, but there  also "linear" sense amplifiers, like they are in
all CPLDs except CoolRunner (which is all-CMOS = very low power)

Peter Alfke, Xilinx
===================
Pierre Lafrance wrote:

> Hi all
> One of my friend, who study electrical eng at university, ask me what
> kind of technology is used to implement a 9500, meaning is it a
> BI-CMOS, ACT, TTL, etc...  This is for a lab he as to do.
> I was not able to find this information on Xilinx web site.
>
> Cheers !


Article: 49102
Subject: Re: Concepts: What is "Clock Edge"?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 31 Oct 2002 16:48:40 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:

> Hmmm - I think even this needs qualification.. :)
>
> Master-Slave implies/requires a hand-over, or make-before-break action.

yes, agreed

> In an extreme slow edge case, the threshold skews could cause
> make-before-break to become break-before-make, so I don't agree
> "You can have any rise or fall time you want" -
>
> 'Properly designed' cannot eliminate threshold variations, due
> to process shifts, as well as practical things like local gound/vcc
> movement.

I disagree. We are talking about a single flip-flop with a common ground. The
designer makes sure that there is no overlap. Otherwise it is not a
"well-designed" flip-flop.

> A minimum slew rate is giving you three things
>
> - sufficently narrow time skew across multiple registers

yes, agreed

> - sufficently narrow time skew within the master-slave core

I call that well-defined set-up and hold times

>
> - Improves noise margin, as Q driven bounce in CMOS shifts the
>   threshold ( == your double clocking case, which can also include
>   miss-clocking )

This is whereI disagree, and this is the reason for continuing this pedantic
thread:
A flip-flop can NEVER miss a clock. There is NO way to sneak the clock from one
level to the other, without the flip-flop recognizing it.
That's always my argument when users complain that a counter bit does not
toggle. It cannot avoid toggling, but it might have toggled twice, which looks
deceptively like no toggle...

Peter Alfke, Xilinx Applications



Article: 49103
Subject: Metastability results are finally posted
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 31 Oct 2002 17:05:11 -0800
Links: << >>  << T >>  << A >>

--------------CB07FD41E3C39322A1341284
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

I am happy to report that the results of our metastabity tests are now
posted at
http://support.xilinx.com/support/techxclusives/metas-techX32.htm

The capture window causing 500 ps of metastable delay is an incredibly
small 0.03 femtoseconds. If the clock rate is below 300 MHz and the
routing delay is minimal, then the MTBF will be thousands or even
millions of years.
Good to know!

Peter Alfke, Xilinx Applications



Article: 49104
Subject: Re: Concepts: What is "Clock Edge"?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 01 Nov 2002 14:39:07 +1300
Links: << >>  << T >>  << A >>
Hello Peter, - interesting debate..

Peter Alfke wrote:
> 
> Jim Granville wrote:
> 
> > Hmmm - I think even this needs qualification.. :)
> >
> > Master-Slave implies/requires a hand-over, or make-before-break action.
> 
> yes, agreed
> 
> > In an extreme slow edge case, the threshold skews could cause
> > make-before-break to become break-before-make, so I don't agree
> > "You can have any rise or fall time you want" -
> >
> > 'Properly designed' cannot eliminate threshold variations, due
> > to process shifts, as well as practical things like local gound/vcc
> > movement.
> 
> I disagree. We are talking about a single flip-flop with a common ground. The
> designer makes sure that there is no overlap. Otherwise it is not a
> "well-designed" flip-flop.

but a single flip-flop is of no practical use, so identifying the
real-world effects that can move the threshold becomes important.
They are external to the FF, so 'well designed' is not really a factor.

> 
> > A minimum slew rate is giving you three things
> >
> > - sufficently narrow time skew across multiple registers
> 
> yes, agreed
> 
> > - sufficently narrow time skew within the master-slave core
> 
> I call that well-defined set-up and hold times
> 
> >
> > - Improves noise margin, as Q driven bounce in CMOS shifts the
> >   threshold ( == your double clocking case, which can also include
> >   miss-clocking )
> 
> This is whereI disagree, and this is the reason for continuing this pedantic
> thread:
> A flip-flop can NEVER miss a clock. There is NO way to sneak the clock from one
> level to the other, without the flip-flop recognizing it.

 Not even if the make-before-break action needed, has morphed into 
break-before-make ?

 Modern FF's seem to mostly use transmission gates, and in the extreme
case ( _very_ slow slews ) these would be all-on, and master-slave 
ceases to exist.

 In this case, it must be very close to metastable in nature, with the
final state a lottery.

 I suppose one could claim that it recognized the clock in going
unstable :) but the nett user symptom is it missed the clock.

 Or, one could claim that in going to 50%, then changing its mind and
not actually toggling, it doubled clocked :)

 To me, once the master-slave hand-over fails, it is no longer a 
true Flip-Flop, but a Might-Flop ! :)


> That's always my argument when users complain that a counter bit does not
> toggle. It cannot avoid toggling, but it might have toggled twice, which looks
> deceptively like no toggle...

 I'll agree double-toggling is by far the dominant failure mode, but I'm
not sure I'm brave enough to claim miss-clock NEVER occurs.

 I have seen some very strange effects from logic under the 'stress' 
of outside spec signals - so much that I'm amazed Schmitt clocks are not
mandatory.

 Jim G.

Article: 49105
Subject: XC18VXX PROM Corruption
From: skyhawk172L@attbi.com
Date: Fri, 01 Nov 2002 02:20:18 GMT
Links: << >>  << T >>  << A >>


Has anyone seen any instances of the image programmed in a Xilinx
XC18VXX device getting corrupted?

I've seen this several times on both XC18V02 and XC18V04 devices. We
load an image in the PROM once and don't touch it again. The FPGA gets
successfully configured by the PROM numerous times until one day
configuration fails. Once it fails, the only way to get things working
again is to reprogram the PROM.

Anyone else seen anything like this??



Article: 49106
Subject: Re: XC18VXX PROM Corruption
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 01 Nov 2002 15:25:46 +1300
Links: << >>  << T >>  << A >>
skyhawk172L@attbi.com wrote:
> 
> Has anyone seen any instances of the image programmed in a Xilinx
> XC18VXX device getting corrupted?
> 
> I've seen this several times on both XC18V02 and XC18V04 devices. We
> load an image in the PROM once and don't touch it again. The FPGA gets
> successfully configured by the PROM numerous times until one day
> configuration fails. Once it fails, the only way to get things working
> again is to reprogram the PROM.
> 
> Anyone else seen anything like this??

 Next time it occurs, read the PROM, and check the details of the
failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc )

 Does raise an intersting question about ECC in Loader devices ?

-jg

Article: 49107
Subject: Re: XC18VXX PROM Corruption
From: skyhawk172L@attbi.com
Date: Fri, 01 Nov 2002 02:37:47 GMT
Links: << >>  << T >>  << A >>
On Fri, 01 Nov 2002 15:25:46 +1300, Jim Granville
<jim.granville@designtools.co.nz> wrote:

>skyhawk172L@attbi.com wrote:
>> 
>> Has anyone seen any instances of the image programmed in a Xilinx
>> XC18VXX device getting corrupted?
>> 
>> I've seen this several times on both XC18V02 and XC18V04 devices. We
>> load an image in the PROM once and don't touch it again. The FPGA gets
>> successfully configured by the PROM numerous times until one day
>> configuration fails. Once it fails, the only way to get things working
>> again is to reprogram the PROM.
>> 
>> Anyone else seen anything like this??
>
> Next time it occurs, read the PROM, and check the details of the
>failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc )
>
> Does raise an intersting question about ECC in Loader devices ?
>
>-jg

What, specifically, should I be looking for? I had one fail today and
did a 'verify'. It came back and told me there was a mismatch at a
certain location in the PROM. 

I can also do a 'readback' from the PROM and see what's in there. I
can see differences. Now what??



Article: 49108
Subject: Re: FPGA XC4005E
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 31 Oct 2002 19:31:11 -0800
Links: << >>  << T >>  << A >>
Ken McElvain <ken@synplicity.com> writes:
> There never was a 4.x version of Synplify, we skipped from 3.x to 5.x
> because of beliefs in Asia about the number 4.

I wrote:
> Don't customers in Asia worry that when they buy version five of your
> product, it's really version four?

Peter Alfke <peter@xilinx.com> writes:
> How many European and American hotels have a thirteenth floor, or a room
> number 13? Not many. Same reason.

And don't superstitious people then worry if they get room 1401 (US)
or 1201 (Europe)?

I've noticed that some passenger aircraft don't have a row 13.

Anything I have control over will not have different numbers to avoid
4, 13, 666, or any other "unlucky" number, unless I have a customer
that is otherwise going to refuse to sign a contract for a large amount
of money.


Article: 49109
Subject: Re: Metastability results are finally posted
From: "Bob" <nimby1_not_spmmm@earthlink.net>
Date: Fri, 01 Nov 2002 03:49:27 GMT
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C28116.8A3507B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Peter,

How in the HELL were you able to control the phase of a clock with (less =
than) 0.03 fs resolution?

Does this mean that the DCM's in your new Virtex-III's will have =
femtosecond phase-shifter adjustability? Jitter in the =
milli-femtoseconds (unit name?) ? Routing delays too low to publish?

  ;-D

Bob
  "Peter Alfke" <peter@xilinx.com> wrote in message =
news:3DC1D346.E1135A16@xilinx.com...
  I am happy to report that the results of our metastabity tests are now =
posted at 
  http://support.xilinx.com/support/techxclusives/metas-techX32.htm 
  The capture window causing 500 ps of metastable delay is an incredibly =
small 0.03 femtoseconds. If the clock rate is below 300 MHz and the =
routing delay is minimal, then the MTBF will be thousands or even =
millions of years. 
  Good to know! 

  Peter Alfke, Xilinx Applications 




Article: 49110
Subject: Re: How important is simulation?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 01 Nov 2002 04:29:14 GMT
Links: << >>  << T >>  << A >>
On Thu, 31 Oct 2002 14:14:12 -0800, John Larkin
<jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:

>On 30 Oct 2002 14:40:07 -0800, joefrese@hotmail.com (Joe Frese) wrote:
>
>>First off, thanks to all who responded to my last post, re: FPGA
>>fullness.  Your comments and suggestions were incredibly helpful.
>>
>>We recently purchased Active-HDL 5.1XE, and in experimenting with it,
>>I discovered an FPGA design that does not simulate (post
>>place-and-route) correctly . . . which is strange, as the design has
>>been tested and verified as operating correctly in actual hardware. 
>>Digging a little deeper, I was able to identify a number of constructs
>>in the design that cause problems in simulation, but should NOT cause
>>problems in real hardware.
>>
>>Now, I could fix these areas so that the design simulates correctly,
>>but the problem constructs are sprinkled heavily throughout, so to do
>>so would be no small undertaking.  My question is, therefore: how
>>important is it to have a completely clean simulation?  Is it
>>important enough to renovate a working and tested design?  Thanks in
>>advance for your input.
>>
>>Joe Frese
>
>
>I've done some pretty hairy stuff (77 MHz OC-3 data, microengines,
>nasty state machines prowling multiport ram) without simulation, and
>without a lot of trouble bringing them up. Just a timing report tells
>us that the p&r looks OK. 
>
>After all, simulation just tells you that you made a mistake, and
>ultimately it becomes obvious, so why not just inspect the design
>carefully before you compile it?

This methodology only works for small, simple designs.  The project
I'm working on at the moment has about 1/2 million lines of source.
Yes, we look over it carefully, but simulation is vitally important
for a successful end result.

Regards,
Allan.

Article: 49111
Subject: Sales News
From: "Hot Dog" <hd@telecomm.8m.com>
Date: Fri, 1 Nov 2002 09:36:21 +0500
Links: << >>  << T >>  << A >>
Hi frends!

Welcomm to www.crackshop.org
Small prices, good pricess.


Hot Dog





Article: 49112
Subject: Re: XC18VXX PROM Corruption
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 01 Nov 2002 17:45:52 +1300
Links: << >>  << T >>  << A >>
skyhawk172L@attbi.com wrote:
> 
> On Fri, 01 Nov 2002 15:25:46 +1300, Jim Granville
> <jim.granville@designtools.co.nz> wrote:
> 
> >skyhawk172L@attbi.com wrote:
> >>
> >> Has anyone seen any instances of the image programmed in a Xilinx
> >> XC18VXX device getting corrupted?
> >>
> >> I've seen this several times on both XC18V02 and XC18V04 devices. We
> >> load an image in the PROM once and don't touch it again. The FPGA gets
> >> successfully configured by the PROM numerous times until one day
> >> configuration fails. Once it fails, the only way to get things working
> >> again is to reprogram the PROM.
> >>
> >> Anyone else seen anything like this??
> >
> > Next time it occurs, read the PROM, and check the details of the
> >failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc )
> >
> > Does raise an intersting question about ECC in Loader devices ?
> >
> >-jg
> 
> What, specifically, should I be looking for? I had one fail today and
> did a 'verify'. It came back and told me there was a mismatch at a
> certain location in the PROM.
> 
> I can also do a 'readback' from the PROM and see what's in there. I
> can see differences. Now what??

 Readback a failed one to a file, and if that file is not identical
in format to the loaded one, read a GOOD prom back as well
( easy way to get two comparable files :)
 Also, read a BLANK one, to check which polarity is blank.

 Then, run a file compare program to compare both files, and check
the differences report.
 Page-flipping in an editor can also show changes, once you know where 
to look.

 - jg

Article: 49113
Subject: Re: Concepts: What is "Clock Edge"?
From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Fri, 01 Nov 2002 05:02:45 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3DC1CF68.722D62F7@xilinx.com...
>
(snip regarding clock edge and master-slave flip-flops)
>
> This is whereI disagree, and this is the reason for continuing this
pedantic
> thread:
> A flip-flop can NEVER miss a clock. There is NO way to sneak the clock
from one
> level to the other, without the flip-flop recognizing it.
> That's always my argument when users complain that a counter bit does not
> toggle. It cannot avoid toggling, but it might have toggled twice, which
looks
> deceptively like no toggle...
>

The one I remember being told not to do, though maybe it doesn't
exactly apply here, has to do with reset on asynchronous counters.

If you want an asynchronous BCD counter, you can set up an
AND gate to reset the counter when it gets to B'1010'.  It is possible
that the such reset signal won't reset all the FF's before the reset
signal goes away.

In the case of edge triggered FF's, say for a falling edge, I would
expect there to be a case where the clock wasn't high long enough
before the falling edge.

I seem to remember some circuit that I think Peter posted before
containing two FF's where one times the signal for the other such
that it can be guaranteed to have the right timing.  I can't remember
any more about it than that, though.

-- glen




Article: 49114
Subject: Re: Metastability results are finally posted
From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Fri, 01 Nov 2002 05:10:36 GMT
Links: << >>  << T >>  << A >>

"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message
news:bRmw9.372$t4.32691@newsread2.prod.itd.earthlink.net...
Peter,

How in the HELL were you able to control the phase of a clock with (less
than) 0.03 fs resolution?

Does this mean that the DCM's in your new Virtex-III's will have femtosecond
phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ?
Routing delays too low to publish?

1e-18 is atto.   There are people who study how a chemical reaction
happens between two atoms with attosecond range laser pulses.

In 1as light travels 3A, about the diameter of an atom.

-- glen



Article: 49115
Subject: Re: Metastability results are finally posted
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 01 Nov 2002 05:27:30 GMT
Links: << >>  << T >>  << A >>
On Fri, 01 Nov 2002 05:10:36 GMT, "glen herrmannsfeldt"
<gah@ugcs.caltech.edu> wrote:

>
>"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message
>news:bRmw9.372$t4.32691@newsread2.prod.itd.earthlink.net...
>Peter,
>
>How in the HELL were you able to control the phase of a clock with (less
>than) 0.03 fs resolution?
>
>Does this mean that the DCM's in your new Virtex-III's will have femtosecond
>phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ?
>Routing delays too low to publish?

No, no.  It's all statistical.  The clock and "data" are asynchronous,
which means that, over time, all different phase alignments will be
tested.

If the clock period is (say) 3 ns, and 1 in every million "tests"
produces an event, then the window size is 3 ns / 1e6 = 3 fs.  Or
something like that.

Regards,
Allan.

Article: 49116
Subject: Re: Xilinx FPGA <> CPLD implementation "mis-match"
From: Bill Turnip <BTurnip@wellspring.org>
Date: Fri, 01 Nov 2002 05:35:08 GMT
Links: << >>  << T >>  << A >>
Georgi -

     You hit the nail on the head.  Thanks.

Bill


Georgi Beloev wrote:
> 
> Bill,
> 
> Have you simulated the powerup process of your CPLD design? To be more
> specific you have to include the following code in your testbench:
> 
> reg PRLD;
> assign glbl.PRLD = PRLD;
> 
> initial begin
>   PRLD = 1;
>   #100;
>   PRLD = 0;
> end
> 
> This tells the simulator that you are powering up the device and it
> will assign your power-up values to the signals. Otherwise they show
> as "X"s.
> 
> Regards,
> -- Georgi
> 
> Bill Turnip <BTurnip@wellspring.org> wrote in message news:<3DBE9D24.9206C4F@wellspring.org>...
> > SH7 -
> >
> >      I did as you suggested, installing and overwriting a boatload of
> > files.
> > Alas, no positive results yet.
> >      I slowed down the clock and selected a faster part as well.  No
> > dice.
> >
> > Bill
> >
> > Spam Hater wrote:
> > >
> > > Bill,
> > >
> > > Did you install the ModelSim library updates?  The ones that come in a
> > > zip file so there's no way to back them out?
> > >
> > > If so, that's your problem.  I had to re-install ModelSim to get rid
> > > of them to fix the same problem.
> > >
> > > Dig into the waveform of the post-fit cpld, and you will see way too
> > > many X's on the signals.
> > >
> > > SH7
> > >
> > > On Sun, 27 Oct 2002 15:07:59 GMT, Bill Turnip <BTurnip@wellspring.org>
> > > wrote:
> > >
> > > >Hello group:
> > > >     I'll try to keep this short.  I have a simple asynchronous Verilog
> > > >module that takes 3 inputs to produce a few simple outputs.
> > > >Behavorially, the module works fine.  I pumped the design through
> > > >WebPACK and targeted an FPGA as well as a CPLD.  Behavorially, the
> > > >post-PAR and post-fit models simulate and match the behavorial model
> > > >(now with various delays, of course).  To switch back and forth between
> > > >FPGA <> CPLD I simply changed the "properties" of the project, and
> > > >re-synthesized, etc.  The verilog code for the module being implemented
> > > >as well as the testbench were the same for both the FPGA and CPLD
> > > >cases.  I let the Xilinx IDE handle all the background stuff for the
> > > >ModelSim simulations of the post-PAR, post-Fit models.
> > > >     So, I then made the design synchronous - added a clock as well as a
> > > >reset and made small modifications to the testbench - and repeated the
> > > >exercise above.  The FPGA implementation works fine, with the behavorial
> > > >functionality matching the post-PAR (and post-map, post-translate, etc.)
> > > >functionality, now with delays of course.  However, the post-fit CPLD
> > > >implementation does not work functionally at all!  Again, I am using the
> > > >same testbench and verilog code for the two synchronous
> > > >implementations.  It seems the post-Fit CPLD design is "stuck."  The
> > > >outputs are correct for the first set of inputs passed to it from the
> > > >testbench, but after this they never change, as if time is not passing.
> > > >But the same exact code works for the FPGA!  I'm new to this area, but
> > > >it doesn't seem to make sense.  Do I need to do something special for
> > > >the clock or reset in the post-Fit code for the CPLD that is transparent
> > > >for the FPGA?  I expected the CPLD implementation to be easier and less
> > > >complicated.
> > > >    Thanks for any insight to this very interesting issue.
> > > >- BT

Article: 49117
Subject: FDRE inference in Synplify
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Fri, 01 Nov 2002 05:35:49 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm trying to write some VHDL that will infer an FDRE (ff with clock
enable and *sychronous* reset) in a Xilinx Virtex-E or -2 device.

We've tried several versions of Synplify Pro 7.x, and they all waste a
LUT to implement the synchronous reset function.

The code used looks something like this:

  foo : process (gsr, clk)
  begin
    if gsr = '1' then
      ff <= '0';
    elsif rising_edge(clk) then
      if sync_reset = '1' then
        ff <= '0';
      elsif clk_enable = '1' then
        ff <= other_sig;
      end if;
    end if;
  end process foo;

Gsr can be traced back to the gsr input of a startup block.

Does anyone know how to do this without wasting a LUT?

TIA,
Allan.

Article: 49118
Subject: Re: Xilinx FPGA <> CPLD implementation "mis-match"
From: Bill Turnip <BTurnip@wellspring.org>
Date: Fri, 01 Nov 2002 05:44:26 GMT
Links: << >>  << T >>  << A >>
GEorgi -
 
     I forgot to ask: why does my FPGA implementation work without this
(or
an equivalent) statement?

Bill

Bill Turnip wrote:
> 
> Georgi -
> 
>      You hit the nail on the head.  Thanks.
> 
> Bill
> 
> Georgi Beloev wrote:
> >
> > Bill,
> >
> > Have you simulated the powerup process of your CPLD design? To be more
> > specific you have to include the following code in your testbench:
> >
> > reg PRLD;
> > assign glbl.PRLD = PRLD;
> >
> > initial begin
> >   PRLD = 1;
> >   #100;
> >   PRLD = 0;
> > end
> >
> > This tells the simulator that you are powering up the device and it
> > will assign your power-up values to the signals. Otherwise they show
> > as "X"s.
> >
> > Regards,
> > -- Georgi
> >
> > Bill Turnip <BTurnip@wellspring.org> wrote in message news:<3DBE9D24.9206C4F@wellspring.org>...
> > > SH7 -
> > >
> > >      I did as you suggested, installing and overwriting a boatload of
> > > files.
> > > Alas, no positive results yet.
> > >      I slowed down the clock and selected a faster part as well.  No
> > > dice.
> > >
> > > Bill
> > >
> > > Spam Hater wrote:
> > > >
> > > > Bill,
> > > >
> > > > Did you install the ModelSim library updates?  The ones that come in a
> > > > zip file so there's no way to back them out?
> > > >
> > > > If so, that's your problem.  I had to re-install ModelSim to get rid
> > > > of them to fix the same problem.
> > > >
> > > > Dig into the waveform of the post-fit cpld, and you will see way too
> > > > many X's on the signals.
> > > >
> > > > SH7
> > > >
> > > > On Sun, 27 Oct 2002 15:07:59 GMT, Bill Turnip <BTurnip@wellspring.org>
> > > > wrote:
> > > >
> > > > >Hello group:
> > > > >     I'll try to keep this short.  I have a simple asynchronous Verilog
> > > > >module that takes 3 inputs to produce a few simple outputs.
> > > > >Behavorially, the module works fine.  I pumped the design through
> > > > >WebPACK and targeted an FPGA as well as a CPLD.  Behavorially, the
> > > > >post-PAR and post-fit models simulate and match the behavorial model
> > > > >(now with various delays, of course).  To switch back and forth between
> > > > >FPGA <> CPLD I simply changed the "properties" of the project, and
> > > > >re-synthesized, etc.  The verilog code for the module being implemented
> > > > >as well as the testbench were the same for both the FPGA and CPLD
> > > > >cases.  I let the Xilinx IDE handle all the background stuff for the
> > > > >ModelSim simulations of the post-PAR, post-Fit models.
> > > > >     So, I then made the design synchronous - added a clock as well as a
> > > > >reset and made small modifications to the testbench - and repeated the
> > > > >exercise above.  The FPGA implementation works fine, with the behavorial
> > > > >functionality matching the post-PAR (and post-map, post-translate, etc.)
> > > > >functionality, now with delays of course.  However, the post-fit CPLD
> > > > >implementation does not work functionally at all!  Again, I am using the
> > > > >same testbench and verilog code for the two synchronous
> > > > >implementations.  It seems the post-Fit CPLD design is "stuck."  The
> > > > >outputs are correct for the first set of inputs passed to it from the
> > > > >testbench, but after this they never change, as if time is not passing.
> > > > >But the same exact code works for the FPGA!  I'm new to this area, but
> > > > >it doesn't seem to make sense.  Do I need to do something special for
> > > > >the clock or reset in the post-Fit code for the CPLD that is transparent
> > > > >for the FPGA?  I expected the CPLD implementation to be easier and less
> > > > >complicated.
> > > > >    Thanks for any insight to this very interesting issue.
> > > > >- BT

Article: 49119
Subject: Re: Modelsim help
From: Bill Turnip <BTurnip@wellspring.org>
Date: Fri, 01 Nov 2002 05:58:16 GMT
Links: << >>  << T >>  << A >>
Peng -
     I don't understand; I have the same version of ModelSim and 
I run 30 to 40 thousand lines of code.  I get warned that I
have exceeded the starter version limit and that the "Simulation
run time might be quite adversely affected," but it still takes only
a few - OK, maybe several - seconds to run the simulation on my PIII
750MHz laptop.  
     Try an older version of Modelsim; I've heard the latest version
that comes with Webpack 5.1 will only run for 30 days, while the Webpack
4.3 version is not as restricted.  Or so I've been told...

Bill



Colin Paul Gloster wrote:
> 
> Peng Cong wrote:
> "Xilinx ISE 5.1 + Modelsim 5.5e
> 
> When I use modelsim for simulation, it always propmt
> "Evaluation memory limit reached".
> How can I solve this problem?"
> 
> Unfortunately this is a problem with the restricted
> version of Modelsim which Xilinx gives away for free.
> You can choose to:
> * not run your simulation in Modelsim;
> * make a smaller system to simulate, small enough to fit in the memory
> restrictions of Modelsim XE;
> or
> * buy a full copy of Modelsim.

Article: 49120
Subject: Re: Metastability results are finally posted
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 01 Nov 2002 19:06:41 +1300
Links: << >>  << T >>  << A >>
Allan Herriman wrote:
> 
> On Fri, 01 Nov 2002 05:10:36 GMT, "glen herrmannsfeldt"
> <gah@ugcs.caltech.edu> wrote:
> 
> >
> >"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message
> >news:bRmw9.372$t4.32691@newsread2.prod.itd.earthlink.net...
> >Peter,
> >
> >How in the HELL were you able to control the phase of a clock with (less
> >than) 0.03 fs resolution?
> >
> >Does this mean that the DCM's in your new Virtex-III's will have femtosecond
> >phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ?
> >Routing delays too low to publish?
> 
> No, no.  It's all statistical.  The clock and "data" are asynchronous,
> which means that, over time, all different phase alignments will be
> tested.

Hopefully :)

> 
> If the clock period is (say) 3 ns, and 1 in every million "tests"
> produces an event, then the window size is 3 ns / 1e6 = 3 fs.  Or
> something like that.

  Light travels 9nm in .03fs, or appx 1/20 of the gate lengths of the
FETS

 ( This excludes velocity factors, or electron wave effects )

 
 Next task for Peter is to give a curve plot, of the 
Effective Aperture (in fs), against the Event Extension lifetime ( in ps
) :)

 We have one point : 500ps / 0.03fs

 Anyone care to calculate how many / how far electrons are involved in 
this ?
 ie how close are we to hitting a quantised limit, like Photomultipliers 
behave with photons ?

 Jim G.

Article: 49121
Subject: Re: Metastability results are finally posted
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Fri, 1 Nov 2002 01:37:18 -0500
Links: << >>  << T >>  << A >>
> >How in the HELL were you able to control the phase of a clock with (less
> >than) 0.03 fs resolution?
> >
> >Does this mean that the DCM's in your new Virtex-III's will have
femtosecond
> >phase-shifter adjustability? Jitter in the milli-femtoseconds (unit
name?) ?
> >Routing delays too low to publish?
>
> No, no.  It's all statistical.  The clock and "data" are asynchronous,
> which means that, over time, all different phase alignments will be
> tested.
>
> If the clock period is (say) 3 ns, and 1 in every million "tests"
> produces an event, then the window size is 3 ns / 1e6 = 3 fs.  Or
> something like that.
>

Duh, is it possible to use the event occurances as some form of clock ?





Article: 49122
Subject: Reference Schematics
From: sonu@vinchip.com (Sonu Abraham)
Date: 31 Oct 2002 23:21:32 -0800
Links: << >>  << T >>  << A >>
Hi all,
Does anybody has any reference schematics based on Altera's ARM Based
Excalibur series of FPGAs..
Sonu

Article: 49123
Subject: Re: FPGA convert to ASIC
From: "Bezamat James" <bezamat.james@wanadoo.fr>
Date: Fri, 1 Nov 2002 08:43:50 +0100
Links: << >>  << T >>  << A >>
Hello,
Every thing is possible, and retargetting FPGA to ASIC, or ASIC to FPGA is a
common activitie for design centers.
 The main factors are technicals and financials :
- A digital design, with very small limitations in term of gate number,
memory size, use of IPs, macro blocks, frequency and so on (FPGA
capabilities are, today, not so far from ASIC-pure digital- capabilities).

Regards
James

--
James BEZAMAT
bezamat.james@wanadoo.fr
"alla" <alng23@hotmail.com> a écrit dans le message de news:
aps669$cdd$1@tilde.itg.ti.com...
> Just want see anyone here has any experience of converting a Xilinx FPGA
> design into an ASIC implementation. If so, which vendor did you use?
What's
> the cost? Are you happy with the result? We are using the Virtex series
and
> considering this option. Thanks
>
>



Article: 49124
Subject: Re: FDRE inference in Synplify
From: "Alan Fitch" <alan.fitch@doulos.com>
Date: Fri, 1 Nov 2002 09:16:36 -0000
Links: << >>  << T >>  << A >>


"Allan Herriman" <allan_herriman.hates.spam@agilent.com> wrote in
message news:3dc210cc.14049401@netnews.agilent.com...
> Hi,
>
> I'm trying to write some VHDL that will infer an FDRE (ff with
clock
> enable and *sychronous* reset) in a Xilinx Virtex-E or -2
device.
>
> We've tried several versions of Synplify Pro 7.x, and they all
waste a
> LUT to implement the synchronous reset function.
>
> The code used looks something like this:
>
>   foo : process (gsr, clk)
>   begin
>     if gsr = '1' then
>       ff <= '0';
>     elsif rising_edge(clk) then
>       if sync_reset = '1' then
>         ff <= '0';
>       elsif clk_enable = '1' then
>         ff <= other_sig;
>       end if;
>     end if;
>   end process foo;
>
> Gsr can be traced back to the gsr input of a startup block.
>
> Does anyone know how to do this without wasting a LUT?
>
> TIA,
> Allan.

I don't know if this is possible in your design,
but Xilinx recommend that you don't use GSR in Virtex
devices. So I would just write

>   foo : process (clk)
>   begin
>     if rising_edge(clk) then
>       if sync_reset = '1' then
>         ff <= '0';
>       elsif clk_enable = '1' then
>         ff <= other_sig;
>       end if;
>     end if;
>   end process foo;

Of course this will only get reset on configuration.

Do you need the global reset functionally, i.e. do you
use it in your application, rather than just letting
reset on configuration happen?


regards

Alan


--
Alan Fitch
www.doulos.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