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
2019JanFebMar2019

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 90275

Article: 90275
Subject: Re: Question about metastability that's been on my mind for a while
From: "rhnlogic@yahoo.com" <rhnlogic@yahoo.com>
Date: 7 Oct 2005 11:26:31 -0700
Links: << >>  << T >>  << A >>
Symon wrote:
> The whole point is that you can never be sure how long the first FF will
> stay metastable. The maximum time it can take to resolve is infinite.

Yes, but the probability that it will take an infinite time to resolve
is zero.  Or at least, the probability of a black hole from outer
space smashing into the circuit is higher.

One has to pick some realistic reliability level (9 9's over 10 years?)
in order to design finite cost hardware.  Then one solution to any
synchronizer is merely to find a flip-flop circuit that resolves in
N clock periods (hopefully only 1) with much higher probability
than needed for you target reliability, and use that time as your
designed-in flop-to-flop synchronization delay.

As for the Schmitt trigger suggestion, yes it might (or might not)
resolve faster; but it's still an analog circuit with finite gain.
Therefore there's still a threshold voltage somewhere.


IMHO. YMMV.
-- 
rhn A.T nicholson d.O.t C-o-M


Article: 90276
Subject: Re: Question about metastability that's been on my mind for a while
From: "rhnlogic@yahoo.com" <rhnlogic@yahoo.com>
Date: 7 Oct 2005 11:38:28 -0700
Links: << >>  << T >>  << A >>
Michael Chan wrote:
> In the problem I was trying to solve, I couldn't treat
> the two clock domains as synchronised, since one clock sometimes led, and
> sometimes lagged the other clock.  This resulted in data changing just as it
> was being sampled.  I was told to add some flipflops to fix up the problems,
> but it didn't seem like a very good solution.  As it was, I sampled data on
> the falling edge of the clock, but I wonder what I could have done if there
> wasn't sufficient timing margin for that to work (taking into account the
> jitter between the two domains).  Actually, thinking about it now I think it
> would have been sufficient to simply sample the output of the negative edge
> triggered flip-flop with a positive edge triggered flip-flop.

I think this is know as isochronous design (not quite asynchronous,
but the same frequency with an unknown phase between clock domains).
The common solution to minimize cycle jitter (random alternation in
synchronizing both before and after the receive clock) is to pick a
receive clock phase farthest from the point most likely to cause
metastable behavior. Then, at least, you lower the probability of
failing to meet setup and hold, and thus have a more predictable
circuit.  DLL's a commonly used for this in DDR and SerDes type
applications.



IMHO. YMMV.
-- 
rhn A.T nicholson d.O.t C-o-M


Article: 90277
Subject: Re: Question about metastability that's been on my mind for a while
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 7 Oct 2005 12:28:14 -0700
Links: << >>  << T >>  << A >>
<rhnlogic@yahoo.com> wrote in message 
news:1128709591.126283.195900@g14g2000cwa.googlegroups.com...
> Symon wrote:
>> The whole point is that you can never be sure how long the first FF will
>> stay metastable. The maximum time it can take to resolve is infinite.
>
> Yes, but the probability that it will take an infinite time to resolve
> is zero.  Or at least, the probability of a black hole from outer
> space smashing into the circuit is higher.
>
Well, of course. But you're quoting me a little out of context. I was 
replying to Raymond's post in which he said:- "So if you are sure that the 
first FF can't stay longer in metastable state than Tperiod-Tsu, you are 
fine."
My point is that you can never be 'sure'. You have to design the system 
using probabilities, as you say.
Cheers, Syms.



Article: 90278
Subject: New Ethernet Development board, open-source
From: "jai.dhar@gmail.com" <jai.dhar@gmail.com>
Date: 7 Oct 2005 13:23:55 -0700
Links: << >>  << T >>  << A >>
Hiya all,

 I just put out my new Dev. board that's open source, but I do sell
assembled units. Thought I would just the link and some specs here for
fun. Any comments are appreciated... the schematics/user-guide/pcb/bom
are all available for download.

http://via.dynalias.org

A feature list (taken from the web page):

FPGA

* Altera Cyclone EP1C12Q240Cx
* -8 Speed grade preloaded, -7 and -6 upon request
* 12,060 LE's - enough for 4 NIOS processors!
* 240 Kbits of on-chip RAM
* 2 PLL's - one pre-loaded with 50MHz oscillator, second upon request
* 1 PLL output header
* 240 QFP package

Programming

* Supports both Byteblaster II and @ltium LiveDesign 3rd party
programmer
* Soft JTAG chain support for Altium programmer
* EPCS4 Active-serial configuration device

RAM

