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 25525

Article: 25525
Subject: Re: Complaint: Xilinx functional simulation libraries
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 13 Sep 2000 10:43:24 GMT
Links: << >>  << T >>  << A >>
On Tue, 12 Sep 2000 17:27:35 -0700, Andy Peters <"apeters <"@> n o a o
[.] e d u> wrote:

>File this under "Why do they do it this way?"
>...
>Why do they put any kind of delay mechanism into something that's
>supposed to be used for functional simulations?  When I do the logic
>design, I'm not concerned about timing!
>
>-- andy

I agree. The rest of this is exactly the same as a message I wrote on
another thread a couple of weeks ago, but I won't let that stop me :)

I'm pretty sure everything works fine if you set your sim timing
resolution to ns; this is much easier than any of the other proposed
fixes. This works because all the default delays in Unisims are
sub-nanosecond, and so they're all truncated to zero.

Only problem is, if you've got a DLL in your design, it wont lock up
on a ns resolution, so you have to set ps resolution in your
simulator. This is because the DLL model actually does attempt to lock
up by moving its delay line tap in 100ps increments. I think this is
the fundamental problem - the Unisims DLL model is basically doing a
timing simulation. One fix is for the author to modify it so that it
assumes that it's already locked up; I think this would be an
acceptable limitation on its use. It could still carry out checks to
find out if it's possible to lock. I've CC'ed the author, so we may
get an official line with some luck.

Whatever you do with the timing resolution, you should also set the
'TimingChecksOn' generic false on the simulator command line, or set
another option to turn off timing checks (+notimingchecks in
ModelSim). This'll fix the problem anyway and should make the
simulation faster.

Evan
Article: 25526
Subject: Virtex 'shutdown' phenomenon
From: news@rtrussell.co.uk
Date: 13 Sep 2000 11:20:12 GMT
Links: << >>  << T >>  << A >>
We are experiencing a peculiar phenomenon with a Virtex
part (XCV600) which has us stumped.  Initially,
following configuration, all is well and the part works
exactly as it should.  However, a variable amount of
time later (sometimes as little as a fraction of a
second, sometimes as much as half an hour) the part
stops working, the current drawn drops considerably
(as if the clock has stopped, or there are no data
transitions) and all the outputs stick at logic '0',
although the DONE line remains high.  Even outputs
which are complementary in normal operation go low
together.

The time it takes before the failure occurs is very
data-dependent.  We can influence this period by
changing the input data (digital video) from having
few transitions - in which case it survives longer -
to having many transitions - in which case it runs
for only a short time.  Cooling the chip increases
the time for which it runs with a given input.

All the inputs and power supplies seem to be OK, and
there is good decoupling on the power rails.  Once the
fault has occurred the only way of restoring correct
operation is to re-configure the chip.  Is this effect
consistent with the chip losing its configuration data,
and if so why should this be happening?  Are there any
other stable, but non-functioning, states which can
be activated by ground-bounce or other data-dependent
triggers ? 

Richard Russell
http://www.rtrussell.co.uk/
Article: 25527
Subject: Re: Virtex 1800 series ISP proms
From: "Peter Schulz" <p.schulz@signaal.de>
Date: Wed, 13 Sep 2000 14:35:44 +0200
Links: << >>  << T >>  << A >>
If you have an engineering sample of the 1804
the CF pin must be left unconnected

Peter Schulz

Tom Leacock schrieb in Nachricht <39BE4FFC.E100FA84@pavcal.com>...
>Has anyone had any success programming the XC1804 ISP proms for Xilnx
>virtex parts with the JTAG download? I am using the  XC1804-pc44 proms
>and multi-linx downloader, but the JTAG interface does not even
>recognize the proms.
>-- Thanks,
>--Tom
>----------------------------------------------
>Thomas Leacock
>Panasonic AVC American Laboratories (PAVCAL)
>311 Main Street
>Westampton NJ 08060
>Phone: 609-518-3700 ext. 3218
>Fax:   609-518-3720
>email: toml@pavcal.com
>----------------------------------------------


Article: 25528
Subject: Re: Clock skew in XILINX CPLD
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Wed, 13 Sep 2000 13:30:17 GMT
Links: << >>  << T >>  << A >>
Thomas,
     Of course I still call my company Synchronous Design!  Parallel
