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
Is it possible to put a mux in front of the BRAM port for the
coprocessor so that I can have X amount of coprocessors, each with
single cycle access to that BRAM? If so, is there a simple way to
implement that? Im really new to the EDK and Microblaze, and am not
really sure how to go about implementing this even if it were possible.
Again, thanks for your help!
Scott
Article: 92201
Hi Adrian,
You wrote:
>addrgen : process (clk_i, reset) -- , read_A)
>begin
> if (reset='1') then
> zeile <= "0000000";
> spalte <= "00";
> elsif (clk_i'event and clk_i='1') then
> for i in 0 to 3 loop
> spalte <= spalte + 1;
> for j in 0 to 127 loop
> zeile <= zeile + 1;
> -- wait for core to read input
> update_input <= '1';
> while (read_A = '0') loop
> null; -- read_A is low until core has captured data
> end loop;
> update_input <= '0';
> end loop;
> reset_trig <= '1';
> reset_trig <= '0';
> end loop;
> end if;
>end process addrgen;
There is a lot wrong here, and I can't teach you all about H/W design
vs. S/W coding, but will try to touch on some key points. I had a look
at your website, and see that you have experience with Ada. Do not be
fooled by any outward similarities between Ada and VHDL. There are many
differences, some obvious and some very subtle. There is a lot more
going on 'behind the curtain' in VHDL. Code written in Ada is has a
single primary destination; it is compiled into an object file containg
bits that control a processor's execution. Code written in VHDL has two
primary destinations; it is compiled by a simulator to produce bits
(dependency tables, signal lists, and a whole lot more) to control a
simulator's exection, and it is compiled by a synthesizer to produce a
netlist that is eventually transformed into bits to control the FPGA
configuration.
Code written for a processor vs. VHDL code:
On a processor, statements execute sequentially, and some kind of
timing is almost always imposed on their execution by the processor's
clock.
In VHDL, all statements outside of a process execute concurrently, with
_no_ timing. Statements inside a process execute sequentially, but
there is still _no_ timing, everything 'happens in an instant', with
the exception of 'wait' statements, which cause suspension of process
statement execution until the wait condition is satisfied. BUT 'wait'
statements are absolutely verboten in synthesizable VHDL. (Wait
statements are used in testbench code, and others can tell you all
about the importance of testbenches, and the differences between them
and synthesizable code)
In a program running on a processor, you can write as part of a
function or procedure:
reset_trig <= '1';
reset_trig <= '0';
and when that function/procedure is called, reset_trig will go to 1 for
some number of processor clock ticks, and then go to 0.
In a VHDL process, even though the statements execute sequentially,
there is nothing to give any duration to the 1 value. If it were to be
synthesized, this might generate a Dirac delta function, or maybe a
glitch, but the first is a theoretical construct, and the second is
really nasty, so this does not produce anything usable.
'For' and 'while' loops:
For loops are typically used to iterate over vector indices, where the
iterator is used for selection purposes. Abreviating your code,
you've written:
addrgen : process (clk_i, reset)
begin
if (reset='1') then
...
elsif (clk_i'event and clk_i='1') then
for i in 0 to 3 loop
spalte <= spalte + 1;
...
end loop;
end if;
end process addrgen;
The iterator 'i' is not even used inside the loop, which should be a
tip-off that something is not right.
Think about what this might do, even if it were a valid piece of code:
Every time a clock edge occurs, "in an instant" the 'for' loop is
executed, and when the process exits, the value of spalte has been
incremented 4 times. This would mean that every clock edge would
increment spalte by 4. HOWEVER, this is NOT valid code, and both
simulation and synthesis produce a counter that increments by 1 on each
clock edge. (Should the tools not even allow this to compile? I don't
know, but mine do)
All the problems here stem from a common source, thinking that a H/W
process is like a S/W procedure or function, but it is not. Concentrate
on the basic way process works in synthesizable code: Whenever an event
occurs on a member of the sensitivity list, the process is entered,
statements run 'in an instant', and the process exits. It may take
days, weeks, or even months before it feels natural. You seem like a
smart cookie, it shouldn't take too long, keep at it.
It might be easier if VHDL had a different word for process, like
'eventblock' or some such, to stress the difference.
Adrian, you've got a bit more learning curve to climb, I've got to get
back to work, and don't want to write your code for you. The last I can
advise is look at other good code examples, get another book, and keep
at it.
Regards,
John
Article: 92202
After implementing the Wishbone interface for main memory access
from JOP I see several issues with the Wishbone specification that
makes it not the best choice for SoC interconnect.
The Wishbone interface specification is still in the tradition of
microcomputer or backplane busses. However, for a SoC interconnect,
which is usually point-to-point, this is not the best approach.
The master is requested to hold the address and data valid through
the whole read or write cycle. This complicates the connection to a
master that has the data valid only for one cycle. In this case the
address and data have to be registered *before* the Wishbone connect
or an expensive (time and resources) MUX has to be used. A register
results in one additional cycle latency. A better approach would be
to register the address and data in the slave. Than there is also
time to perform address decoding in the slave (before the address
register).
There is a similar issue for the output data from the slave: As it
is only valid for a single cycle it has to be registered by the
master when the processor is not reading it immediately. Therefore,
the slave should keep the last valid data at it's output even when
wb.stb is not assigned anymore (which is no issue from the hardware
complexity).
The Wishbone connection for JOP resulted in an unregistered Wishbone
memory interface and registers for the address and data in the
Wishbone master. However, for fast address and control output (tco)
and short setup time (tsu) we want the registers in the IO-pads of
the FPGA. With the registers buried in the WB master it takes some
effort to set the right constraints for the Synthesizer to implement
such IO-registers.
The same issue is true for the control signals. The translation from
the wb.cyc, wb.stb and wb.we signals to ncs, noe and nwe for the
SRAM are on the critical path.
The ack signal is too late for a pipelined master. We would need to
know it *earlier* when the next data will be available --- and this
is possible, as we know in the slave when the data from the SRAM
will arrive. A work around solution is a non-WB-conforming early ack
signal.
Due to the fact that the data registers not inside the WB interface
we need an extra WB interface for the Flash/NAND interface (on the
Cyclone board). We cannot afford the address decoding and a MUX in
the data read path without registers. This would result in an extra
cycle for the memory read due to the combinational delay.
In the WB specification (AFAIK) there is no way to perform pipelined
read or write. However, for blocked memory transfers (e.g. cache
load) this is the usual way to get a good performance.
Conclusion -- I would prefer:
* Address and data (in/out) register in the slave
* A way to know earlier when data will be available (or
a write has finished)
* Pipelining in the slave
As a result from this experience I'm working on a new SoC
interconnect (working name SimpCon) definition that should avoid the
mentioned issues and should be still easy to implement the master
and slave.
As there are so many projects available that implement the WB
interface I will provide bridges between SimpCon and WB. For IO
devices the former arguments do not apply to that extent as the
pressure for low latency access and pipelining is not high.
Therefore, a bridge to WB IO devices can be a practical solution for
design reuse.
A question to the group: What SoC interconnect are you using?
A standard one for the peripheral devices and a 'home-brewed' for
more demanding connections (e.g. external RAM access)?
Martin
Article: 92203Hello, I would like to ask, if there is any downloadable software to implement designs on XC2000 family devices? I know the XACT 5.1.2 is the latest software that support XC2000, and is there any way to obtain a free copy of this software or any other old DOS software that can implement designs for XC2000 devices?Article: 92204
> However, more realistic timing can often be obtained by placing you design unit (presumably will ultimately be located deep within > your design, eg a super fast multiplier) between registers, adding timing constraints and use the static timing report.... > For this kind of exercise I usually use even two registers between the pins and the DUT. When the P&R places the first register in the IO pad the second register avoids a probably long path from the IO to the DUT (assuming that the second register gets placed near the DUT). Another tip: If you have more input and output signals than pins just add more registers and use signals from different pipeline stages. Synthesizer are (not yet) smart enough to optimize this away ;-) MartinArticle: 92205
zora wrote:
> Hi
> I want to correlate my question to Chintan's problem and Alex answer.
> I usually use the method suggested by Alex to handle a bidirectional
> bus, but post PAR simulation (using modelsim) shows the signals on
> the bus delayed of about 12 ns and undefined for the next 5-6 ns
> before to begin stable. When bus comes back in Z state there's also
> a period of instability of 5-6 ns.
>
> The bus default state is 'Z'. It changes state during writing and
> readind operation.
> Microprocessor interface operations use a clock of 80Mhz, but writng
> operation from FPGA to Micro is asynchornous.
>
> I have also noted that this time of instability decreases (to 2-3 ns)
> when I do PAR whit High Effort Level.
>
> Is this a normal situation? or It should be better to investigate for
> the origin of the instability.
>
I am assuming that by "instability", you mean that the bus is rapidly
changing between a bunch of different values. If so, the origin of the
"instability" is variation in the times that the various bits take to
get to the output pins. If you are not using registered outputs, then
this is normal.
In general, there are two approaches that you can use. One is to apply a
timing constraint, something like:
TIMESPEC "TSCLK2PADS" = FROM "FFS" TO "PADS" 12 ns;
That should restrict the period of instability, assuming the tool is
capable of meeting the timing.
The other solution is to register the outputs. Something like:
MICROPROCESSOR_D_BUS<=SOME_SIGNAL when WRITE_TO_BUS='1' else 'Z';
...
if rising_edge(CLK) then
SOME_SIGNAL <= SOME_SIGNAL_I;
end if;
Xilinx will pack those flipflops into the IOB registers (unless you tell
it not to). And then the outputs will all flip virtually simultaneously.
Of course, then you need to account for the extra clock delay on the output.
Article: 92206Do not start a new design with XC2000 products. They are of pre-1990 vintage. My rule is: One year in FPGA evolution equals 15 years in human aging. So these parts correspond to a 15 x 15 = 225 year old great-grandfather. Do not disturb him in his grave. Newer chips are so much easier to design with, and Spartan 3 devices are ridiculously cheap. Don't waste any new-design effort on FPGAs that were introduced at any time in the previous century. Some people may have no choice when they need to fix old designs, but nobody should do this voluntarily. Just aim for the nearest trash can... Peter Alfke, Xilinx ApplicationsArticle: 92207
Francesco, Two years ago I tried the same exercise. I took another group's code, enough VHDL to fill an XC2V3000, which would compile under Synplify, and tried to port it to XST. I won't go into details, but I finally had to give up the effort. I suspect part of the problem may have been that the original code was _very_ strict about using unconstrained arrays in _any_and_every_ place it was possible to do so. This means a lot of work for the tool (not to mention the writer). Here is a link to a very fair, and not too old, article on 'free' tools, like XST, vs. expensive tools like Synplify: http://www.fpgajournal.com/articles_2005/20050322_freetool.htm Quoting from that: "First (at this stage anyway), the commercial EDA tools seem to have an edge in the robustness and versatility in their language front-end. If you don't write perfect, mainstream-style HDL, a commercial tool will often do a better job making some sense of your code and yielding reasonable results than the current crop of vendor-proprietary tools." Personally, I code to XST, on the assumption that if it makes it there, it'll play anywhere.Article: 92208
OOOPS, I wrote: >addrgen : process (clk_i, reset) >begin > if (reset='1') then > ... > elsif (clk_i'event and clk_i='1') then > for i in 0 to 3 loop > spalte <= spalte + 1; > ... > end loop; > end if; >end process addrgen; > > >The iterator 'i' is not even used inside the loop, which should be a >tip-off that something is not right. >Think about what this might do, even if it were a valid piece of code: >Every time a clock edge occurs, "in an instant" the 'for' loop is >executed, and when the process exits, the value of spalte has been >incremented 4 times. This would mean that every clock edge would >increment spalte by 4. HOWEVER, this is NOT valid code, and both >simulation and synthesis produce a counter that increments by 1 on each >clock edge. (Should the tools not even allow this to compile? I don't >know, but mine do) I said that wrong, it IS VALID CODE, but silly. It is equivalent to writing: spalte <= spalte + 1; spalte <= spalte + 1; spalte <= spalte + 1; spalte <= spalte + 1; but the net result is that spalte only gets updated to spalte + 1 when the process exits. It doesn't matter how many assignments you make to a _signal_ during a process 'instant', only the very last assignment is performed when the process exits (mix 'wait's into it, and things are different, but remember, no waits allowed in synthesizable code). Variables (instead of signals) are more intuitive to the programming mindset, see Mike's templates. See, I've been using VHDL for only 4 years now, and still stumble occasionally. Regards, JohnArticle: 92209
"Dave Pollum" wrote: >Shouldn't: > if count(3) = '1' then > count <= count + 1; >be: > if count(3) = '0' then > count <= count + 1; Yes. Thank you. -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 92210
hi, im having a strange problem with the CMOS image sensor ( KAC-9630 ) im using. i've changed the operating mode from snap shot mode to video mode through i2c interface. in this mode it is supposed to continuously acquire images. however it stops acquiring images if the sensor happen to be in light. when i cover it ( make it dark) it works properly. the same happens in default power up mode (snapshot mode), only if i change the video gain to some higher value. default value is 1.1. in this case it stops acquiring one and only frame which should be acquired in this mode. however with the default gain value, it works perfectly even under heavy light. im operating it under the normal recommended conditions. all the configurations are done using i2c interface. If any one can guess the problem, Please let me know. Thank you CMOSArticle: 92211
When using a xilinx DCM, I receive the following warning - Xst:753 - ... Unconnected output port 'CLK2X' of component 'DCM'. Is there someway to let XST know that I dont want anything connected to that port. There is about 6 ports on the DCM that I don't intend to use. Thanks, JoelArticle: 92212
Actually, he might be in the same boat as me. Some of us need to maintain hardware and software developed 15-20 years ago. And this means FPGA development as well. For this, I need to keep an old.... real old... PC around just to maintain my XC3090 stuff. -- Ed "Peter Alfke" <peter@xilinx.com> wrote in message news:1132790004.827979.224250@g47g2000cwa.googlegroups.com... > Do not start a new design with XC2000 products. They are of pre-1990 > vintage. > My rule is: One year in FPGA evolution equals 15 years in human aging. > So these parts correspond to a 15 x 15 = 225 year old > great-grandfather. Do not disturb him in his grave. > Newer chips are so much easier to design with, and Spartan 3 devices > are ridiculously cheap. > Don't waste any new-design effort on FPGAs that were introduced at any > time in the previous century. Some people may have no choice when they > need to fix old designs, but nobody should do this voluntarily. Just > aim for the nearest trash can... > Peter Alfke, Xilinx Applications >Article: 92213
Duane Clark wrote: > Nju Njoroge wrote: > > Hello, > > > > Is there an existing flow for simulating PLB DDR in ModelSim using EDK > > 7.1 SP2 in a full system (PPCs, pcores,etc)? The instructions are being > > stored in BRAMs, as to avoid DDR initialization hassles. I have been > > simulating the data-only DDR using BRAMs, however, to get a more > > accurate depiction of the system, I would like to use DDR in > > simulation. > > Sure you can simulate that. Do you have the DDR memory simulation > models? If not, Micron provides good models on their web site for the > individual chips. Other than that, a specific question of what it is you > are having trouble with would help; your question is too vague to me (or > maybe I am overlooking something). Thanks for the pointers. I'm trying to observe how my design interacts with the PLB DDR Controller in simulation, but to do so, there needs to be a DDR model with which the PLB DDR Controller can interface in simulation. My design has a master PLB interface that issues writes and reads to the PLB DDR controller. Previously, I have been using a PLB BRAM controller, which I verified works in both simulation and in hardware. However, I have been observing differences when I replace the PLB BRAM controller with the DDR. Specifically, for certain test cases, the design using the DDR controller doesn't work. Since my design interacts with the PLB bus, I did not change it when I switched over from the BRAM controller to the DDR controller.Article: 92214
There is a dichotomy between the extreme reliability and longevity of the electronic hardware, and its rapid obsolescence. The equipment does not die, but it gets harder and harder to maintain, let alone upgrade it. The military suffers most from this, but industrial and medical may not be so far behind. Long ago, even telecom moved slowly, but that has changed dramatically during the past decades. Certain chips seem to stay around forever, like the 8051 and the Z80 (I was Zilog Applications in 1978/9), but I don't think you can find a '286 or even a '386 today. Xilinx still offers some XC3000A chips (I think), but the software and the computer operating system are a different matter. My warning was just that nobody should venture into this archaeological trap without a very compelling reason. Peter Alfke, from home.Article: 92215
Just translate "warning" as "reminder" or "observation", if that gives you more mental peace. Peter AlfkeArticle: 92216
>Just translate "warning" as "reminder" or "observation", if that gives >you more mental peace. I think that all software that generates warnings should have some way to say "Thank you, I thought about that one." The main goal is to preserve the signal/noise ratio. If I have to ignore too many warnings I won't be able to find the important ones. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 92217
Very interresting solution. I buy it. Nick On Tue, 22 Nov 2005 22:51:04 -0800, Phil Hays <Spampostmaster@comcast.net> wrote: >Nick <nick@no-domain> wrote: > >>I'm in the final phase of a design in VHDL on a Cyclon, and i am >>really puzzled by something. >>I do not have an external reset pin, so how can i ensure that my >>states machines start at the right state, that all values are well >>initialized and everything ? > >I've never used Cyclon, but I'd expect that there is an asynchronous >reset and/or set applied as part of configuration. If so, then what >you need to worry about is the first clock. As the reset will be >released at different times across the chip, some FFs may be released >from reset before others, and a statemachine may end up in a non valid >state that will prevent correct functioning. This can be solved by >using safe statemachines, so that all non-valid states map into valid >states in at most a few clocks, or by using statemachines with no >invalid states at all. A binary counter, for example, has only valid >states. > >Now, suppose there was a "reset" statemachine that held reset to the >rest of the statemachines until the configuration was released and >all? > >This is fairly simple, put in a binary counter or similar safe >statemachine with more than enough counts (or states) to make sure >that the reset is released, have it hold synchronous reset to the >reset of the design until count complete, then release it. Example in >VHDL follows: > > >use ieee.numeric_std.all; >entity >... >architecture >... > Signal reset : std_logic := '1'; > Signal count : unsigned(3 downto 0) := "0000"; >begin > -- > -- This counter is used to hold all statemachines in reset for the > -- first 8 or so clocks after the end of configuration. > -- > RESET_STATE: process(clk) > begin > if rising_edge(clk) then > reset <= count(3); > if count(3) = '1' then > count <= count + 1; > end if; > end if; > end process; >(rest of code) > > >Note that not all synthesis tools can correctly handle this. Some of >the old tools would have problems with this. While I've used similar >tricks in the past, I have not verified this exact code. > >Note that the number of bits in count needs to be large enough to get >well past the end of asynchronous reset, and not so large as to cause >startup delays.Article: 92218
To figure out the delay of a global clock that isn't driven by a dedicated
global clock pin you should put your design (or at least a skeleton of it)
in Quartus II and compile it. Then you can get a full timing report to see
where you stand. Make sure you set your timing constraints correctly. If
you are running out of global clocks, start trying out some of the
assignments I mentioned in my previous post.
Working out complex delays that include routing from the datasheet isn't
going to work well, so it is much better to move on to Quartus.
In terms of meeting your I/O timing: if your clock has higher delay, you
likely have to delay the data to meet your setup/hold window. Quartus will
do that automatically for you. Just set the appropriate Tsu and Th
constraints on your input pins. 4 ns is a pretty wide window, so you should
meet timing when you compile using the default Quartus settings. For
maximum safety, you should both optimize & check timing for both the slow
timing corner (slow transistors, low V, high T) and the fast timing corner
(fast transistors, high V, low T). To do this, turn on "optimize fast
corner timing" in the fitter settings, and turn on "Report combined fast &
slow timing" in the Timing Settings->More Settings dialog.
*If* there is a problem, you can refine your clocking strategy to reduce the
delay to the registers capturing the input data. The Quartus assignment
editor lets you set different fanouts of a clock to different types of
global resources. Set the "from" node to the clock node, and the "to" node
to the appropriate clock fanouts. So you could make the registers that
capture input data on your 125 MHz clock use local routing ("global signal =
off"), while letting the rest of the clock net be routed on a chip-wide
global network and hence have low skew. If you do this, you have a
potential hold time problem from the "low-delay-clock" capture registers to
the "higher-delay-clock" other registers in the clock domain. If the
Quartus timing analyzer flags such a hold violation, you can set
Assignments->Settings->Fitter Settings->Optimize Hold Time to "All Paths"
and re-compile: now Quartus will insert datapath delay on these register to
register transfers to fix the hold violation for you.
So basically there are algorithms and options in Quartus to make exactly
this kind of system work. Most likely everything will work out fine if you
simply make all the timing assignments and compile. If there are problems,
there are many controls and additional optimization algorithms that can be
turned on to help you close timing.
Regards,
Vaughn Betz
[v b e t z (at) altera.com]
"huangjie" <huangjielg@gmail.com> wrote in message
news:1132745857.693286.66230@g44g2000cwa.googlegroups.com...
> Thanks for Betz and Simon.
> To Simon, my design have some clock at 125M without any phase and
> frequence relations
> but not only one, so which one should be the reference ?
> To Betz, my trouble is NOT too many clocks but tow many interface
> clocks not connected to the
> dedicated clock pin.Although some clocks slow eg:33M PCI,but some of
> very fast 125M.
> I know I can use global clock,but how to calculate the delay of global
> clock?
> Interface has a valid data window about 4ns, how can I or how many ns
> I should shift the global ?
> My problem is skew between chip internal and chip external ,but not
> skew in chip internal.
>
Article: 92219Hal Murray wrote: > I think that all software that generates warnings should have some > way to say "Thank you, I thought about that one." The main goal is > to preserve the signal/noise ratio. If I have to ignore too many > warnings I won't be able to find the important ones. Definitely, even better if it can be done on a line-by-line (enclose statements in a compiler directive) or at least file-by-file basis, much like it can be done in most decent C compilers (and MSVC as well). I guess it becomes more difficult for the latter stages of synthesis when the 'code' bears little resemblance to the originating source?!? Regards, MarkArticle: 92220
"Brian Davis" <brimdavis@aol.com> wrote in message news:1132660954.262101.295110@g14g2000cwa.googlegroups.com... > Andrew Lohbihler wrote: >> >> I've been using the uart_tx and uart_rx core EDIF's provided >> by Xilinx in xapp223 > <snip> >>Does anyone know/have a free/$ replacement to these EDIF's >> that work for the Virtex-4? >> > > see Ken Chapman's old post pointing to the VHDL equivalent of the > XAPP223 UARTS, which can be found in the Picoblaze sources: > http://groups.google.com/group/comp.arch.fpga/msg/0d3017a2beb810fd > > Brian > Thanks to all! i did find the source code in www.picoblaze.com as Ken Chapman's code. The old EDIF's are not reproducable for the V4 because of the architecture changes from V2 to V4. The souce code solves these issues. -AndrewArticle: 92221
ssirowy@gmail.com wrote: > My ultimate goal is to try and investigate how much of an impact > adding 1, 2, 4, X amount of peripherals onto the local memory bus has > on processor clock impact. I want to be able to allow each coprocessor > to have single cycle access, which should in theory impact the clock > speed of the Microblaze. Is there a way for me to model and show this > impact on the processor clock with the EDK? > You have to do a full implementation if you want to see the real impacts. Keep in mind that the data side LMB of MicroBlaze is NOT single cycle but it takes two clock cycles for each load or store. Take a lmb_bram_if_cntrl as the start for your lmb slaves. One thing, there is no absolute truth on what impact you will see. It will depends on many other different features of your system - What fpga device - What speed grade - What other feature of MicroBlaze is used - How full is the device - What LMB slaves that you are using and how they are implemented ... You should also run Multi-pass PAR (more than 10 passes at least) and take the average. One question, what is the purpose of this study?Article: 92222
Shure, there is too big volume. Will program at first and then to sold them. I had a hope to grab some tool under this project. Chief have smirked and tell me to use Parallel Cable to my experiments. Bummer. :-) We have the way to reprogram flash in complete product. Our board contains just couple of chips wich support JTAG. We don't use it. Thanks to all.Article: 92223
On 23 Nov 2005 01:38:02 -0800, v_mirgorodsky@yahoo.com wrote:
>Hello ALL,
Hi Vladimir,
>I have a design with two global clocks. I have data I need to transfer
>from one clock domain to another. I am aware of existence of FIFO
>blocks :), but it seems to be too expensive to spend a block-ram and
>other resources for every boundary crossing. To avoid using FIFO blocks
>we created a handshake schematic, based on some triggers and small FSM.
>This solution is proven to work in hardware error-free for almost 40
>hours. First domain clock frequency is 25MHz or 125MHz (depending on
>mode); second domain clock frequency is 166MHz.
40 hours of testing is not nearly enough for almost any system. You
desperately need to read this:
http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
to get a better understanding of the issues. Since you don't say what
FPGAs you are using, I can't guide you to specific numbers, but there
is significant information at the Xilinx web site that describes the
metastable parameters for various product families.
For example, XAPP094 and
http://klabs.org/richcontent/General_Application_Notes/mestablestates/xilinx_metastable_recovery.pdf
There were also some Xcell articles I believe.
You need to use this data plus a careful analysis of your design and
its post place and route timing and cycle margin, to calculate Mean
Time Between Failures (MTBF). For example, Peter has given you some
numbers in his answer to your question, but he has assumed that you
are using very recent products, and has not made clear that the
metastable characteristics depend on the device you are using.
>Naturally, some triggers in our design are metastable. Is it possible
>to get some intermediate voltage level at the output of trigger in FPGA
>if input signal on its Data input violates setup or hold times?
This is why you need to read the FAQ article above. Metastables can
give many possible anomalous types of behavior, depending on the
actual circuit design. You can get metastables that transition cleanly
between logic 0 and logic 1. The metastable behavior is that it occurs
later than Tcko MAX. (greater than the clock-to-output max delay for the
Flip Flop, taken from the data sheet)
As Peter said in his response:
"Don't worry about strange levels. It's the unpredictable extra delay
that is the problem."
This doesn't mean that strange levels don't occur, but the end result
of metastables regardless of their signal levels while getting to a
final stable value is that the time to get to the stable value is
unbounded.
>In my design I assume I don't get any intermediate level voltages
>at the trigger outputs.
It is not clear what you mean by "triggers". When a signal goes
metastable, it can do many strange things: oscillate, intermediate
levels, normal levels, multiple transitions, ...
>What about signal I input into FPGA from outside? Is
>it possible to get some intermediate voltage levels on the trigger
>outputs by violating setup-hold times and/or IO standard voltage
>levels?
Anything that violates setup and hold to clock can cause metastables.
>With best regards,
>Vladimir S. Mirgorodsky
Cheers,
Philip
Philip Freidin
Fliptronics
Article: 92224Thanks all, JustJohn XST has been improved a lot from the version 6.1 to 7.1. 2 years ago you tryed XST 5.1 maybe or 6.1..... I found XST (ISE 7.1) much improved but I'm not 100% happy. Alan thanks for your answer is very important to me. Thanks again all, Francesco PS: I hope to have some feedback from Xilinx about that :-)
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