* 256Kx32 / 512K x 16 SRAM with 12 nS access time (10,12,15 and 20 nS
available)
* Easily integrates with both NIOS and @ltium soft-processor

Flash

* Altera EPCS4 configuration device for Active Serial (AS)
configuration on startupt
* 4 Mbits of space allows for a complete image and ~64 Kbyte of
user-code
* 32-Mbit SPI Flash for extended storage of user-code; bootable with
custom bootloader

Ethernet

* National Semiconductor DP83846A 10/100-Base TX PHY with industry
standard MII
* Full-duplex communication and auto-negotiation
* MDIO interface
* 5 LED output signals that are connected to FPGA
* RJ45 jack and integrated magnetics with 2 LEDs connected to FPGA
* Works with Opencores Ethernet MAC and Altium's EMAC controllers

Peripherals

* Dallas I2C Real-time-clock with Battery
* Microchip on-board I2C temperature sensor
* Microchip 512 Kbit I2C EEPROM
* Power-on reset controller
* RS232 port
* 8x LED outputs and 4 pushbuttons + Reset button
* 16x GPIO signals
* 8x 5-Volt inputs and 8x 5-Volt bi-directional signals (can be toggled
by jumper)

Software

* Comes with sample code that communicates with nearly all peripherals
* Altium P*otel and Altera quartus projects with Constraint and Pin
files included
* Support is free!

Daughtercards

* Common daughtercards include ADC, DAC, serial port expander
* Custom design available to suit customer requirements

Feel free to contact me for any other questions. Jai.


Article: 90279
Subject: Re: Virtex4 shift register layout: Horizontal or vertical?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 07 Oct 2005 16:27:50 -0400
Links: << >>  << T >>  << A >>
jjohnson@cs.ucf.edu wrote:

>Summary: Should high-speed shift registers (purely DFFs) flow
>left->right, top->bottom, or does it matter?
>
>Doing a Virtex4 (LX100). I wound up with high-speed inputs (clocks and
>serial data) on the IOBs that run vertically down the center of the
>die. OK for clocks, since the DCMs and BUFGs are also in that center
>column.
>
>Regarding data: I deserialize the inputs, and pass parallel data to
>some large datapath blocks that start on the left edge of the die. I
>constrain all my deserializer logic to use sites near the center column
>to minimize clock skew. (Sorry, I can't use the on-chip deserializers;
>they max out at 10 bits, and I need 12.)
>
>Kind of annoying to take my inputs from the center over to the left,
>and then start flowing left-to-right, but that's just how the layout
>wound up...
>
>Anyway, older Xilinx docs say you should flow left->right, and
>numerical operations should have their MSB flowing downward (?) to make
>best use of carry chains. Is that still the case?
>
>Back to my deserializers: I'm using 20 of them, so that's 40 6-bit
>shift registers (6 bits on rising edge, 6 bits on falling edge), which
>I plan to do manual placement on. I don't want to use the SRL16's (yet;
>long story...), but just DFFs.
>
>I thought left->right flow was perfect for shift registers, but ISE
>seems to place all the DFFs for a downward flow. Actually, since my
>inputs are all down the center column (20 serial data streams) and need
>to go left, horizontal alignment flowing right-to-left makes for best
>placement. Not sure about routing though...
>
>Any suggestions? The data is coming in close to 1Gbps, so the shift
>regs run close to 500 MHz...
>
>Thanks again for all the help; I'll appreciate your input as I work
>another weekend...
>
>  
>
You can still use the deserializers.  Use them as 6 bits and unload them 
at 2x the rate.  Since your data is ~1Gbps, that gets you to an unload 
frequency at about 170 MHz, which is quite easy to deal with.  The 
SRL16's wouldn't help you much for a deserializer.