synchronizers are simply a no-no design technique of synchronous design.
There is a whole set of rules that I use to synchronize asynchronous
signals, and parallel synchronizers is a prohibited practice.  There is a
simple way around this particular problem, though.
     I found out a long time ago that if I used synchronous techniques, I
don't have to do a lot of analysis and design to verify asynchronous
operation and noise abatement issues.  Timing is trivialized to a few types
such as input setup and hold,  register to register delays, and clock to
output delays.  As technology progressed from board level SSI/MSI to
ASIC/FPGA designs, synchronous techniques became even more important, since
machines are doing most of the routing.
     I once had an engineer tell me that synchronous designers aren't as
good as asynchronous designers.  He was referring to the detailed analysis
that he had to do to verify that an asynchronous state machine worked
properly.  I agreed with him that I didn't have to do that type of
anaylysis, and I also agreed that I was a little rusty in that department.
Three years later his design started failing out in the field.  He had
failed to analyze his design sufficiently to accommodate wear and tear on
the transistors over the years.
     This does not mean that I will not pay attention to asynchronous
design, though.  Technology changes rapidly in a few years to where I have
to pay attention to anything related to our field of expertise.  In fact,
there is a company here in town called Theseus Logic that specializes in
clockless logic.  They have a lot of funding, so someone thinks that this
technology is worth a shot.  I have not investigated it, because I am very
busy, but I will soon just to find out what they are doing.  Maybe I can
learn something that I can apply to what I am doing.  They have white papers
on their web site if anyone cares to indulge.
     I hope I have answered your question sufficiently for you to understand
why Sychronous Design is alive and well.
-Simon Ramirez, Consultant
-Sychronous Design, Inc.


"Thomas Falk " <falk@iee.et.tu-dresden.de> wrote in message
news:8pn9uu$bd4$1@rks1.urz.tu-dresden.de...
> Hi Simon,
>
> thanks for your answer. In my case the parallel input works fortunately,
> but some of the logik detecting slopes in slow impulse trains does fail.
>
> Interestingly enough, there seems to be a lot of experiences in this
> group with similar problems, but I haven't heard anything from XILINX yet.
>
> Thanks,
>
> Thomas
>
> PS: Simon, despite your experiences with synchronizers you call your
> company still Synchronous Design ?   ;-)
>
>


Article: 25529
Subject: Re: VirtexE availability?
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Wed, 13 Sep 2000 13:40:01 GMT
Links: << >>  << T >>  << A >>

"Mark Harvey" <mark.harvey@iol.it> wrote in message
news:EjCv5.16916$Sm1.265203@news.infostrada.it...

> The rep in my area certainly doesn't lack any balls!

--I am glad.  What is her name?


> Again, if the disti has been dishonest or exaggerated his/her tech
support,
> then they deserve to be put in their place.

--This happens a lot.  All it takes is lost sales.


> > --I agree with you here 100%.  I bet that if Andy, the original poster,
had
> > a darn good Xilinx specific disty FAE, he wouldn't have the problem he
is
> > having.  His problem (my opinion) is that the disties are asking him a
lot
> > of questions, contributing nothing to his cause, wasting his time, and
> they are still getting the registration!
>
> But somebody, somewhere HAS to register the design.

--Yes and no.  That somebody is the Xilinx FAE, but we're not talking about
him, we're talking about disties.  A disty does not need to be involved,
i.e., register a design, every time.  Just ask the direct accounts.

-Simon Ramirez, Consultant
 Synchronous Design, Inc.


Article: 25530
Subject: sw
From: "Rinux" <rinocirr@iternet.it>
Date: Wed, 13 Sep 2000 15:57:35 +0200
Links: << >>  << T >>  << A >>
wath software can I use to program 16v8 and 22v10 ???


Article: 25531
Subject: Re: Clock skew in XILINX CPLD
From: falk@iee.et.tu-dresden.de (Thomas Falk )
Date: 13 Sep 2000 14:00:47 GMT
Links: << >>  << T >>  << A >>
In article <39BF49EB.4A5D@designtools.co.nz>,
	Jim Granville <jim.granville@designtools.co.nz> writes:
> Can you clarify 'slopes in slow inpulse trains' - are these slow edges,
> and how many registers do they feed ?

Hi Jim,

Exuse my English, I meaned the edges of impulses. In my case the output
of a D-FF was feed into the D input of another one and from this I wanted
to detect the edge by a logic combination of input and output of the second
D-FF. 

The timing simulation showed that in my case the change of the data arrived
earlier than the corresponding clock edge. The clock came via a global net
GCK1. 

Thomas
Article: 25532
Subject: Re: Complaint: Xilinx functional simulation libraries
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Sep 2000 14:15:14 GMT
Links: << >>  << T >>  << A >>
Well, it has been working for me. Virtually all of my designs are a mix of
structural (instantiated) and RTL code.  I tried setting the simulator
resolution to get around it, but that kept the DLLs from working.  Setting the
generics seems to do the trick.  Why it defaults to On for a library that is
ostensibly for FUNCTIONAL simulation is beyond me.

"K. Orthner" wrote:
> 
> Ray,
> 
> You mean I didn't have to go recompile the unisim libraries?  It's as easy
> as setting the generic to FALSE?  Then all the nasty timing ptoblems go
> away?
> 
> ray@andraka.com (Ray Andraka) wrote in <39BF2224.8921F01@andraka.com>:
> 
> >I also ran into the same thing.  When you instantiate the clocked unisim
> >components, set the TimingChecksOn generic to "FALSE" to disable the
> >timing crap.  You'll also have to surround the generic in the
> >declaration with syn_translate on and off pragmas to keep the synthesis
> >from complaining.  For example:

-- 
-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: 25533
Subject: Re: Is this practical?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Sep 2000 14:19:16 GMT
Links: << >>  << T >>  << A >>


Michael Warner wrote:
> ster should be sufficient.
> 
> Yes, they are, and that approach did occur to me. Would it be simpler
> than 64 simple ripple counters?

Yikes, no! use synchronous counters.  With the carry chain it takes up the same
area and everything runs off a common clock


-- 
-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: 25534
Subject: Re: Is this practical?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Sep 2000 14:22:30 GMT
Links: << >>  << T >>  << A >>
I don't know hom much you will find in the literature about multiplied clocks in
this context.  Just use a master clock that is say 16x your data rate.  Of every
16 clock cycles, one is dedicated for processing a particular channel.  That
allows you to share the accumulator over many channels,  The intermediate strage
for each channel should then be kept in a small synchronous RAM instead of
individual registers.  The RAM address is the 'time slot'.  ALternatively, you
can use a shift register in place of the RAM.

Michael Warner wrote:
> 
> On Tue, 12 Sep 2000 11:59:31 GMT, Ray Andraka <ray@andraka.com> wrote:
> 
> >what is the available clock and required sample rate?  If you can supply a
> >multiplied clock, you can reduce the size of the logic substantially.
> 
> It's pretty slow - the PWM time-slice is probably no less than 1us.
> I'll have to read up on these "multiplied clocks", since they seem to
> be the key to success :-)
> 
> Thanks for your help, folks!

-- 
-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: 25535
Subject: Re: MEMORY
From: husby@my-deja.com
Date: Wed, 13 Sep 2000 15:20:33 GMT
Links: << >>  << T >>  << A >>
"psisabel" <psisabel@mii.zaz.com.br> wrote:
> Somebody would have a schematic of memory ram or
> salary so that I can accomplish a project

Salary? Do you mean cache?



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25536
Subject: Re: virtex shape
From: husby@my-deja.com
Date: Wed, 13 Sep 2000 15:25:20 GMT
Links: << >>  << T >>  << A >>
 erika_uk@my-deja.com wrote:
> why virtex chips are rectangular and not square

My guess is because the BlockRam takes up several columns
which, if filled with CLBs would make it square.



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25537
Subject: Re: ABEL trouble with XC95108 and Foundation 2.1i SPVI
From: Hawker <Hawker@connriver.net>
Date: Wed, 13 Sep 2000 11:25:37 -0400
Links: << >>  << T >>  << A >>

