Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
Before we get all worked up, let me clarify: Power-up is an event that occurs long before any bitstream is started. So it is a totally different subject. Feeding a legitimate bitstream, that has passed the standard design-rule check, DRC, and is compiled for this particular device, will never cause any contention or other strange behavior. The problem reported was one of ( obviously unintentional ) feeding a bitstream that was properly created for a different device. If it had been a "bad" bitstream, the CRC would have caught it. I think Virtex-II takes care of such issues, but I let Austin answer that. Peter Alfke eteam wrote: > Peter (and Austin and Phil), > > Here is my take (*please* correct me where I'm mistaken): > > It sounds like there are two weaknesses in (at least) > some of the Xilinx device families that can lead to > catastrophic failures: > > 1. Devices don't check the programming data stream > for a "match" of target device. Thus, you can try to > program a Virtex 600E device with a Virtex 400E > configuration data stream, and the configuration data > will be accepted. > > This "hole" allows the designer to make a mistake, and be > burned by it. The workaround is, simply, to make sure that > your configuration files were compiled for the correct target > device; you screw up at your own peril. > > 2. More ominous is that drivers for internal > multi-source busses are not disabled (tri-stated, if > you will) before and during the configuration and powerup > sequence, when the internal state of the device cannot be > controlled or specified by the designer. I'm not sure there > is *any* workaround to this, short of a re-design of the FPGA die. > > We need to understand the breadth of this problem (if the above > assessments are basically correct): which device families are > affected (afflicted), etc. etc. > > I'm not posting this to cause alarm, but to distill the > issues at hand as clearly as possible, and avoid any FUD. > > Rather than get excited, it would be good for all concerned > to await Xilinx's response which, if history is a guide, will be > an honest and open discussion of the facts, and which will provide > essential guidance to the design community. > > Bob Elkind, eteam@aracnet.comArticle: 29651
Hello there, I am implementing a 100BASE-T4 Network reapter ( case study in " VHDL for Programmable logic by Kevin Skahill) in a Xilinx FPGA. Can anyone recommend me some ways to test my design? Thanks for your help ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email abuse@newsone.netArticle: 29652
I am quire certain that XC4000 and prior devices automatically avoid this problem, since they check for a start bit in specific bitstream locations. If the frame structure is "wrong", then there is a 50% chance of detecting the error after every frame. After a few frames, the probability of detection gets very high. After hundred of frames it is practically 100%. I am glad the Virtex devices survived this jolt. Peter Alfke Joel Kolstad wrote: > Thanks for the explanation, Peter. I'm thinking we'll add something to the > board so that the PC's software will be able to detect what type of FPGA the > board has loaded on it, and not feed it incorrect bitstreams. > > The FPGA itself survived just fine, as far as I can tell. :-) > > ---JoelArticle: 29653
"S. Ramirez" wrote: >> It is true that you need two flip flops. The first one is to > synchronize the asynchronous signal to the using clock domain. The second > one is to reject the metastability of the first flip flop. If you are > testing an asynchronous signal (note I said signal, not signals) that is > feeding a state machine, then the state machine flip flops will serve as the > "2nd flip flop,", i.e., they are the metastability rejectors. If you use > two fllip flops prior to the state machine, then the 2nd flip flop is the > metastability rejector, and you will incur an additional cycle of delay. Simon failed to point out that using the state machine as the second flip flop should only be done if the possibly metastable signal affects only one flip-flop in the state machine. If if affects more than one flip-flop, there is a potential for a metastable event to be detected as different levels by the multiple flip-flops that depend on its condition. Simon, I'm sure this was your intention, I just wanted to make sure your short response didn't mislead anyone. -- -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.comArticle: 29654
Ray Andraka <ray@andraka.com> writes: [Simons wisdom deleted] > Simon failed to point out that using the state machine as the second > flip flop should only be done if the possibly metastable signal > affects only one flip-flop in the state machine. If if affects more > than one flip-flop, there is a potential for a metastable event to > be detected as different levels by the multiple flip-flops that > depend on its condition. Simon, I'm sure this was your intention, I > just wanted to make sure your short response didn't mislead anyone. Really? Hmm, the idea is that FF1 would settle within the cycle time. Now, if it doesn't, does it really matter if one or several of the statemachines FFs wil go into metastability? The idea is that the cycle time will be enough for all metastability to vanish. If it hasn't, is there anything you can do to save your FSM from running amok? Your advice might be god, but probably mostly due to the fact that having only one FF after FF1 usaully reduces the routing delay, and hence increases the available settling time (iff you have the same cycle time in both cases). Comments invited. Homann -- Magnus HomannArticle: 29655
Peter Alfke <palfke@earthlink.net> writes: > The gist is: > Virtex parts do check for CRC errors, but not for formatting errors. And you > sent a legitimately CRC-protected file, just the wrong format... Horrendous > amount of internal contention. [...] > Correct. If there were a CRC error, the part would recognize this. But there > was no CRC error... Is there some reason why the part doesn't ALSO recognize that the bitstream is too short? I wouldn't think it would expect the CRC until it had filled all of the RAM cells. This suggests that in addition to length checking, you guys might want to design a part id number into future parts, and have it fail to configure if the part id in the bitstream doesn't match the part id of the part.Article: 29656
On 04 Mar 2001 00:25:08 +0100, Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: >Ray Andraka <ray@andraka.com> writes: > >[Simons wisdom deleted] > >> Simon failed to point out that using the state machine as the second >> flip flop should only be done if the possibly metastable signal >> affects only one flip-flop in the state machine. If if affects more >> than one flip-flop, there is a potential for a metastable event to >> be detected as different levels by the multiple flip-flops that >> depend on its condition. Simon, I'm sure this was your intention, I >> just wanted to make sure your short response didn't mislead anyone. > >Really? Hmm, the idea is that FF1 would settle within the cycle >time. Now, if it doesn't, does it really matter if one or several of >the statemachines FFs wil go into metastability? > >The idea is that the cycle time will be enough for all metastability >to vanish. If it hasn't, is there anything you can do to save your FSM >from running amok? > >Your advice might be god, but probably mostly due to the fact that having >only one FF after FF1 usaully reduces the routing delay, and >hence increases the available settling time (iff you have the same >cycle time in both cases). > >Comments invited. > >Homann I think that "two FFs" was just a rule of thumb which ensured a certain MTBF under certain conditions (which are probably not valid in < .25u processes anymore). You can further reduce the probability of metastability by adding more FFs. The metastability never vanishes completely. There is always a non-zero probability that the metastable event will pass through all the FFs. It can be made arbitrarily small though. That's where the MTBF comes from. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29657
"Mark" <mark@plumjob.net> wrote on Thu, 22 Feb 2001: > Does anybody have any information on the expected availability of the Virtex > II family, especially the 6000 part? Avnet-Marshall currently lists five Virtex II parts including the 6000: part number availability lead time q. 1-24 q. 25-99 ------------------- ------------ --------- -------- -------- XC2V40-4FG256CES no stock no info $40.15 $36.36 XC2V1000-4FG256CES no stock 4 weeks $279.40 $254.10 XC2V1000-4FG456CES no stock no info $308.00 $279.40 XC2V1000-4FF896CES no stock no info $420.20 $380.60 XC2V6000-4FF1152CES no stock 4 weeks $4573.80 $4145.90 They don't list the XC2V8000 and XC2V10000 yet, nor any other sizes.Article: 29658
> "S. Ramirez" wrote:
> >> It is true that you need two flip flops. The first one is to
> > synchronize the asynchronous signal to the using clock domain. The
second
> > one is to reject the metastability of the first flip flop. If you are
> > testing an asynchronous signal (note I said signal, not signals) that is
> > feeding a state machine, then the state machine flip flops will serve as
the
> > "2nd flip flop,", i.e., they are the metastability rejectors. If you
use
> > two fllip flops prior to the state machine, then the 2nd flip flop is
the
> > metastability rejector, and you will incur an additional cycle of delay.
> "Ray Andraka" wrote::
> Simon failed to point out that using the state machine as the second flip
flop
> should only be done if the possibly metastable signal affects only one
flip-flop
> in the state machine. If if affects more than one flip-flop, there is a
> potential
> for a metastable event to be detected as different levels by the multiple
> flip-flops
> that depend on its condition. Simon, I'm sure this was your intention, I
just
> wanted
> to make sure your short response didn't mislead anyone.
Ray,
Sorry for not responding to you sooner. I see that some others have
responded. I was out in my garage doing a fiberglass layup, and once I
start it, I cannot walk away until it is finished!
I'm not sure if we are talking about the same thing, so let me
elaborate.
The first flip flop, FF1, I am sure that everyone agrees it will meta
when used as a synchronizing flip flop. There is a certain probability, p1,
for a particular FF1 to meta if the input signal changes within the
setup/hold time violation window. There is another probability, p2, of the
time that FF1 spends in meta. As that time increases, p2 decreases. These
two probabilities multiply and give the final probability in a simplisitic
form. If meta exists when FF2 samples FF1's output, then it will also have
a probability of meta. Usually the clock cycle time of the two flip flops
is much greater than the time for p2 to be significant, because this cycle
time is usually dealing with prop delays that affect register to register
performance. But as well know, a long cycle time does not guarantee that
FF2 will not see meta.
I claim that one can make the state machine flip flops the FF2s. As
long as they don't see meta at their setup-hold time window, they will
perform as intended. With the probability of meta being in the range of
years, decades, centuries, this is accepted as practice. If one inserts FF2
between FF1 and the state machine flip flops, then FF2 becomes subject to
that meta. It will in turn meta in a hundred years and introduce its own
small probability (p1*p2) of affecting the state machine's flip flops. In
other words, inserting FF2 only decreases the probability of causing a
problem at the state machine, because the probabilities multiply
(p1*p2*p1*p2). But I claim that multiple flip flops in a state machine can
serve as FF2s and work correctly as long as one knows that they will meta
some time in the distant future (p1*p2). Introducing FF2 between FF1 and
the state machine has the disadvantage of adding another cycle of delay
along with decreasing the probability of the flip flops acting as flop
flops.
Usually in a state machine, there are multiple flip flops that will get
affected by this low probability of meta. There are different ways of
designing state machines, but I really don't know how to design a state
machine where only one flip flop will be affected, or at least I don't
design state machines that way. I usually use one-hot encoding, but this
doesn't guarantee that only one flip flop will be affected. Along with the
state encoding bits, there are state output bits that are a function of the
present state and the inputs, meta included. My state output bits are not
the state encoding bits, so there are multiple flip flops there seeing the
low probability of meta.
I have seen others use FF1 and FF2, but I always questioned why they
used it. We never really came into an agreement that either I was wrong or
they were wrong. If I am wrong, then I am capable of learning things. But
my theories come from two major defense contractors that did some work in
this area and standardized their design methodologies using the state
machine flip flops as FF2s. Their design handbook included what I said
above as well as other procedures. An example of one of these procedures
is if one is building a nuclear device that is controlled by an electronic
circuit, then everything needs to be synchronous, with the exception of a
very few and heavily studied signals. On the other hand, if you are Saddam
Hussein working on an asynchronous nuclear device and the U.N. inspectors
are scheduled to see you in a week, and you don't have time to convert it to
a synchronous design, then you take your chances, run BIST and test it now!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 29659Eric Smith wrote: > This suggests that in addition to length checking, you guys might want > to design a part id number into future parts, and have it fail to > configure if the part id in the bitstream doesn't match the part id of > the part. Done, in the new family Virtex-II. Peter AlfkeArticle: 29660
If your're interfacing to a serial port on the Palm Pilot, then that's very obviously going to be your limiting factor. I don't think a Dragonball could sustain 115kbit/s of even if the built in uart supports that baud rate. PIO mode should do. Now if you were going to a Visor, you'd be better off with an FPGA- it has a Compact Flash slot - with parallel bus signals - so a simple decoding and latch arrangement would work- a PLD could even be enough Any simple microcontroller should be able to handle this- even bit bashing a software uart. Take a look at a system from MVS (<$100$US) -I think they're using a Scenix PIC clone. I know this isn't an FPGA solution, but there are many ways to skin a cat - some a lot easier and cheaper than others... unless you're just after the FPGA learning exercise. http://www.star.net/people/~mvs/SDRVSPEC.TXT Regards, Heinz Wolter "Bard_64" <Bard_64@ntlworld.com> wrote in message news:3A9C0C45.3A3D8431@ntlworld.com... > > > > Hello Everyone. > > I am currently doing backgroud reading on a project > involving the > interfacing of a Hard disk to a Palm Pilot. > > I was wondering could it be possible to access the IDE > interface > using an FPGA (specifically the X4003). > > Thanks > > Daniel >Article: 29661
I'm trying to use WebPACK ISE to build a microprocessor core model
using an XC2S200. I can't get the data path to compile; the synthesizer
exits with the message:
Done: failed with exit code: 0002.
I don't think I'm doing anything too strange. I did have to change it
somewhat from the design I was using with the Cypress tools, because
I used ieee.numeric_std with those.
I stripped down the data path until all that is left is the adder,
and I still get the error. While it's entirely possible that I've
screwed something up and this may not be a legal VHDL file, I'm
astonished that the synthesizer would exit with a non-zero exit code
without actually telling me what it is upset about.
Here's the code:
library ieee;
use ieee.std_logic_1164.all;
entity adder is
port (
carry_in : in std_logic;
a, b: in std_logic_vector (7 downto 0);
result: out std_logic_vector (7 downto 0);
carry_out_4: out std_logic; -- digit carry
carry_out_8: out std_logic; -- the "real" carry out
overflow: out std_logic -- two's complement overflow
);
end adder;
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
architecture arch_adder of adder is
signal sum_low : std_logic_vector (4 downto 0);
signal sum_high : std_logic_vector (9 downto 4);
begin
sum_low <= (('0' & a (3 downto 0)) + ('0' & b (3 downto 0))) + carry_in;
sum_high <= (('0' & (a (7) & a (7 downto 4))) +
('0' & (b (7) & b (6 downto 4)))) + sum_low (4);
result <= sum_high (7 downto 4) & sum_low (3 downto 0);
carry_out_4 <= sum_low (4);
carry_out_8 <= sum_high (9);
overflow <= sum_high (8) xor sum_high (7);
end architecture arch_adder;
The .plg file is below. Anyone have any ideas as to what's going wrong?
Can anyone else reproduce the problem?
I'm using Design Entry 3.2WP3.1, Spartan 2 fitter 3.2WP3.2, and JTAG
programmer 3.2WP3.1. I've successfully compiled the ledflash example
that Burch Electronic Designs provides as a demo of their BED-SPARTAN2+
board, so I think WebPACK is installed correctly.
Thanks!
Eric
=========================================================================
---- Global Settings
Tmp directory : .
DUMPDIR : .
overwrite : YES
=========================================================================
XST D.22
Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved.
--> Parameter TMPDIR set to .
--> Parameter DUMPDIR set to .
--> Parameter overwrite set to YES
--> =========================================================================
---- Source Parameters
Input File Name : adder.prj
Input Format : VHDL
---- Target Parameters
Output File Name : adder.edn
Output Format : EDIF
---- Source Options
Entity Name : adder
Automatic FSM Extraction : YES
FSM Encoding Algorithm : Auto
HDL Verbose Level : 1
RAM Extraction : Yes
RAM Style : Auto
Mux Extraction : YES
Mux Style : Auto
Decoder Extraction : YES
Priority Encoder Extraction : YES
Shift Register Extraction : YES
Logical Shifter Extraction : YES
XOR Collapsing : YES
Resource Sharing : YES
Complex Clock Enable Extraction : YES
Resolution Style : WIRE_MS
---- FSM Options
FSM Flip-Flop Type : D
---- Target Options
Family : Xilinx_Virtex
Device : 2S200-PQ208-5
Macro Generator : Macro+
Add IO Buffers : YES
Add Generic Clock Buffer(BUFG) : 4
Global Maximum Fanout : 100
Keep Hierarchy : NO
---- General Options
Optimization Criterion : Speed
Optimization Effort : 1
Global Optimization : AllClockNets
Incremental Synthesis : NO
=========================================================================
Compiling vhdl file C:\Xilinx_WebPACK\data\webpack\genff.vhd in Library genff.
Entity <g_depc> (Architecture <behavioral>) compiled.
Entity <g_tpc> (Architecture <behavioral>) compiled.
Entity <g_latpc> (Architecture <behavioral>) compiled.
Compiling vhdl file E:\xproj\adder\adder.vhd in Library work.
Compiling vhdl file E:\xproj\adder\adder_arch.vhd in Library work.
Entity <adder> (Architecture <arch_adder>) compiled.
Analyzing Entity <adder> (Architecture <arch_adder>).
Entity <adder> analyzed. Unit <adder> generated.
Synthesizing Unit <adder>.
Extracting 4-bit adder carry in/out for signal <sum_low<3:0>>.
Extracting 5-bit adder carry in/out for signal <sum_high<4:0>>.
Extracting 1-bit xor2 for signal <overflow>.
Article: 29662
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhlmqm7x4c.fsf@ruckus.brouhaha.com...
> I'm trying to use WebPACK ISE to build a microprocessor core model
> using an XC2S200. I can't get the data path to compile; the synthesizer
> exits with the message:
>
> Done: failed with exit code: 0002.
>
> I don't think I'm doing anything too strange. I did have to change it
> somewhat from the design I was using with the Cypress tools, because
> I used ieee.numeric_std with those.
>
> I stripped down the data path until all that is left is the adder,
> and I still get the error. While it's entirely possible that I've
> screwed something up and this may not be a legal VHDL file, I'm
> astonished that the synthesizer would exit with a non-zero exit code
> without actually telling me what it is upset about.
> Thanks!
> Eric
Eric,
Since you were brilliant enough to include the code and make it easy, I
copied the code into a file and ran it through Synplify 6.1.3/Design Manager
3.3.06i.
I targeted a Spartan 2 chip, and everything ran fine. In other words,
the Synplify tool did not detect any errors and pumped out an EDIF file
correctly. I would immediately start suspecting the XST tools, which are
fairly new and I suspect "bug-not-free." If you want, you can email me your
entire code, and I will run it through the Synplify tool and ship you back
an EDIF file. What the heck. It's 5:51am, Sunday morning, and I have
nothing to do but wait for the newspaper to arrive! No, actually,
synthesizing a file that is already written and debugged should be trivial.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
sramirez@cfl.rr.com
Article: 29663"S. Ramirez" wrote: > > I will run it through the Synplify tool and ship you back > an EDIF file. What the heck. It's 5:51am, Sunday morning, > and I have nothing to do but wait for the newspaper to arrive! Man! Sunday morning @ 5:51am === sleep time for me! ATB, Simon. -- Freedom ? What's that ? (see http://www.domesday.co.uk/ )Article: 29664
"Embedded Head" <chilln@gte.net> wrote in message
news:OKco6.3179$sC4.237266@paloalto-snr1.gtei.net...
> Mixed Signal Engineer
> Will work as a member of our Test Engineering team to design, test and
> troubleshoot our next generation of test equipment. We are a rapidly
> expanding, progressive company with excellent benefits and friendly
> atmosphere.
> Qualifications
> BSEE (required)
> 2+ years experience in C/C++ and VHDL or FPGA (required)
> 2+ years experience with analog hardware (required)
> Schematic design software experience (required)
> DSP experience preferred
> Send or Fax resume to:
> "Mixed Signal Engineer Web"
> 3629 Vista Mercado
> Camarillo, CA 93012
> FAX: (805) 383-1838
> EMAIL: humanresources@a-m-c.com
Your BULLET_P.gif is quite enlightening.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 29665Were you able to convert your old bitmaps to the current generation of software? I find that the process is not well supported and, in fact, as evidenced by the replies you got, not well understood. I'd be quite interested in how you solved your problem. regards, Dick On Fri, 2 Feb 2001 16:01:43 -0000, "Alan Horton" <arh@jet.uk> wrote: >I have been given the task of resurrecting the Xilinx software used at my >place of work. A few years ago we were quite active in designing various >bespoke electronic modules but the majority of our desingers have since >left. Our existing "out of date" set-up uses two types of design entry >methods: ABEL Version 5.12 and Orcad ESP V4.40 and the designs are >implemented using Xilinx XACT Version 5.1.0. > >As I understand it there are three available families of software: >Alliance, Foundation ISE and Foundation. > >I need to find out whether any or all of these families will be able to >support our old existing designs. I assume they probably do but can anyone >confirm this or point me to where I can find out this information. > >Regards >Alan > > >Article: 29666
AFAIK, Muzaffer Kal is right. The latest T13 document he references clarify the data rates / throughput http://www.t13.org/project/d1410r1a.pdf Look page numbered 400 (414 in acrobat reader) third paragraph, and you'll find the exact transfert speed for all modes. If you made a UDMA interface that runs a 16.67 Mhz, thus transferring 16.67 * 2[transfers per clock] * 2[bytes per transfert], then it's UDMA mode 4 (AKA UDMA66) and not UDMA33. If you plan to build a UDMA controller with a 33 Mhz clock, you're ahead of times and already building a UDMA133 interface. IOW, you will simply overclock your drive, and, as usual, that's pretty sure to work in the lab / fail in the field. The fastest established standard, UDMA100, uses a 25 Mhz clock to attain 25*2*2=100 MBytes per second. Double check the timing in table 57 ( page numbered 361 (375 in acrobat reader)) "T2cyctyp" for UDMA mode 2 (AKA UDMA33) is 120 ns (8.33 Mhz) . "T2cyctyp" for UDMA mode 4 is 60 ns (16.67 Mhz) while Tcyc applies to either half clock period and is specified to allow for unequal High / Low clock times. Tcyc is *not* the clock cycle time. Hope this helps. Eric. ------------------------------------- Rick Filipkiewicz wrote: > Muzaffer Kal wrote: > > > On Fri, 02 Mar 2001 00:36:06 +0000, Rick Filipkiewicz > > <rick@algor.co.uk> wrote: > > > > >yuryws@banet.net wrote: > > > > > >> Side note: > > >> uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) > > >> not 133 MB/sec. > > >> > > >> -- Yury > > >> > > >> R > > > > > >UDMA66 = 33MHz clock. 16 bits on each edge = 4 bytes every 30nsec = > > >133MBytes/sec. > > > > I believe you're mistaken. UDMA66 (UDMA Mode 4) is 33 M transitions/s > > not 33 MHz; IOW, it has a 16.67 MHz clock and transmits data at both > > edges so it has a 66.67 MB/s transfer rate. > > > > Muzaffer > > > > FPGA DSP Consulting > > http://www.dspia.com > > I've *built* a UDMA33 interface and that clock runs at 16.66 ergo the UDMA66 > interface I'm about to build will have a 33.33MHz clock. Note that the clock > frequency is really the read clock sent by the disk on IORDY. The write clock is > under my own control.Article: 29667
One flip flop is enough as long as it gets your metastability recovery down to a reasonable value for your system. Remember also that the propagation time from your synchronizing flip-flop to your next flip-flop(s) detracts from the available metastability recovery time. If you have a state machine which has more than one flip-flop affected by your synchronized input, the routing delays can easily become substantial, especially if not floorplanned. That first flip-flop is virtually guaranteed to go metastable, as its input is async to the system. If you have a slow clock, you probably have enough time for most metastable events to settle. If on the other hand, you are running the clock fast, you can significantly improve your metastable resistance using two FF's and floorplanning them to use the fastest interconnect available. "S. Ramirez" wrote: > > > "S. Ramirez" wrote: > > >> It is true that you need two flip flops. The first one is to > > > synchronize the asynchronous signal to the using clock domain. The > second > > > one is to reject the metastability of the first flip flop. If you are > > > testing an asynchronous signal (note I said signal, not signals) that is > > > feeding a state machine, then the state machine flip flops will serve as > the > > > "2nd flip flop,", i.e., they are the metastability rejectors. If you > use > > > two fllip flops prior to the state machine, then the 2nd flip flop is > the > > > metastability rejector, and you will incur an additional cycle of delay. > > > "Ray Andraka" wrote:: > > Simon failed to point out that using the state machine as the second flip > flop > > should only be done if the possibly metastable signal affects only one > flip-flop > > in the state machine. If if affects more than one flip-flop, there is a > > potential > > for a metastable event to be detected as different levels by the multiple > > flip-flops > > that depend on its condition. Simon, I'm sure this was your intention, I > just > > wanted > > to make sure your short response didn't mislead anyone. > > Ray, > Sorry for not responding to you sooner. I see that some others have > responded. I was out in my garage doing a fiberglass layup, and once I > start it, I cannot walk away until it is finished! > I'm not sure if we are talking about the same thing, so let me > elaborate. > The first flip flop, FF1, I am sure that everyone agrees it will meta > when used as a synchronizing flip flop. There is a certain probability, p1, > for a particular FF1 to meta if the input signal changes within the > setup/hold time violation window. There is another probability, p2, of the > time that FF1 spends in meta. As that time increases, p2 decreases. These > two probabilities multiply and give the final probability in a simplisitic > form. If meta exists when FF2 samples FF1's output, then it will also have > a probability of meta. Usually the clock cycle time of the two flip flops > is much greater than the time for p2 to be significant, because this cycle > time is usually dealing with prop delays that affect register to register > performance. But as well know, a long cycle time does not guarantee that > FF2 will not see meta. > I claim that one can make the state machine flip flops the FF2s. As > long as they don't see meta at their setup-hold time window, they will > perform as intended. With the probability of meta being in the range of > years, decades, centuries, this is accepted as practice. If one inserts FF2 > between FF1 and the state machine flip flops, then FF2 becomes subject to > that meta. It will in turn meta in a hundred years and introduce its own > small probability (p1*p2) of affecting the state machine's flip flops. In > other words, inserting FF2 only decreases the probability of causing a > problem at the state machine, because the probabilities multiply > (p1*p2*p1*p2). But I claim that multiple flip flops in a state machine can > serve as FF2s and work correctly as long as one knows that they will meta > some time in the distant future (p1*p2). Introducing FF2 between FF1 and > the state machine has the disadvantage of adding another cycle of delay > along with decreasing the probability of the flip flops acting as flop > flops. > Usually in a state machine, there are multiple flip flops that will get > affected by this low probability of meta. There are different ways of > designing state machines, but I really don't know how to design a state > machine where only one flip flop will be affected, or at least I don't > design state machines that way. I usually use one-hot encoding, but this > doesn't guarantee that only one flip flop will be affected. Along with the > state encoding bits, there are state output bits that are a function of the > present state and the inputs, meta included. My state output bits are not > the state encoding bits, so there are multiple flip flops there seeing the > low probability of meta. > I have seen others use FF1 and FF2, but I always questioned why they > used it. We never really came into an agreement that either I was wrong or > they were wrong. If I am wrong, then I am capable of learning things. But > my theories come from two major defense contractors that did some work in > this area and standardized their design methodologies using the state > machine flip flops as FF2s. Their design handbook included what I said > above as well as other procedures. An example of one of these procedures > is if one is building a nuclear device that is controlled by an electronic > circuit, then everything needs to be synchronous, with the exception of a > very few and heavily studied signals. On the other hand, if you are Saddam > Hussein working on an asynchronous nuclear device and the U.N. inspectors > are scheduled to see you in a week, and you don't have time to convert it to > a synchronous design, then you take your chances, run BIST and test it now! > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA -- -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.comArticle: 29668
Kevin, Xilinx does not support Ambit. Cadence acquired Ambit a few years back. The required library files for a Xilinx flow through Ambit are supplied by Cadence and you must contact Cadence technical support for Xilinx/Ambit flow. Cadence technical support's contact info is email : support@cadence.com Ph. no: 1(877)CDS-4911 or 1(877)237-4911 Hope this helps. -Vikram Xilinx Applications Kelvin CHEUNG/ÕżÒΰ/±i®a°¶ wrote: > Hi, > > FPGA synthesis can be transparent to Ambit when the library contain sufficent information (loading, drive, timing model and so on). The netlist can be converted to EDIF and then Alliance should be > able to P&R it. It can be done thru design compiler since .db file is provided. (Not only FPGA compiler but also dc.) Yet we cannot do it with Ambit with an Ambit library. > > Muzaffer Kal wrote: > > > Ambit is strictly an ASIC synthesis tool. I don't believe it supports > > any FPGA devices. You're much better off with Synplicity tools for > > Virtex anyway. > > > > Muzaffer > > > > FPGA DSP Consulting > > http://www.dspia.comArticle: 29669
I'm an FAE for a distributor of Actel. As Philip stated the devices are OTP. There are no inherent problems with the SX/SXA families but if you want to be successful on the first pass (this applies to any vendor/technology) budget time for proper simulation. Tim "jean-francois hasson" <jfhasson@club-internet.fr> wrote in message news:951h9l$9aa$1@front1.grolier.fr... > Hi, > > I am about to use an Actel A54SX32A in a FBGA144I package. I am interested > in people having an experience with Actel's FPGAs and the best would be with > the SX family. I have used up to know either Altera or Xilinx and I have no > experience with Actel. Are there any known problems with these devices ? > Anything specific to look at before starting a design ? > Thank you in advance for your time and information. > > J.F. Hasson > >Article: 29670
use BIBUF "I. Purnhagen" <Purnhagen@ohb-system.de> wrote in message news:94mfgc$2eo6$1@wrath.news.nacamar.de... > Hello Newsgroup! > > How can I implement a real bidirectional route-through wire (no direction > pin, e.g. a databus) in an Actel 54SX? > Is it allowed to interconnect an INBUF and OUTBUF as work-around? > > Greetings, Ingo Purnhagen > > _______________________________ > > Ingo Purnhagen (Dipl.-Ing.) > OHB-System GmbH > Abt. Hardware > Universitaetsallee 27-29 > 28359 Bremen, Germany > Fon: +49 421 2020 702 > Fax: +49 421 2020 610 > mailto:XXXpurnhagen@ohb-system.de > http://www.ohb-system.de > > XXX to be removed > > >Article: 29671
S. Ramirez wrote: <snip> > The first flip flop, FF1, I am sure that everyone agrees it will meta > when used as a synchronizing flip flop. Yes. > There is a certain probability, p1, > for a particular FF1 to meta if the input signal changes within the > setup/hold time violation window. There is another probability, p2, of the > time that FF1 spends in meta. As that time increases, p2 decreases. These > two probabilities multiply and give the final probability in a simplisitic > form. I'm not sure you can multiply them that simply. Metastable is quasi-analog in nature, it's a regenerative feedback system being balanced precisely on release. To trigger the SAME effect in FF2, your metastable Tpd time must be exactly matched to cause the same precise-balance point on the FF2. A Tpd of > clock is actually OK, so all Tpd's above this time are not included. So, the stats factor a little differently with two sync FF's, vs one driving a State engine with multiple paths. Due to noise effects, is there not a 'zero' probability point - where the device must have settled. (Opposite effect: Most XTAL oscillators will not start without some noise ) Some questions for Peter A. - When a modern FF goes metastable, does it have the slow edge / multiple edge 'nasties' seen in the 'classic' TTL plots of metastable registers ? - has anyone at Xilinx done test / simulations on finite noise and its effect on metastable times. - Most Metastable specs I have seen are focused on settling times, has any work been done on defining the time window-width, on the INPUT side ? -jgArticle: 29672
My detailed answers are below. But first I want to agree with Jim, that there is a difference between the time delay until the flip-flop has stabilized, and the exact moment when it makes a change. The second flip-flop will only go metastable if the first flip-flop's delay plus routing exactly ( down to the picosecond !) hits the second flip-flops funny-bone metastability point. Otherwise the second flip-flop will reflect the right or wrong info coming from the first. In other words: You might transfer wrong data, but it is borderline impossible to transfer the act of going metastable. Jim Granville wrote: > Due to noise effects, is there not a 'zero' probability point - where > the device must have settled. > (Opposite effect: Most XTAL oscillators will not start without some > noise ) I chicken out on that question. > > > Some questions for Peter A. > - When a modern FF goes metastable, does it have the slow edge / > multiple edge > 'nasties' seen in the 'classic' TTL plots of metastable registers ? I have never seen that on CMOS flip-flops ( but I have seen it in TTL ). My somewhat flaky theory is that the feedback path in CMOS flip-flops is so simple, a single stage feeding back to another single stage, through pass transistors, that it does not have the capability to oscillate. Think of phase angle per octave of gain loss, and related things they taught you in school about oscillators. > > > - has anyone at Xilinx done test / simulations on finite noise and its > effect > on metastable times. No, we just measured under room-temperature condition, and next time (soon) we will measure also hot and cold. > > > - Most Metastable specs I have seen are focused on settling times, has > any > work been done on defining the time window-width, on the INPUT side ? Well, they are related. I look at it this way: If you hit the "funny-bone" bull's eye precisely, the delay will be very long ( theoretically, without noise, infinite) If you hit it the slightest moment earlier or later, the delay will be significant shorter. When I measured it with random input times ( incoherent clock and data ) I counted the times metastability exceeded a certain value. I think you can calculate the width of the input window from that. It is extremely narrow. Perhaps even femtoseconds. let me know once you figured it out. I'm in a hurry right know. Peter AlfkeArticle: 29673
"S. Ramirez" <sramirez@deletethis.cfl.rr.com> writes:
> Since you were brilliant enough to include the code and make it easy, I
> copied the code into a file and ran it through Synplify 6.1.3/Design Manager
> 3.3.06i.
> I targeted a Spartan 2 chip, and everything ran fine. In other words,
> the Synplify tool did not detect any errors and pumped out an EDIF file
> correctly.
Thanks for verifying that my code is OK. Or at least OK enough to please
other synthesizers.
> I would immediately start suspecting the XST tools, which are
> fairly new and I suspect "bug-not-free."
I suspected that to be the case. I've tried a few ways to restructure
the code, and so far I have not been able to figure out specifically
what about my code is making XST unhappy.
Maybe someone from Xilinx will try it. I suppose I should figure out how
to submit a bug report.
> If you want, you can email me your
> entire code, and I will run it through the Synplify tool and ship you back
> an EDIF file.
Thanks for the kind offer, but I don't think it would make much sense
to do that just yet. I'm still developing the uP core. I was originally
targetting a Cypress CY37512 CPLD, but I ran out of routing resources.
This forced me to split my design explicitly into control and data path
sections, which I think is architecturally better anyhow. After the split
I was targetting the pieces to a CY37256 and a CY37512. It looks like it
will fit.
However, the Spartan II parts look more cost effective. Originally I
avoided them because:
1) The Xilinx software was too expensive, I am doing this as
self-education and didn't have any budget for expensive tools.
Xilinx fixed this with the introduction of the WebPACK ISE.
2) The Spartan II parts availability was poor. This is improving,
but for me the big break was finding out about the cheap (US $120)
XC2S200 eval board from www.burched.com.
It looks like my design should run much faster in the XC2S200-5 than
in the Cypress CPLDs, because in the latter I had five levels of
feedback in the data path.
Once my model is complete and at verified, I'll make it publicly
available.
Best regards,
Eric
Article: 29674
"Ray Andraka" <ray@andraka.com> wrote in message
news:3AA296D7.6F7EB8AC@andraka.com...
> One flip flop is enough as long as it gets your metastability recovery
down to a
> reasonable value for your system. Remember also that the propagation time
from
> your synchronizing flip-flop to your next flip-flop(s) detracts from the
> available metastability recovery time. If you have a state machine which
has
> more than one flip-flop affected by your synchronized input, the routing
delays
> can easily become substantial, especially if not floorplanned. That first
> flip-flop is virtually guaranteed to go metastable, as its input is async
to the
> system. If you have a slow clock, you probably have enough time for most
> metastable events to settle. If on the other hand, you are running the
clock
> fast, you can significantly improve your metastable resistance using two
FF's
> and floorplanning them to use the fastest interconnect available.
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
I agree, Ray, that the prop delay as well as the meta time add to form
a total time that determines "registered performance," as the Altera people
like to call it. The meta time will be a probabilistic value whose
probability approaches zero as it increases.
I think I have heard Peter Alfke say that the meta times of most FFs in
a Xilinx device are way down there in the hundred picosecond range. If this
is true, then it becomes a small fraction of the total clock to clock time.
Nonetheless, it must be accounted for somehow.
As everyone knows, the first FF will sometimes meta due to the
asynchronous input, but the rest of the FFs will not see the meta except in
a probabilistic determination, which is quite small. It is harder to
floorplan multiple flip flops being fed by FF1 vs. one flip flop (FF2) being
fed by FF1, and this is a good argument to use FF2 if you are worried about
meta and cannot account for it. However, if I don't floorplan and I feed
multiple FFs with FF1's output, I can specify a timing constraint to get a
faster registered performance and thus plan for additional time to
accommodate the meta time.
As Jim Granville mentioned, p3*p4 is more complicated than the p1*p2,
but it is good enough for most applications. Besides, we more or less lack
real substantial data when it comes to meta propbability functions. All I
know is that it is *almost" insignificant compared to the clock to clock
delays in a typical FPGA design, especially if you fudge. Perhaps Peter A.
can enlighten us on this one. I seem to remember a post by him recently (<
two months) saying that he couldn't measure this time because he didn't have
enough resolution in his clock scheme, and he needed the resolution because
the meta time was so small. He did mention, I believe, that the Virtex II
has a DCM which may allow him to do this.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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