As far as the layout, unless you are using the carry chains, there is no 
reason to arrange the registers for horizontal flow.  In fact, with the 
V4SX family, you'll find that you'll have more of a vertical flow to use 
the DSP48s anyway.  Direct register to register connections, even 
without an optimal place and route are pretty fast in V4, and I think 
you'll find that 500 MHz is fairly easy to achieve if there is no logic 
between the flip-flops, even in a -10 part.   For high clock rates, you' 
want to avoid the carry chains.  The router doesn't do a very good job 
at getting on and off the chains, even when the driving flip-flop is in 
an adjacent slice, so even if you get lucky and make timing with one PAR 
run, there is a good chance you won't make timing after making design 
changes.  As long as you stay off the carry chains and keep your logic 
to one level between flip-flops, the fabric will run faster than the 
maximum clock spec of the BRAM and DSP48 slices.  That max clock is 400 
MHz for a -10 part, 500 MHz in a -12.  If you avoid logic in front of 
the FF's you can get well past 500 MHz in a -10 part.  Be careful that 
the synthesis doesn't use the sync reset input though, that input is 
dreadfully slow: IIRC more than 2ns tsu.  Synplicity has a nasty habit 
of using the sync reset for logic (which would be a good thing if it 
could be overridden with a switch), which kills the performance of a 
high clock rate design.



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

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 90280
Subject: Re: Avoiding meta stability?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 07 Oct 2005 16:46:04 -0400
Links: << >>  << T >>  << A >>
:
Peter, as I have said before, fast and slow metastability recovery is 
relative.  You very much can still be bitten by metastability in modern 
FPGAs.  Yes the resolution time is decreasing, but so are the clock 
cycle times.

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

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 90281
Subject: Re: Question about metastability that's been on my mind for a while
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 07 Oct 2005 13:55:14 -0700
Links: << >>  << T >>  << A >>
All,

The problem being described is a very practical one.  Many lifetimes 
ago, in a different job, I designed telecom synchronization systems.

These systems looked at references from two separate redundant feeds 
(east-west, or north-south, as they are usually called in the 
literature), and (tried) to keep a local oscillator locked in phase to 
one (or the other, but usually not both) references.

The local oscillator might be pretty good (Stratum 4, just a plain old 
crystal), or might be really quite good (a rubidium steered quartz 
oscillator).

It was inevitable that somewhere, sometime, the phase detectors, 
frequency counters, etc. would get to just the right point, and 
metastable outputs would happen (which led to bad counts, or bad phase 
measurements).  When the phase was "just right" the naturally occurring 
jitter would rock you back and forth across the metastable threshold ....

The result would be that the clock system would suddenly think it was 
terribly out of sync, and slew like crazy to go find phase lock (with 
what it thought was the right phase now).

This was, of course, unacceptable, as all systems sync'd to this one 
would dump their buffers (overflow or underflow).  As well, alarms were 
turned in, references switched, and so on.  Not pretty.

A two stage solution was initially used, and found to be not good 
enough.  We then used a series of what we thought were clever 
arrangements of flip flops and clock edges, all no help (as noted above 
in the other thread, it is easy to make it worse, not better).