An update after wasting yet another day with this.
After reading about some other XC95xxx problems on this NG someone mentioned
moving optimizing method and things working.. So After extensive playing
I found that if either "use timing optimization" or "Using MultiLevel
Optimization"
were checked my ABEL Script failed miserably.  Changing other settings (like
PTERM limit)
only changed how the symptoms looked.
Problem is I changed from almost fitting in one size down (9572) to barely
fitting in 
what I am using (95108) which scares me incase I have to add to the design as
there is no
drop in package one size up for me.
Interestingly I have ALWAYS found that Using MultiLevel Optimization makes the
design
take more equations, not less which seems odd.

So any thoughts on this.  Is this Foundation screwing up or am I implementing my 
ABEL BCD-7 SEG LCD driver incorrectly?

Thanx
  Rick
Article: 25538
Subject: Re: MEMORY
From: Hawker <Hawker@connriver.net>
Date: Wed, 13 Sep 2000 12:52:32 -0400
Links: << >>  << T >>  << A >>

Darn Language Translators I bet..
Good catch.. I had been scratching my head trying to figure
out what he meant.  Cache=cash=Salary  I didn't get that far.
I was trying to figure out if he was asking how much it would cost
in Salary to get someone to do this part of his "project".

Anyway psisabel:
You'll have to give us more info on what you want as I am
not clear.. Are you looking for a schematic of how
traditional memory is implemented on a logic level
or do you have something more specific in mind or what
exactly are you after.

Hawker


husby@my-deja.com wrote:
> 
> "psisabel" <psisabel@mii.zaz.com.br> wrote:
> > Somebody would have a schematic of memory ram or
> > salary so that I can accomplish a project
> 
> Salary? Do you mean cache?
>
Article: 25539
Subject: Re: Virtex 'shutdown' phenomenon
From: Hawker <Hawker@connriver.net>
Date: Wed, 13 Sep 2000 12:56:29 -0400
Links: << >>  << T >>  << A >>


Are you going into some sort of boundary scan mode?
I had a similar problem with a XCS05.  I found some
sort of app note about adding some pull-ups and 2 small caps
to the JTAG pins and it fixed the problem. Basically random noise
was putting me an a boundary scan or JTAG programing mode of some sort
Can't remember what
exactly it was as it is now a block in PADS-PCB/Logic that I just plop down
that gives me all the parts I need for JTAG (header, caps, resistor etc)
so I have long forgotten the exacts.. but can look up if needed.

Hawker
Article: 25540
Subject: Re: Complaint: Xilinx functional simulation libraries
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 13 Sep 2000 10:35:35 -0700
Links: << >>  << T >>  << A >>
"K. Orthner" wrote:
> 
> Ray,
> 
> You mean I didn't have to go recompile the unisim libraries?  It's as easy
> as setting the generic to FALSE?  Then all the nasty timing ptoblems go
> away?

No, TimingChecksOn = FALSE disables the setup/hold/etc tests.  The
delays are still there.
 
> ray@andraka.com (Ray Andraka) wrote in <39BF2224.8921F01@andraka.com>:
> 
> >I also ran into the same thing.  When you instantiate the clocked unisim
> >components, set the TimingChecksOn generic to "FALSE" to disable the
> >timing crap.  You'll also have to surround the generic in the
> >declaration with syn_translate on and off pragmas to keep the synthesis
> >from complaining.  For example:

-- 
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25541
Subject: Re: Complaint: Xilinx functional simulation libraries
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 13 Sep 2000 10:41:27 -0700
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote:
> 
> On Tue, 12 Sep 2000 17:27:35 -0700, Andy Peters <"apeters <"@> n o a o
> [.] e d u> wrote:
> 
> >File this under "Why do they do it this way?"
> >...
> >Why do they put any kind of delay mechanism into something that's
> >supposed to be used for functional simulations?  When I do the logic
> >design, I'm not concerned about timing!
> >
> >-- andy
 
> I agree. The rest of this is exactly the same as a message I wrote on
> another thread a couple of weeks ago, but I won't let that stop me :)

No, no, don't stop!
 
> I'm pretty sure everything works fine if you set your sim timing
> resolution to ns; this is much easier than any of the other proposed
> fixes. This works because all the default delays in Unisims are
> sub-nanosecond, and so they're all truncated to zero.