Finally, a simple software patch solved the whole problem:  if you 
suddenly think you are WAY OFF, stop, throw the result out, and check 
again.  If you still think you are WAY OFF, then just call the new spot 
your reference (if it really is WAY OFF, then all the damage is done, 
and why should you continue to make all sync'd equipment suffer), and 
turn in a "notification" of poor sync quality (so if someone at the 
network control center feels we are doing the wrong thing, they can 
override and take over control).

As long as this little patch executed about once every 6 months, no one 
cared.

So, the solution to this little problem:  build the best synchronizer 
you can, and also have another means to deal with the inevitable 
"failure" to get a valid result.

Another solution that we never tried was to build three separate 
detection packages for phase and frequency, each offset by a portion of 
the period (like 0, 1/3, and 2/3) and then vote.  If two out of three of 
the detectors said the phase was 0x1234h (yes, it was a 16 bit phase 
detector, 8 bits for the raw number of clocks, and 8 bits for the 
fraction of a clock), then we might go ahead and use that number.  If 
there was no majority, the value would be ignored, and the reading taken 
again.

Austin

Article: 90282
Subject: Re: Xilinx WebPack and command line
From: devb@xess.com
Date: 7 Oct 2005 15:23:16 -0700
Links: << >>  << T >>  << A >>

Sandro wrote:
> d...@xess.com wrote:
> > We have a more recent document that shows how to use makefiles with
> > WebPACK or ISE.  It does not need fe_shell.  You can see it here:
> >
> > http://www.xess.com/appnotes/makefile.html
>
> Maybe that works with ISE 6.x with "projectfile.prj" as ascii file...
>
> any suggest to make it to run with ISE 7.x with "projectfile.ise" as
> binary unknown (for me) format file ?
>
> Sandro

Sandro:

The makefiles only use the .prj and .xst files to get information about
the project and the synthesis options.  These are both ASCII in 6.x.
So the makefiles will work if these are still ASCII in 7.x.

The makefiles don't use anything in the .npl file so they shouldn't be
affected by the switch to .ise binary files in 7.x.


Article: 90283
Subject: Re: PowerPC interrupt latency
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Fri, 07 Oct 2005 16:41:54 -0700
Links: << >>  << T >>  << A >>
Did you turn the caches on?

- Peter


Eli Hughes wrote:
> Hello
> 
> Has anyone here had experience with interrupt latency in a PowerPC block 
>  in a VirtexII Pro?   I did a simple experiment where I setup a PowerPC 
> core where the critical interrupt input is always raised (just tied it 
> to net_vcc in the .mhs file).  I then registered a very simple interrupt 
> handler:
> 
> void MyIrqA(void * arg)
> {
> 
> i = MYIP;  // read a generic register on the PLB Bus
> 
> }
> 
> 
> with built Xilinx Functions:
> 
> XExc_RegisterHandler(XEXC_ID_CRITICAL_INT,    (XExceptionHandler)MyIrqA, 
> (void *)0);
> 
> and then enabled the interrupt with:
> 
> XExc_mEnableExceptions(XEXC_CRITICAL);
> 
> 
> 
> I then monitor a bus read signal for my generic register to see how 
> often it occurrs.  The PLB bus and PowerPC is being clocked at 100MHz on 
> a Digilent VirtexII Pro development board.
> 
> To my surprise, there is almost 10uS between reads!  I know this isn't a 
> PLB bus issue, I can do multiple reads in the interrupt route and the 
> read pulses are within a few bus cycles of each other.
> 
> 
> 
> Is there anythign I can do to help this?  What in the world is Xilinx 
> doing in their BSP to save context that takes 10uS with a 100MHz clock 
> period?
> 
> -Eli Hughes
> 
> 


Article: 90284
Subject: Re: Question about metastability that's been on my mind for a while - mine too, I lived it
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 Oct 2005 21:28:31 -0700
Links: << >>  << T >>  << A >>
Austin described the difficult case where the two frequencies are
supposed to be identical, but are really generated by different
oscillators and thus have an unknown and changing phase relationship.

I think the original question dealt with the simpler case where both
frequencies come from a common source, but have developed a certain
delay difference that -worst case- could be drifting around zero. Which
of course invites metastabilty.
The simple (simplistic?) solution is to offset the edges deliberately,
e.g. by using oppsite polarities.
That avoids metastability, as long as the delay uncertainty never
approaches half a period.
Peter


Article: 90285
Subject: Re: Avoiding meta stability?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 7 Oct 2005 21:38:40 -0700
Links: << >>  << T >>  << A >>
I agree 100%, but remember, the original posting mentioned 1.6 and 24
MHz.
It is hard to imagine that metastabilty would cause any trouble in such
a system, especially when the routing delay from the single
synchronizing flip-flop to it single second synchronizer is kept under
control, guaranteeing 5 or more ns of slack.(Which is very easy, just
change the time spec).
If the original posting had mentioned hundreds of MHz, this thread
would have run very differently.
Peter Alfke


Article: 90286
Subject: Re: Question about metastability that's been on my mind for a while
From: "Raymund Hofmann" <filter002@desinformation.de>
Date: Sat, 8 Oct 2005 14:02:36 +0200
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag 
news:43468fc4$0$49012$14726298@news.sunsite.dk...
> "Raymund Hofmann" <filter002@desinformation.de> wrote in message 
> news:di5qj7$pvg$1@online.de...
>>
>> CMOS is reported not to stay long in such a metastable state.
>> So if you are sure that the first FF can't stay longer in metastable 
>> state than Tperiod-Tsu, you are fine.
>>
> The whole point is that you can never be sure how long the first FF 
> will stay metastable. The maximum time it can take to resolve is 
> infinite.

Yes, our whole life has to deal with probabilities. Lukily they are 
different and selectable.
And the lifetime of our Earth may not be long enough to get a good, fast 
CMOS FF (.18um technology) in metastability for longer than 20ns.

>>
>> In a CMOS FF you could avoid the hypothetical persisting metastable 
>> state by constructing the feedback (of the output stage) with a 
>> schmitt-trigger.
>>
> This doesn't help fix the problem.

Do you hint at the schmitt trigger going metastable >20nS ?
OK, i think on a 7414 this may be demonstrated, but in modern CMOS ?
So the Question would be:

What is the probability distribution of the metastable duration 
comparing the normal FF with a schmitt trigger output state feedback FF?
I guess the schmitt output stage will be significantly better and even 
practically metastable free after 20nS in the lifetime of our Planet.

>>
>> Such a FF should never - by construction - stay in the metastable 
>> state, only the CK->Q time may be affected.
>>
> This is why the problem isn't fixed by the Schmitt idea. The CK->Q 
> time can be anything up to infinite. So, Q can be changing just as the 
> next stage of the circuit tries to sample it. A FF in a metastable 
> state doesn't necessarily have to have a funny output voltage. It's in 
> a state where it hasn't made up its mind what its output should be.

This brings another Idea to my mind:

What about injecting noise in the FF feedback loops which is small 
enough not to alter their (static)performance, but large enough to drive 
the feedback loops (and maybe schmitt triggers) into clipping and thus 
their stable state ?
Practically this is what you get in a FPGA/ASIC due to crosstalk in and 
out of the chip, although it's not uncorrelated white noise.
And the inherent noise of CMOS technology also helps, with the high gain 
of the feedback loops.

Raymund Hofmann 


Article: 90287
Subject: Re: Question about metastability that's been on my mind for a while
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Sat, 08 Oct 2005 17:20:59 GMT
Links: << >>  << T >>  << A >>
On Sat, 8 Oct 2005 14:02:36 +0200, "Raymund Hofmann"
<filter002@desinformation.de> wrote:

<most stuff snipped>

>What is the probability distribution of the metastable duration 
>comparing the normal FF with a schmitt trigger output state feedback FF?
>I guess the schmitt output stage will be significantly better and even 
>practically metastable free after 20nS in the lifetime of our Planet.

Back in 1977, some unfortunate soul wrote to IEEE Transactions on
Computers with a proposal to eliminate metastability through the use
of Schmitt triggers.  A while later, Thomas Chaney, one of the
pioneers in the investigation of metastable operation, wrote a reply.
Chaney went to the trouble of building up a Schmitt-trigger-based
circuit that he deliberately made as clean as possible--good bypassing
and the like--and measured performance with and without the Schmitt
trigger in place.  He concluded that not only did the Schmitt trigger
circuit not eliminate metastability, but it made the metastable
performance of the circuit significantly *worse*.   Even the original
proposer of the idea admitted that, yes, Chaney was right.

>This brings another Idea to my mind:
>
>What about injecting noise in the FF feedback loops which is small 
>enough not to alter their (static)performance, but large enough to drive 
>the feedback loops (and maybe schmitt triggers) into clipping and thus 
>their stable state ?

This is an idea that has been proposed before.  Unfortunately, it's
just as likely that noise will drive you into a metastable state as
out of it.

If you sense some frustration on the part of the old hands in this
group, it's because metastable-fix mania sweeps through here on a
regular basis, and every time the same "fixes" and "improvements" are
trotted out, virtually all of which were disproved ages ago.

Please, please, please, everybody, go to:

http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm

and read the whole thing.  Then look at the bibliography at the end
and read some more.

The subject has been well-researched.  The point is, you don't *have*
to guess, at least not if the vendor gives you a little information on
their metastable performance.  And if there isn't enough information
from the vendor, there are simple ways to trade latency for lower
metastable failure rate.

Let's move on, folks.  Let the healing begin.

Bob Perlman
Cambrian Design Works

Article: 90288
Subject: Opal help please
From: fpbankroll@hotmail.com
Date: 8 Oct 2005 12:13:43 -0700
Links: << >>  << T >>  << A >>
Hello all
I am sure this is a trivial question for you all,but i am getting tired
of breaking pins off my gal  lol.
How do i leave just one of the output pins permanently tristated
without affecting the other outputs?

I use opaljr for writing my equation.

Thanks
Deon Hansen


Article: 90289
Subject: Re: Xilinx WebPack and command line
From: Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com>
Date: Sat, 08 Oct 2005 19:44:09 GMT
Links: << >>  << T >>  << A >>
Hi Remis,

I doubt that running the Xilinx software from command line is going to 
speed up the compilation of your design (Perhaps, buying a faster 
computer is going to solve that problem.), but it can still be done for 
FPGAs in ISE WebPACK contrary to what Xilinx is saying.
Assuming that you are using ISE WebPACK 7.1i, download the following files.

http://www.xilinx.com/support/sw_manuals/xilinx7/download/xst.zip
http://www.xilinx.com/support/sw_manuals/xilinx7/download/dev.zip


The above two documents explain the arguments for the command line 
version of the Xilinx software.
For an example of a sample batch file script, check out page 13 (or 14) 
of the following PDF file.

http://legacy.memec.com/solutions/reference/xilinx/downloads/S-II_PCI_Tutorial.pdf


The above document itself is several years old, but Xilinx software 
doesn't change that much from version of version, so the sample batch 
file script should even work with 7.1i.
 From there, make changes to meet to needs.
Next, make sure that your XILINX environmental variable is pointing to 
your ISE WebPACK install path. (i.e., XILINX=d:\Xilinx)
I hope it works.


Kevin Brace


Remis Norvilis wrote:
> I wonder if there is a posibility to do Xilinx fpga synthesis and
> implementation from command line on WindowsXP platform to speed up the
> process. 
> Xilinx web site mentioned something, that it's only availabe for CPLDs.
> XESS have an app note on how to use Make file to script and automate build
> process. It needs fe_shell utility, but I don't think it comes with WebPack
> edition.


-- 
Brace Design Solutions
Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available 
for as little as $100 for non-commercial, non-profit, personal use.
http://www.bracedesignsolutions.com

Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.

Article: 90290
Subject: Re: Question about metastability that's been on my mind for a while
From: nospam <nospam@nospam.invalid>
Date: Sat, 08 Oct 2005 21:24:52 +0100
Links: << >>  << T >>  << A >>
Bob Perlman <bobsrefusebin@hotmail.com> wrote:

>>What about injecting noise in the FF feedback loops which is small 
>>enough not to alter their (static)performance, but large enough to drive 
>>the feedback loops (and maybe schmitt triggers) into clipping and thus 
>>their stable state ?

>This is an idea that has been proposed before.  Unfortunately, it's
>just as likely that noise will drive you into a metastable state as
>out of it.

It is an idea I proposed before, without any claim that it would reduce the
occurence metastable states only that it would reduce their duration.



Article: 90291
Subject: 3rd party JTAG cables/controllers for Virtex-4
From: "Waage" <chris@ednainc.com>
Date: 8 Oct 2005 13:56:19 -0700
Links: << >>  << T >>  << A >>
I think I know that answer all ready, but I just wanted to but out the
question...

Is there any 3rd party JTAG cable/controller that can be used to
configure Xilinx's
Virtex-4?

Thanks!


Article: 90292
Subject: Re: 3rd party JTAG cables/controllers for Virtex-4
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sun, 9 Oct 2005 14:44:24 +1300
Links: << >>  << T >>  << A >>
why.. the xilinx one is cheap enough
I have seen alternatives... but they weren't much cheaper

Simon

"Waage" <chris@ednainc.com> wrote in message
news:1128804979.089139.49140@g47g2000cwa.googlegroups.com...
> I think I know that answer all ready, but I just wanted to but out the
> question...
>
> Is there any 3rd party JTAG cable/controller that can be used to
> configure Xilinx's
> Virtex-4?
>
> Thanks!
>



Article: 90293
Subject: Library Simprim cannot be found?
From: seabrench@163.com
Date: 9 Oct 2005 04:28:06 -0700
Links: << >>  << T >>  << A >>
hello!
When I use ths XST to synthesis(Simulate Post-translate VHDL Modele) a
project,it tells me errors:
ERROR:HDLParsers:3317...Library SIMPRIM cannot be found.
ERROR:HDLParsers:3013...Library SIMPRIM is not declared.

library SIMPRIM;
use SIMPRIM.VCOMPONENTS.ALL;
use SIMPRIM.VPACKAGE.ALL;

why?How to do it?

Thanks!


Article: 90294
Subject: Re: 3rd party JTAG cables/controllers for Virtex-4
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 9 Oct 2005 12:45:53 +0100
Links: << >>  << T >>  << A >>
There are a number of Parallel Cable III look-alikes available including one 
or two from ourselves. The only thing to watch out for is the minimum 
voltage than they will run at. If a 2.5V programming voltage only is 
available some of the 3rd party cables will not operate. Our PROG1 cable 
will work down to about 2.2V and with mods down to about 1.7V. Our PROG2 
cable which is being released with our Raggedstone1 release in a few weeks 
time with be slightly more restricted and but will operate happily at 2.5V 
and 3.3V.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Very Cheap Spartan3 Development 
Board.
http://www.enterpoint.co.uk

"Waage" <chris@ednainc.com> wrote in message 
news:1128804979.089139.49140@g47g2000cwa.googlegroups.com...
>I think I know that answer all ready, but I just wanted to but out the
> question...
>
> Is there any 3rd party JTAG cable/controller that can be used to
> configure Xilinx's
> Virtex-4?
>
> Thanks!
> 



Article: 90295
Subject: Re: Question about metastability that's been on my mind for a while
From: "Raymund Hofmann" <filter002@desinformation.de>
Date: Sun, 9 Oct 2005 14:27:18 +0200
Links: << >>  << T >>  << A >>

"Bob Perlman" <bobsrefusebin@hotmail.com> schrieb im Newsbeitrag 
news:8mufk156urltejl11o21p7oup8arqq8bi2@4ax.com...
> On Sat, 8 Oct 2005 14:02:36 +0200, "Raymund Hofmann"
> <filter002@desinformation.de> wrote:
>
> <most stuff snipped>
>
>>What is the probability distribution of the metastable duration
>>comparing the normal FF with a schmitt trigger output state feedback 
>>FF?
>>I guess the schmitt output stage will be significantly better and even
>>practically metastable free after 20nS in the lifetime of our Planet.
>
> <some innuendos about unfortunate souls snipped>
>

I was talking about a FF containing a schmitt trigger _in_ it's feedback 
loops. And I was talking about a 7414 schmitt trigger eventually not 
suitable for this (and how to get it inside a FF feedback loop), 
although maybe not detailed enough.

>
>>This brings another Idea to my mind:
>>
>>What about injecting noise in the FF feedback loops which is small
>>enough not to alter their (static)performance, but large enough to 
>>drive
>>the feedback loops (and maybe schmitt triggers) into clipping and thus
>>their stable state ?
>
> This is an idea that has been proposed before.  Unfortunately, it's
> just as likely that noise will drive you into a metastable state as
> out of it.

Metastability is not the question, it's "duration probability" is. Every 
FF has some CK->Q uncertainty(jitter) you could also call "Metastable", 
even with proper setup/hold.

So I can't second this.

>
> If you sense some frustration on the part of the old hands in this
> group, it's because metastable-fix mania sweeps through here on a
> regular basis, and every time the same "fixes" and "improvements" are
> trotted out, virtually all of which were disproved ages ago.

I guess you sense some illusion of superiority.

>
> Please, please, please, everybody, go to:
>
> http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
>
> and read the whole thing.  Then look at the bibliography at the end
> and read some more.

I get partial dyslexia reading the whole thing. This is where I also 
want to expose my Ignorance and explain everything (in my way).

>
> The subject has been well-researched.  The point is, you don't *have*


The ether has also been "well researched" until Albert Einstein.
You are free to defame me of thinking I am a Genius.
Can you also think on your own or do you only quote "well researched" 
subjects ?
Is there a reason individual life is finite by conception ?

> to guess, at least not if the vendor gives you a little information on
> their metastable performance.  And if there isn't enough information
> from the vendor, there are simple ways to trade latency for lower
> metastable failure rate.
>
> Let's move on, folks.  Let the healing begin.
>

Who's healing do you mean ?

Raymund Hofmann 


Article: 90296
Subject: Re: Avoiding meta stability?
From: "Bill" <mr@bredband.net>
Date: Sun, 9 Oct 2005 17:39:50 +0200
Links: << >>  << T >>  << A >>
Thank you, i will do it like you wrote :-)