That's a good idea.  My test benches all have a generic that sets clock
speed, which is arbitrary in a functional simulation, anyway.
 
> Only problem is, if you've got a DLL in your design, it wont lock up

Nope, no DLL yet.  Unless the design isn't fast enough for a Spartan, in
which case it'll go to a Virtex.  I'm still in the "conceptual design"
stage and trying various solutions before I commit to anything.  Or
before they commit me.
 
> Whatever you do with the timing resolution, you should also set the
> 'TimingChecksOn' generic false on the simulator command line, or set
> another option to turn off timing checks (+notimingchecks in
> ModelSim). This'll fix the problem anyway and should make the
> simulation faster.

Does that affect the 100 ps prop delays, too (assuming ps resolution)? 
I think those are still there.
-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25542
Subject: Re: Complaint: Xilinx functional simulation libraries
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 13 Sep 2000 11:19:20 -0700
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote:

> I'm pretty sure everything works fine if you set your sim timing
> resolution to ns; this is much easier than any of the other proposed
> fixes. This works because all the default delays in Unisims are
> sub-nanosecond, and so they're all truncated to zero.

Ah!  Just did the test.  Simulation resolution set to ps (which was my
default, since my last design ran at 80 MHz which requires ps resolution
to deal with 12.5 ns) and everything's screwed up.  (By screwed up, I
mean that my state machine is off by one tick, and not grabbing data
when it's supposed to.)

Set resolution to ns, problem solved.

On 2/2/2000, someone with the initials SG at Xilinx changed the default
for DefaultTimingChecksOn to false, so timing checks aren't being
peformed.

I had opened a Xilinx case about this, and I just discussed it with the
apps guy, so there should be a Xilinx "Answer Record" about this soon. 
I told him that I still didn't think a functional model should have any
kind of timing information in it, and he agreed.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25543
Subject: Re: Clock skew in XILINX CPLD
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Wed, 13 Sep 2000 18:44:05 GMT
Links: << >>  << T >>  << A >>
Thomas,
     There is an easy way to do what you describe below.  I call it digital
differentiation, where the job is to detect an edge, leading or otherwise.
     All you have to do is create a process that delays the signal A by one
clock cycle.  Assuming signal_A is active high, this is easy to do:
           signal_A_delayed <= signal_A;
     Then you simply do the following to create a combinatorial pulse
(signal_A_diff) that is generated at the edge:
          assign signal_A_diff = signal_A & ~signal_A_delayed;   // detect
rising edge
          assign signal_A_diff = ~signal_A & signal_A_Delayed;  // detect
falling edge

     Assuming that you are doing the above, I see no reason why you should
have any problem with timing.  signal_A_diff is a combinatorial signal that
is generated to be used by other flip flops, and its prop delay is part of
the timing between flip flops in a Xilinx net PERIOD constraint.  Thus the
whole design is still synchronous.
     Do you have any causal signals that are going to resets or presets of
flip flops?
-Simon Ramirez, Consultant
-Synchronous Design, Inc.


> Hi Jim,
>
> Exuse my English, I meaned the edges of impulses. In my case the output
> of a D-FF was feed into the D input of another one and from this I wanted
> to detect the edge by a logic combination of input and output of the
second
> D-FF.
>
> The timing simulation showed that in my case the change of the data
arrived
> earlier than the corresponding clock edge. The clock came via a global net
> GCK1.
>
> Thomas
>


Article: 25544
Subject: Re: Virtex 'shutdown' phenomenon
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Wed, 13 Sep 2000 18:48:19 GMT
Links: << >>  << T >>  << A >>
Richard,
     Are you sure that ALL of your inputs are defined?  If you have a
floating input, especially a control pin, it could cause weird problems.
Data dependent noise could then activate some function that causes the
symptoms described below.
-Simon Ramirez, Consultant
-Synchronous Design, Inc.


<news@rtrussell.co.uk> wrote in message
news:8pnntc$2jt$1@nntp0.reith.bbc.co.uk...
> We are experiencing a peculiar phenomenon with a Virtex
> part (XCV600) which has us stumped.  Initially,
> following configuration, all is well and the part works
> exactly as it should.  However, a variable amount of
> time later (sometimes as little as a fraction of a
> second, sometimes as much as half an hour) the part
> stops working, the current drawn drops considerably
> (as if the clock has stopped, or there are no data
> transitions) and all the outputs stick at logic '0',
> although the DONE line remains high.  Even outputs
> which are complementary in normal operation go low
> together.
>
> The time it takes before the failure occurs is very
> data-dependent.  We can influence this period by
> changing the input data (digital video) from having
> few transitions - in which case it survives longer -
> to having many transitions - in which case it runs
> for only a short time.  Cooling the chip increases
> the time for which it runs with a given input.
>
> All the inputs and power supplies seem to be OK, and
> there is good decoupling on the power rails.  Once the
> fault has occurred the only way of restoring correct
> operation is to re-configure the chip.  Is this effect
> consistent with the chip losing its configuration data,
> and if so why should this be happening?  Are there any
> other stable, but non-functioning, states which can
> be activated by ground-bounce or other data-dependent
> triggers ?
>
> Richard Russell
> http://www.rtrussell.co.uk/
>


Article: 25545
Subject: Re: virtex shape
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Sep 2000 19:36:33 GMT
Links: << >>  << T >>  << A >>
Nope, block RAM is, at least conceptually, along the shorter dimension.  

husby@my-deja.com wrote:
> 
>  erika_uk@my-deja.com wrote:
> > why virtex chips are rectangular and not square
> 
> My guess is because the BlockRam takes up several columns
> which, if filled with CLBs would make it square.
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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: 25546
Subject: Re: Complaint: Xilinx functional simulation libraries
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 13 Sep 2000 20:02:39 GMT
Links: << >>  << T >>  << A >>
On Wed, 13 Sep 2000 10:41:27 -0700, Andy Peters <"apeters <"@> n o a o
[.] e d u> wrote:

>eml@riverside-machines.com.NOSPAM wrote:
>> Whatever you do with the timing resolution, you should also set the
>> 'TimingChecksOn' generic false on the simulator command line, or set
>> another option to turn off timing checks (+notimingchecks in
>> ModelSim). This'll fix the problem anyway and should make the
>> simulation faster.
>
>Does that affect the 100 ps prop delays, too (assuming ps resolution)? 
>I think those are still there.
>-- a
>----------------------------
>Andy Peters

You're right, it doesn't affect them. I've just checked and just about
everything of any interest in the library has these delays. So, the
question is, are there any circumstances in which addition of an
arbitrary 100ps delay will screw up a functional sim? I can only think
of two:

1) If you instantiate lots of unisims components in a chain, such that
the cumulative 100ps delays add up to more than a clock period, then
the sim will fall over. Unlikely, but possible.

2) More interesting: the Unisim clock elements (IBUFG/BUFG) also have
the default 100ps delay. If you're into coding guidelines, you'll know
that you shouldn't put a delta delay on a clock by doing something
like
 CLKA <= CLKB
because of the potential for races. This is similar, just much worse -
in fact, it's plain wrong, Mr. Patel, if you're reading this. However,
you can still get around this without modifying the libraries. There
are two problem cases - one for IBUFG, one for BUFG.

(a)
Device Under Test: IBUFG on an input clock, RTL code for the sampled
data
Testbench: Stimulus is produced with zero delay from the clock, and
the stimulus data is resampled in the device by the clock

This is a problem, since the IBUFG delays the clock, but the input
data isn't delayed (because no Unisim component is instantiated),
hence isn't resampled correctly. To fix this, just change your
stimulus-generation code in the testbench to reflect the real setup
and hold you're going to give the device, instead of just doing
zero-delay stimulus. This is much better anyway, since it allows you
to use the same testbench for both functional and timing sims.

This looks something like this:

  -- enter loop HOLD_IN after a clock edge
  while not STOP_SIM loop
    wait for PERIOD - SETUP_IN - HOLD_IN;
    -- reached the setup point: read file, or whatever,
    -- and drive stimulus
    ...
    stimulus <= ...;
    -- deschedule, drive the stimulus, wake up at the next clock edge
    wait for SETUP_IN; 
    wait for HOLD_IN;
    stimulus <= (others => 'X');  -- or whatever
  end loop;
  wait; -- end of sim