"Symon" <symon_brewer@hotmail.com> skrev i meddelandet
news:434649c7$0$49021$14726298@news.sunsite.dk...
> Hi Bill,
> Sorry, but your circuit is not good. In fact it wastes some FFs and logic
to
> make the metastability performance worse by many orders of magnitude. The
> time from b to q in your circuit is half a 24MHz clock period. The OR gate
> eats up some of this time. This is much better:-
>
>   process(clk_24M)
>   begin
>     if rising_edge(clk_24M) then
>       a <= d;
>       q <= a;
>     end if;
>   end process;
> The signal 'a' has a whole 24 MHz period to settle. In your UCF file, do
> this:-
>
> NET "a" MAXDELAY = 1ns;
>
> This is just to make sure the router doesn't screw up.
>
> Have you taken Philip's advice and read
> http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm ?
>
> Also, re-read Bob's post. He's explained very well why your circuit isn't
> good, and your latest modification doesn't address the concerns he
> expresses.
>
> HTH, Syms.
>
>



Article: 90297
Subject: Re: Question about metastability that's been on my mind for a while
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Sun, 09 Oct 2005 18:45:34 GMT
Links: << >>  << T >>  << A >>
Raymund - 

Best of luck to you.

For others who want to learn about metastability and avoid the
mistakes and misconceptions of the past, my advice holds; please read:

http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm

Bob Perlman
Cambrian Design Works
----------
"But the fact that some geniuses were laughed at does not imply that
all who are laughed at are geniuses. They laughed at Columbus, they
laughed at Fulton, they laughed at the Wright brothers. But they also
laughed at Bozo the Clown." - Carl Sagan


On Sun, 9 Oct 2005 14:27:18 +0200, "Raymund Hofmann"
<filter002@desinformation.de> wrote:

>
>"Bob Perlman" <bobsrefusebin@hotmail.com> schrieb im Newsbeitrag 
>news:8mufk156urltejl11o21p7oup8arqq8bi2@4ax.com...
>> On Sat, 8 Oct 2005 14:02:36 +0200, "Raymund Hofmann"
>> <filter002@desinformation.de> wrote:
>>
>> <most stuff snipped>
>>
>>>What is the probability distribution of the metastable duration
>>>comparing the normal FF with a schmitt trigger output state feedback 
>>>FF?
>>>I guess the schmitt output stage will be significantly better and even
>>>practically metastable free after 20nS in the lifetime of our Planet.
>>
>> <some innuendos about unfortunate souls snipped>
>>
>
>I was talking about a FF containing a schmitt trigger _in_ it's feedback 
>loops. And I was talking about a 7414 schmitt trigger eventually not 
>suitable for this (and how to get it inside a FF feedback loop), 
>although maybe not detailed enough.
>
>>
>>>This brings another Idea to my mind:
>>>
>>>What about injecting noise in the FF feedback loops which is small
>>>enough not to alter their (static)performance, but large enough to 
>>>drive
>>>the feedback loops (and maybe schmitt triggers) into clipping and thus
>>>their stable state ?
>>
>> This is an idea that has been proposed before.  Unfortunately, it's
>> just as likely that noise will drive you into a metastable state as
>> out of it.
>
>Metastability is not the question, it's "duration probability" is. Every 
>FF has some CK->Q uncertainty(jitter) you could also call "Metastable", 
>even with proper setup/hold.
>
>So I can't second this.
>
>>
>> If you sense some frustration on the part of the old hands in this
>> group, it's because metastable-fix mania sweeps through here on a
>> regular basis, and every time the same "fixes" and "improvements" are
>> trotted out, virtually all of which were disproved ages ago.
>
>I guess you sense some illusion of superiority.
>
>>
>> Please, please, please, everybody, go to:
>>
>> http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
>>
>> and read the whole thing.  Then look at the bibliography at the end
>> and read some more.
>
>I get partial dyslexia reading the whole thing. This is where I also 
>want to expose my Ignorance and explain everything (in my way).
>
>>
>> The subject has been well-researched.  The point is, you don't *have*
>
>
>The ether has also been "well researched" until Albert Einstein.
>You are free to defame me of thinking I am a Genius.
>Can you also think on your own or do you only quote "well researched" 
>subjects ?
>Is there a reason individual life is finite by conception ?
>
>> to guess, at least not if the vendor gives you a little information on
>> their metastable performance.  And if there isn't enough information
>> from the vendor, there are simple ways to trade latency for lower
>> metastable failure rate.
>>
>> Let's move on, folks.  Let the healing begin.
>>
>
>Who's healing do you mean ?
>
>Raymund Hofmann 