(b) second case - instantiating BUFG directly in your code, driving it
from an internal signal. Something like CLKA -> combinatorial logic ->
CLKB. I don't think that there's a problem here, since the RTL code is
presumably not going to try pass signals from domain A to domain B on
the same clock edge, which would just be wrong.

So, here's some modified take-it-or-leave-it advice for functional
sims:

(1)  Don't mess with the libraries
(2)  Turn off timing checks anyway, using a generic on the sim command
line or a specific simulator switch. Not necessary for ns resolution,
but will give a faster sim.
(3)  If you can use ns resolution, then you won't have a problem
(4)  If you have a DLL, then you must use ps resolution
(5)  If you must have ps resolution, then:
(a)  make sure you have turned off timing checks
(b)  In your testbench, don't use zero-delay assignments: use a style
that will be correct for timing sims

Evan
Article: 25547
Subject: Re: Clock skew in XILINX CPLD
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 13 Sep 2000 21:52:39 +0100
Links: << >>  << T >>  << A >>


Thomas Falk wrote:

> In article <39BF49EB.4A5D@designtools.co.nz>,
>         Jim Granville <jim.granville@designtools.co.nz> writes:
> > Can you clarify 'slopes in slow inpulse trains' - are these slow edges,
> > and how many registers do they feed ?
>
> Hi Jim,
>
> Exuse my English, I meaned the edges of impulses. In my case the output
> of a D-FF was feed into the D input of another one and from this I wanted
> to detect the edge by a logic combination of input and output of the second
> D-FF.
>
> The timing simulation showed that in my case the change of the data arrived
> earlier than the corresponding clock edge. The clock came via a global net
> GCK1.
>
> Thomas

I'm not sure if this is right but I've just been looking at the SDF file
produced by the tsim -> ngd2ver chain. For a -7 XC9572 it shows in the very
simple case of a FF that just produces a delayed version of the input:

Delay on input = 2.5 ns.
Global clock delay = 1.5ns
FF setup/hold at its clock pin = 1.5/3.0

Therefore the global timing of the input wrt the clock pin is 2.5/2.0 whereas
the data sheet gives something like 6.5/0.

Is CPLD timing simulation to be trusted ?

I thought Xilinx, like all silicon makers, work very hard to make sure that
their FFs have 0 hold time or at least that the min Tco >  Thld. For ASICs this
means this means that to get post layout hold times o.k. you only have to deal
with the small amount of clock skew introduced by the clock trees.

Article: 25548
Subject: Re: Complaint: Xilinx functional simulation libraries
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 13 Sep 2000 21:09:32 GMT
Links: << >>  << T >>  << A >>
On Wed, 13 Sep 2000 11:19:20 -0700, Andy Peters <"apeters <"@> n o a o
[.] e d u> wrote:

>Ah!  Just did the test.  Simulation resolution set to ps (which was my
>default, since my last design ran at 80 MHz which requires ps resolution
>to deal with 12.5 ns) and everything's screwed up.  (By screwed up, I
>mean that my state machine is off by one tick, and not grabbing data
>when it's supposed to.)
>
>Set resolution to ns, problem solved.

Almost forgot - technically, it's illegal to run the sim with ns
resolution, since the library contains ps delays (LRM 3.1.3.1).
However, I suspect that most simulators can cope with this.

Evan
Article: 25549
Subject: Re: Virtex 'shutdown' phenomenon
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 13 Sep 2000 22:18:34 +0100
Links: << >>  << T >>  << A >>


"S. Ramirez" wrote:

> Richard,
>      Are you sure that ALL of your inputs are defined?  If you have a
> floating input, especially a control pin, it could cause weird problems.
> Data dependent noise could then activate some function that causes the
> symptoms described below.
> -Simon Ramirez, Consultant
> -Synchronous Design, Inc.

I think its more likely the new ``cycle based'' licensing scheme whereby any
design is only allow to run for a certain number of clocks before
maintenance becomes due. You will however still be able to re-use or develop
any of the logic transitions generated from your clock allocation.




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