Article: 90298
Subject: Bus master DMA and cache coherency
From: "Gordon Friend" <gfriend-nospam@no-spam.bigonefeet.com>
Date: Sun, 9 Oct 2005 23:44:37 +0100
Links: << >>  << T >>  << A >>
Hello,

Hopefully these groups are appropriate for this quesiton, apologies if not.

I've designed a PCI card that does data capture, along with a driver module
for Linux 2.4.
It all seems to work fine, BUT I have one nagging doubt regarding the DMA
performance.

I've implemented a data-aware bus master DMA on the PCI interface FPGA, i.e.
the PCI card is initialised to transfer a v.large amount of data (upto
512Mbytes). When data is available the card initiates the transfer into the
allocated memory location. The memory is then mmap'd into user space, where
the user app/driver can interogate the PCI card to find out how much data
has been transferred, and process it accordingly. So far so good, all seems
to work.

The doubt I have is regarding cache paging.
Scenario - 2300 bytes of data are received by the PCI card and transferred
into the bottom of the memory area. The application/driver detects this
transfer and starts processing the data. This will cause the memory page to
be copied into the processor cache. While the app is processing this data
more (e.g.3400bytes) data arrives in the PCI card and is transferred into
memory. When the application has processed the first block of data, it
interrogates the PCI card and detects the new data. When it goes to process
it, it looks for the data at the end of the first block, BUT and here's the
doubt, is there any reason to believe that the page in cache will have been
invalidated and reloaded when the 2nd block of data was transferred by the
PCI cards DMA action ? Or will the application be looking at the "old" data
that was in the unused part of the page when it was first copied into cache
?

At the moment I've designed round this concern, by modifying the data
handover protocol and ensuring the driver module only hands data over in
4096 byte blocks (Linux 2.4 default page size).

The target platforms are PCs using standard Intel chipsets.

Any hints appreciated.

Many Thanks

Gordon



Article: 90299
Subject: Re: FPGA behaviour when its used resource is >90% ?
From: bijoy <pbijoy@rediffmail.com>
Date: Sun, 9 Oct 2005 20:28:48 -0700
Links: << >>  << T >>  << A >>
Hi Antii

How can i identify the unrelated logic ? what is the meaning of unrelated logic. ?

could you please explain about it ?

regards bijoy



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
2019JanFebMar2019

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