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
Hi Jerker, >From reading your various postings, I believe the summary is: You have a state machine. It gets into illegal states. It does it about 1 out of 10 times on startup. You do not have an async reset to the FSM. Your async inputs to the state machine go through a single flipflop. You are investigating ways of detecting illegal states and want to get back to a valid state. You specify initial values (in VHDL). Your static timing analysis indicates no problems. Your clock frequency is 20MHz. On Wed, 7 Jul 2004 19:51:32 +0200, "Jerker Hammarberg \(DST\)" <jerkerNO@SPAMdst.se> wrote: >Hi all! I'd like to once again bring up the subject of state machines >running into illegal states (illegal in the sense that the state vector does >not correspond to any of the states defined in the VHDL code), ... > >1. Most discussions cover how to recover from illegal states, but few cover >how it actually happens. ... > >2. How can I force Xilinx XST (6.2 SP3) to produce a safe FSM that recovers >from an illegal state? ... > >/Jerker In summary from other postings: This might be metastables. This might be a timing problem. There is an asyc reset, which occurs when your chip goes active. (FPGAs and CPLDs do this differently, but the effect is similar) There are various noise sources that could cause this: kai: "Internal noise coupling in the chip (crosstalk), power drops, alpha particles, not properly double-sync'ing an async signal before using it in two different places ... the list goes on! Phil Hays wrote: "You do have an asynchronous reset, you just didn't know that you did. When a Xilinx FPGA finishes the program download, it has all initial values held until an internal signal is released. This release is asynchronous to your clock. To avoid problems with this add a counter that is reset to all zeros. Until that counter counts to 15, keep the state machine in the initial state." Rickman wrote: "Figure out what is wrong and deal with the cause of the problem." You wrote: "I doubt that it's about static timing in my case since my clock is 20 MHz, and XST's post-layout static timing analysis doesn't complain. Metastability could be an issue, but it's strange that it happens so often. On one particular design, it happens about once every ten times i startup the system. All inputs are synchronized with one FF each, but I'll try adding a second one to see if it helps." Here is my analysis: Trying to change your design to get out of illegal states is nearly pointless, since A) it is hard to do B) the tools work against you C) you may not catch all possible cases D) by the time you detect it, damage has already been done E) if the cause is gross signal integrity problems such as unreliable power, then you FSM is the least of your problems. (there are exceptions to this, such as remote systems (no one to push the reset button, ultra high reliability systems (tolerates rare alpha particle upsets) ) Rickmans quote above is spot on. Since this happens 10% of the time in a system at 20MHz, this is not metastability. If you want to learn more about metastability, this is my favorite URL: http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm Even though your problem is not metastability, once your current problem is fixed, the much rarer problem of metastability may cause problems. A double synchronizer on all your async inputs is cheap insurance. You wrote: "I doubt that it's about static timing in my case since my clock is 20 MHz, and XST's post-layout static timing analysis doesn't complain." Your assertion that static timing analysis indicates that there are no problems is insufficient. I have seen far too many designs by engineer that proudly show the static timing report showing that there are no errors, but they have not generated the "unconstrained paths" report. The static timing analyzer tells you that of the paths you have constrained, these all meet timing, but the delay on the unconstrained paths is unbounded. You need to identify all unconstrained paths and either be able to explain why they dont need a timing constraint (such as a push button input), or add constraints so that the paths are covered. Phil Hays' quote above is almost certainly identifying your problem, and gives a fine solution. Let me expand on it. The problem is that when the chip goes active, you have logic signals that go into the state machine that cause it to transition to a next state immediately. Since the going active is asynchronous to the 20MHz clock, you may have anywhere from 50 to 0 ns to do this. This represents a race condition (not a metastability), and in 10% of your startups, you lose the race. As others have described, not all parts of the state machine have enough time (when the available time is less than 50 ns) to transition to the next valid state. Phil's (and Philip's) solution is to hold off the first transitions of the state machine until a few cycles after the chip goes active. Phil's solution suggests 15 cycles, probably anything over 4 would be rock solid. As an example, I usually use a 4 bit shift register to do this. Either way, it works like this: The hold-off circuit is initialized to 0000 (counter or shifter). The release of reset (chip going active) allows either to start changing. Phil's counter counts up, in my case the D input to the shifter is tied high, so I start to shift in '1's (0000->1000->1100->1110->1111->1111 ...) For Phil's counter, you probably would want to make it dead-end at 1111, and not wrap back to 0000. Neither the counter or the shifter can't get to their terminal state other than through multiple cycles of the clock. In your FSM, the initial state is set in your VHDL. Depending on what your FSM does the transition out of this state may be to one or more states. For ALL of these exit conditions, you need to add an additional signal, the detection of the terminal state of the hold-off circuit. The result is that the FSM cant leave the initial state until several clocks after the chip goes active, because the same logic that initializes the FSM, is also holding the hold-off circuit in its initial state. By the time the FSM is allowed to make its first transition, it will have stable input signals (through the double synchronizers) and it will have a full cycle to do its transition. Additional answers to some of your other questions: "But your point is still interesting in case I would need to introduce an asynchronous reset some day. Does that mean one should avoid them if illegal states are a concern?" Yes, you should avoid async signals and resets, regardless of whether you are concerned about illegal states. If you must have broadly used resets, then the common recommendation is async assertion, and sync de-assertion. You wrote: "Metastability could be an issue, but it's strange that it happens so often. On one particular design, it happens about once every ten times i startup the system. All inputs are synchronized with one FF each, but I'll try adding a second one to see if it helps." Right. The 1 in 10 occurrence rate is far to high to be metastables in a system running at 20MHz. Your async inputs to the state machine should have at least a double synchronizer. (read the above URL). The double synchronizers is just good design practice. In summary: Add the hold-off circuit, and check the unconstrained paths report in the static timing analyzer. Good Luck, Philip Philip Freidin FliptronicsArticle: 71101
Hi, I would like to know if the Ethernet packets sent through the Nios Ethernet Kit, do they have a 32-bit CRC as the trailer. If there is a CRC trailer does the Nios software and hardware check this automatically? And if there isn't a 32-bit CRC trailer, how can we calculate and add this? ThanxArticle: 71102
Lookup table is the answer... FPGA-based designs usually have abundant LUTs... Kelvin "Andy" <bayou1221@yahoo.com> wrote in message news:cbff8633.0406222001.6d2a0e93@posting.google.com... > Hi all, > I am trying to implement a small ALU module using the Xilinx ISE web > pack and the simulator is Silos. > When I try to synthesize this design, it gives me an error for the > division. I have implemented division directly, i.e. out <= A / B; > All I know is this is a pretty inefficient way of doing it but was not > expecting errors. > > Any tips or pointers will be very helpful. > > Thanks, > AndyArticle: 71103
benkhalh@hotmail.com (Oleg) wrote in message news:<5f8ab9cc.0407070601.1b243a93@posting.google.com>... > Hi, > Help me please to fixe the folowing probleme: > > When i open PACE window (ISE 6.1)to create area constrainte (region), > in the design broser window (top most left window in PACE) there are 3 > folders : I/O pins, Global Logic and Logic, this last one should > containe the logic of my design(by blocks) but its empty, Why? how to > fixe this? is it because the tool dont keep the heararchy of the > design??? If you have choosen Property Keep Hierarchy "NO", then you can place only hole design. When you select Keep Hierarchy "Yes" then you can place allso sub modules and so on. TPalmArticle: 71104
Hi, there: My clk_4m is generated from clk_12m through a divide_by_3 state machine... And I feed clk_4m into a BUFG also...I estimate the time from rising edge of clk_12m to clk_4m is 3.6 ns...Can I write these two constraints? NET "clk_12m" TNM = "clk_12m"; TIMESPEC "TS_clk_12m" = PERIOD "clk_12m" 83.3 ns HIGH 50 %; NET "clk_4m" TNM = "clk_4m"; TIMESPEC "TS_clk_4m" = PERIOD "clk_4m" TS_clk_12m / 3 PHASE + 3.6 ns; Thanks. KelvinArticle: 71105
> In Germany your are right that you could ignore any license agreement, > when purchasing a standard programm (enter the shop and buy a CD). But > you have to deal with the license agreement, when purchasing a license > (or get it free) by downloading a software. > > These are two different things, which seem very similar. Probably not. By downloading you are receiving a single copy of the software. The process of copying was initialized by the seller. Only the ownership of that copy is transfered, there is no license for copying necessary, the transaction can be handled as a purchase. Also, the buyer probably believes this is a purchase anyway, so that a license contract is likely to be void. One could argue that the process of copying is performed by the person doing the download, but that view has MAJOR implication on copyright law. Basically it makes P2P downloads legal in many countries. So don't expect that view to be successful. Again, IANAL, Kolja SulimmaArticle: 71106
Hello,
I built my design with EDK (using BSB base system builder),
I generated my xparameters.h
I compiled U-boot (the bootloader)
I generate an ace file. ($ xmd genace.tcl -jprog -board ml300 -hw
implementation/download.bit -elf u-boot -ace top.ace, I used:
genace.tcl given by xilinx in a reference design)
When running u-boot on the ML300 board, I have nothing on
Hyperterminal???
I don't understand where is the problem (it is not a problem of a
baudrate, and I have tested my design in standalone and it is OK)
Thanks
Abdelmajid
Article: 71107try using the incremental design flow? http://www.xilinx.com/bvdocs/appnotes/xapp418.pdf "Oleg" <benkhalh@hotmail.com> wrote in message news:5f8ab9cc.0407070601.1b243a93@posting.google.com... > Hi, > Help me please to fixe the folowing probleme: > > When i open PACE window (ISE 6.1)to create area constrainte (region), > in the design broser window (top most left window in PACE) there are 3 > folders : I/O pins, Global Logic and Logic, this last one should > containe the logic of my design(by blocks) but its empty, Why? how to > fixe this? is it because the tool dont keep the heararchy of the > design??? > Note: this happen when i use VHDL entrance to ISE tool,but does not if > i use Synplify to synthesis my design and then i entre EDIF file to > ISE(her i can see and plce my blocks). > > This is very important for me since i need to place manualy some > blocks of my design to get a better speed. > > Thanks for any help.Article: 71108
> Each valid state will have a number of hold-until-next-move-true terms, > but states not covered will have NO .D terms, and so their NEXT state is > Q0.D = 0; > Q1.D = 0; > or to the 00 state. > > If you code > IF State=11 THEN immediate_next = 00, then no more logic is generated, > as that is implicit. All right, NOW I see your point! But it seems to me you're assuming that the synthesis tool always generates the transition logic such that illegal states always transition to the state vector of all zeroes, and I'm not yet convinced that this is the case. I would have believed that the transition function would map all illegal states to "Don't care", allowing the tool to minimize the transition logic. As a consequence, the illegal states could transition to anyting, including the same illegal state, which means it's stuck. But I will try to investigate how XST generates the transition logic. If you're right, you definitely answered my question no 2. /JerkerArticle: 71109
Hi all, What would be the optimal way, in terms of device utilization and functionality, to exstend the length of the time a signal is asserted from one clock cycle to four clock cycles. I.e. [pseduo code:] if signal_a is asserted then signal_b is asserted for four clk; Is it possible to accomplish the function by utilizing an SRL16, or is there a better solution? Or should I simply create four delayed versions of signal_a, and OR them together to form signal_b? I'm working with a Virtex-2 device. regards -- ----------------------------------------------- Please remove the x's in the email address if replying to me personally. Johan Bernspång, xjohbex@xfoix.seArticle: 71110
We have some programming files (we have rights to the source, and have hardcopy of the source in schematics, no softcopy) for some ACTEL FPGAs (AT1240XL and AT1225XL). We are in the process of creating VHDL code for these parts so we can make changes and do some integration. We would like to do some simulation to verify our new code against the old design before we put our new code in hardware. Does anybody know of a way to create a black box simulation model (preferably VHDL) for the FPGAs from the programming file? I realize that a net list is not usable, but the should be able to extract the input to output logic and timing based on fuse map information.Article: 71111
tns1 wrote: > I am using the QII4.0 SP1 web edition, SOPC4.0, Nios3.2 tools to develop > on a Cyclone C4 system. I have had problems taking working projects > created with the licensed versions of the tools, and re-building, > re-generating, and compiling some C with the web edition, and getting > the resulting pof & srec to work properly. If I leave the project alone > and just re-compile the C, it works. Somehow the pof or the srec I > produce is faulty. The timing report says timing is good, so I suspect > that the Generate step is not producing good libraries. The resulting > system partially runs, but strips off the leading chars of every printf, > along with other quirks. > > So whats the story on compatibilty? Should it work, or is the web > edition intentionally crippled in this way? > According to Altera there is some incompatibility between the licensed & web edition SW prior to NiosII/QII4.1. This is supposed to be fixed with the newest NiosII/QII4.1 release in that you should be able to modify & rebuild projects built with the licensed SW on the web edition.Article: 71112
rickman <spamgoeshere4@yahoo.com> writes: <much snippage> > Rajeev wrote: > > (1) Is it a bad idea to use 'X' in a simulation ? > > It would seem X is not a useful state in this simulator. In a proper > VHDL simulator X has a defined behavior and is the default for FFs that > are not init'd or inputs that are not assigned. > To be a bit more specific, 'U' is the undefined or "start-up" state. 'X' is what appears when you drive two clashing values onto a std_logic. Or when the simulator sees a D input change inside the setup-hold window of a FF. I've never used an 'X' in simulation - created a few inadvertently though... If you want a "don't-care" use '-' instead. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 71113
We have been using Xilinx Student Edition 2.1i in a Third World university for several years. Now that we have upgraded to Windows-XP, it refuses to install, giving a message that java.exe is producing an unhandled exception (looks like stack problem). Does anyone know of a fix that would allow us to use the older software on the new operating system? If so, it would save us changing devices, software and experiment boards with our non-existent foreign currency. Any ideas?Article: 71114
Hi, My suggestion to you is: * Revert to Windows 2000, preserve your hardware and software investment. Windows 2000 isn't that bad... But 2.1i is now pretty stale. As are the XC4000-style parts, which I assume you are using. * Submit a donation request to the Xilinx University Program, for software and the hardware you require. It is worth a shot... At SJSU, we check out one board to groups of two or three. And I tell them they are always welcome to buy their own boards. The recently released Spartan-3 board is cheaper than many textbooks (in the US, anyway...) In the worst case, you buy 15 ($1500) and WebPACK is free. In the future, if at all practical, you might consider having a nominal "lab fee" like some labs at SJSU. You can save the proceeds over several years and then use it to upgrade your hardware in an attempt to stay current. When making your decision, you might also consider the overhead in updating all the coursework to the new tools. I went through this (2.1i schematic --> 4.2i verilog) and it took a lot of work. In the end, it was worth it though. You're welcome to pull any material you want from: http://www.engr.sjsu.edu/crabill Eric Mike Collier wrote: > > We have been using Xilinx Student Edition 2.1i in a Third World > university for several years. Now that we have upgraded to Windows-XP, > it refuses to install, giving a message that java.exe is producing an > unhandled exception (looks like stack problem). Does anyone know of a > fix that would allow us to use the older software on the new operating > system? If so, it would save us changing devices, software and > experiment boards with our non-existent foreign currency. Any ideas?Article: 71115
continuing the discussion about Lattice's DSP block, I found the following interesting article: http://www.fpgajournal.com/articles/20040706_lattice.htm regards, paul Luc Braeckman <luc.braeckman@pandora.be> wrote in message news:<lodne0lvp5eovdjm6v670bcrm4uod7vs1i@4ax.com>... > Joseph, > > I tried the software, and it looks good. As you mentioned, they share > a similar GUI, even the EPIC editor is similar. > Of course the libraries aren't complete yet, but it gives you a good > feeling of the possibilities. > > You're right, with the introduction of the 90nm SC parts, I think they > can compete with every other high-end FPGA. > > Luc > ___ > > On Tue, 6 Jul 2004 21:18:17 +0000 (UTC), jhallen@TheWorld.com (Joseph > H Allen) wrote: > > >Have any of you tried Lattice's software for their new -EC parts? How close > >is it to Xilinx (they share a common heritage)? I'm trying to get a feel > >for its quality and stability. > > > >Things should be getting interesting when their 90nm -SC parts come out (vs. > >Stratix-II and Virtex-4), especially with their cool DDR I/O interface. > >Perhaps Lattice will make a come-back?Article: 71116
"Yttrium" <Yttrium@pandora.be> wrote in message news:<ueaHc.178265$9C7.8746094@phobos.telenet-ops.be>... > try using the incremental design flow? > > http://www.xilinx.com/bvdocs/appnotes/xapp418.pdf > > "Oleg" <benkhalh@hotmail.com> wrote in message > news:5f8ab9cc.0407070601.1b243a93@posting.google.com... > > Hi, > > Help me please to fixe the folowing probleme: > > > > When i open PACE window (ISE 6.1)to create area constrainte (region), > > in the design broser window (top most left window in PACE) there are 3 > > folders : I/O pins, Global Logic and Logic, this last one should > > containe the logic of my design(by blocks) but its empty, Why? how to > > fixe this? is it because the tool dont keep the heararchy of the > > design??? > > Note: this happen when i use VHDL entrance to ISE tool,but does not if > > i use Synplify to synthesis my design and then i entre EDIF file to > > ISE(her i can see and plce my blocks). > > > > This is very important for me since i need to place manualy some > > blocks of my design to get a better speed. > > > > Thanks for any help. Hi, Yes, the option keep_hierarchy = 'yes' did realy help to solve this, but the area occupation increases because of this and i have no idea how to overcome this, or at least reduce it...??? I will conceder the incremental design to see what it gonna give. Thaks guysArticle: 71117
On Thu, 08 Jul 2004 02:55:08 GMT, Philip Freidin <philip@fliptronics.com> wrote: > .... much good stuff .... :-) > >Neither the counter or the shifter can't get to their terminal state other than >through multiple cycles of the clock. > of course this should be: Neither the counter or the shifter can get to their terminal state other than through multiple cycles of the clock. Philip Philip Freidin FliptronicsArticle: 71118
Duane Clark wrote: > > rickman wrote: > > > > I am unclear as to why the others clause would not result in recovery > > from an illegal state. That could very easily add a lot of extra logic > > and even slow the max speed of the FSM. But it should not be optimized > > away since it is a specified part of the machine. I assume the illegal > > state detection works in simulation, no? If so, it should work in > > operation. > > > > The synthesis tools are "smart" enough to recognize that there is no > logical way to reach the "others" state. Therefore it is optimized out. > Many synthesis tools do this. If this were true, then you would never need to specify that you are using one-hot encoding. The states that are not used would be detected as not needing to be decoded and the logic would automatically minimize to just using one bit to represent each state. But I have seen guides and HDL books explicitly tell you to either use an attribute to inform the tool that you are using one-not encoding or to do the encoding yourself by not using a case statement. Where have you seen that a tool will optimize away the others clause? I would like to read further on this. Are you talking about a FSM using an enumerated data type? That would certainly not use the others clause if all the listed values are covered. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71119
"Jerker Hammarberg (DST)" wrote:
>
> Hi Rick, thanks for your reply!
>
> > 1) electrical noise which would also cause upset of *other* FFs in the
> > system causing other symptoms and
>
> I don't think I can rule that out in this specific application. But
> where, that is on what physical signal, do you mean the electrical noise
> would occur, and how could it affect the FPGA's internal state?
The noise could be on the power rail or ground bounce. It does not need
to be on an input signal.
> > 2) timing issues with the FSM. This can be either from async inputs
> > (metastability) or from failing to meet setup time on a reg input. If
> > you have done your static timing analysis correctly, then it must be a
> > metastability issue. The fact that it occurs happens on startup says
> > to me it is a timing issue. If you can chase the problem away by
> > slowing your clock, then it is a static timing issue. If it persists,
> > then you most likely have a metastable issue.
>
> I doubt that it's about static timing in my case since my clock is 20
> MHz, and XST's post-layout static timing analysis doesn't complain.
That depends entirely on your timing specs. If you have none, then they
are not likely to be wrong ;) XST will be trying to make every path
meet single clock timing.
> Metastability could be an issue, but it's strange that it happens so
> often. On one particular design, it happens about once every ten times i
> startup the system. All inputs are synchronized with one FF each, but
> I'll try adding a second one to see if it helps.
As others have suggested, if it fails on startup, it could easily be the
async reset vs. clock. I think you made two bad assumptions from the
way you describe your initial state. You indicated you used "initial
values by declarations". I don't think synthesis tools use initial
values as reset values. I have never asked if XST does this or not
since I don't depend on this. Accepted style is to put it explicitly in
your hdl code like this...
ByteFlag: process (SysClk, Reset) begin
if (Reset = '1') then
membyte <= '0';
elsif (rising_edge(SysClk)) then
if (set_byte = '1') then
membyte <= '1';
end if;
end if;
end process ByteFlag;
This code will use SysClk as the clock, Reset will init the FF to 0 and
set_byte will set the FF to a one. You can then use this signal as a
internal reset to other logic. Since it is synchronized it will allow
an FSM to get off on the right foot. You should not use the same signal
throughout your chip as it will most likely have significant routing
delay and miss setup times. Use a different copy for each FSM.
BTW, the Reset signal will sometimes automatically be connected to the
internal power on reset. It may require you to explicitly connect it
using an instantiated primative. Read up on XST and how it handles
resets.
> > I am not a fan of dealing with this type of problem by illegal state
> > recognition. If it gets into an illegal state it has already caused a
> > malfunction of the rest of the circuit most likely. Getting back to a
> > known state is only useful in that it can resume normal operation.
> > But it is not a "fix".
>
> I agree totally, that's why I pointed out that most previous threads
> dealt with recovery from but not with the cause of illegal states.
>
> > I am unclear as to why the others clause would not result in recovery
> > from an illegal state. That could very easily add a lot of extra
> > logic and even slow the max speed of the FSM. But it should not be
> > optimized away since it is a specified part of the machine. I assume
> > the illegal state detection works in simulation, no? If so, it should
> > work in operation.
>
> Well, the FSM optimizer detects unreachable and removes related logic,
> and I guess that's what's happening here too. Indeed, if I simulate the
> RTL code as it is, I can't put the design in an illegal state - there is
> simply no signal that I can force to an illegal value. But if I add a
> dummy state in the enumerated state type definition without adding a
> "when" clause for it, then I can enforce the dummy state and the "when
> others" clause is applied. If I simulate the post-layout code, I would
> be very surprised if the illegal state detection worked since it was
> taken away during synthesis, but I haven't tried it.
You can directly force the FSM FFs into any state you wish. I have not
done it often, but I have used this feature. Read up on your simulator.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 71120"Jerker Hammarberg (DST)" wrote: > > Hi Jim! > > > Do LOOK at the resultant output of your tools, and HOW it actually > > built the FSM. It can use .D or .T registers, with .D the most common. > > Well, the output netlist isn't exactly human-readable, although I guess > I could write a simple FSM, synthesize it and study it. But actually I > already know how XST has encoded my machine. My options are essentially > One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably > on D flip-flops. I get One-Hot encoded machines unless i ask for > something else. > > However, correct me if I'm wrong, the state encoding itself doesn't > change anything in the machine's ability to recover from illegal states > - it takes some logic that detects these illegal states and forces the > state vector back to normal, and that logic obviously isn't there. Many > synthesis tools provide an extra option "safe FSMs" which will add such > logic, but XST doesn't. So my question is XST-specific - how do I add > illegal state recovery logic with XST? One other thing you can do is to add the logic manually. If you are using an enumerated data type, you can get the encoded value. Write your own logic on this state value and detect the illegal combinations. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71121
Hi Philip, and thank you for your enlightening and extensive reply! > From reading your various postings, I believe the summary is: > > You have a state machine. > It gets into illegal states. > It does it about 1 out of 10 times on startup. > You do not have an async reset to the FSM. > Your async inputs to the state machine go through a single flipflop. > You are investigating ways of detecting illegal states and want to get > back to a valid state. > You specify initial values (in VHDL). > Your static timing analysis indicates no problems. > Your clock frequency is 20MHz. Right, I should say that this design with 20MHz and 1 out of 10 failure rate is just one of several designs that I have problems with. I don't only want to solve the problem for that particular one design; I want to learn as much as possible about this issue, so that I can solve the problem for all my designs and avoid it in the future. For that 20MHz design, I could add that it doesn't seem to happen when the board's power supply is less loaded. Considering that it almost always happens on startup, when components all over the board need a lot of current, I suspect it might have something to do with voltage dips. But I don't see why that would only result in a state machine hanging; I would expect to see more diverse errors. Whatsoever I will examine the voltage curve on powerup. > If you want to learn more about metastability, this is my favorite > URL: > http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm > > Even though your problem is not metastability, once your current > problem is fixed, the much rarer problem of metastability may cause > problems. A double synchronizer on all your async inputs is cheap > insurance. I actually read the faq before posting, like a good newsgroup poster should do! I will add a second synchronizer, but it hurts a little, because one of the inputs is an SPI clock and the FPGA is supposed to react as fast as possible on its edges. > You wrote: "I doubt that it's about static timing in my case since my > clock is 20 MHz, and XST's post-layout static timing analysis doesn't > complain." > > Your assertion that static timing analysis indicates that there are no > problems is insufficient. I have seen far too many designs by engineer > that proudly show the static timing report showing that there are no > errors, but they have not generated the "unconstrained paths" report. > The static timing analyzer tells you that of the paths you have > constrained, these all meet timing, but the delay on the unconstrained > paths is unbounded. You need to identify all unconstrained paths and > either be able to explain why they dont need a timing constraint (such > as a push button input), or add constraints so that the paths are > covered. I have to admit I haven't cared much about static timing, since I believed that if I specify a clock period constraint, all FF to FF paths would be constrained by this time, and that's all I need in a completely synchronous design. Is that wrong? Anyway, I realize that I need to learn more about timing... or finally tell my boss I shouldn't be doing FPGA design without proper education. I will check the unconstrained paths, but I expect to find only input to FF and FF to output paths. I don't care about output delay since they are only connected to leds and SPI units working at a considerably slower rate. In particular, these paths can't affect my state machines. And the inputs can arrive anytime anyway. Would you agree that given this, I could rule out timing issues (apart from the following)? > Phil Hays' quote above is almost certainly identifying your problem, > and gives a fine solution. Let me expand on it. The problem is that > when the chip goes active, you have logic signals that go into the > state machine that cause it to transition to a next state immediately. > Since the going active is asynchronous to the 20MHz clock, you may > have anywhere from 50 to 0 ns to do this. This represents a race > condition (not a metastability), and in 10% of your startups, you lose > the race. As others have described, not all parts of the state machine > have enough time (when the available time is less than 50 ns) to > transition to the next valid state. Phil's (and Philip's) solution is > to hold off the first transitions of the state machine until a few > cycles after the chip goes active. Phil's solution suggests 15 cycles, > probably anything over 4 would be rock solid. As an example, I usually > use a 4 bit shift register to do this. Either way, it works like this: This was totally new to me. I take it ALL state machines that may transition on the first clock pulse need this kind of protection. Thanks again, Philip (and Phil)! /JerkerArticle: 71122
Kelvin, if for some reason you decide not to use a DCM to do the frequency division, you can do this with two flip-flops and their two LUTs. The input clock to output Q is exactly one "clock-to-Q" parameter. There can be only one result, unless you insist on doing something weird and non-synchonous.. Peter Alfke, Xilinx Applications From: "Kelvin" <student@nowhere.com> Organization: StarHub Internet Pte Ltd Newsgroups: comp.arch.fpga Date: Thu, 8 Jul 2004 15:45:54 +0800 Subject: How to constrain a divide by 3 clock? Hi, there: My clk_4m is generated from clk_12m through a divide_by_3 state machine... And I feed clk_4m into a BUFG also...I estimate the time from rising edge of clk_12m to clk_4m is 3.6 ns...Can I write these two constraints? NET "clk_12m" TNM = "clk_12m"; TIMESPEC "TS_clk_12m" = PERIOD "clk_12m" 83.3 ns HIGH 50 %; NET "clk_4m" TNM = "clk_4m"; TIMESPEC "TS_clk_4m" = PERIOD "clk_4m" TS_clk_12m / 3 PHASE + 3.6 ns; Thanks. KelvinArticle: 71123
> One other thing you can do is to add the logic manually. If you are
> using an enumerated data type, you can get the encoded value. Write
> your own logic on this state value and detect the illegal
> combinations.
I'm not so sure... again, XST finds all unreachable states and takes
away the logic for them, even states that are legal and have their own
"when" clause. I've even seen in another thread on comp.lang.vhdl the
suggestion to connect an input pin to ground, then add code to the state
machine like
if ground_signal = '1' then
state <= UNREACHABLE_STATE;
end if;
just to prevent XST from taking away the logic for UNREACHABLE_STATE.
But I was hoping there were better solutions...
/Jerker
Article: 71124Makesh Soundarajan <makesh_s_e@hotmail.com> wrote: Dear Makesh, I will send you a pice of code which will toggle DAC A and DAB B output with no addional requirements tomorrow. I have used the 24 bit mode. Concerning the DAC the update rate is 900ks/s. If you run both DACs in parallel it ends up at approx. 450ks/s each. Its just about how to write data sheets... BTW: The user constraints file is ok? Have you checked the DAC input lines with a scope? Best regards and please rinind me if you dont receive the file, Christoph > Hi Christoph, > > Thanks a lot for bringing that to my attention. Inspite > of using a jumper for channel B and the changing the code for channel > B I still get a 0 voltage output. I think I am running into some > timing issues. > > Did you use the 24 bit or 32 bit load sequence ? If > possible could you post first few lines and last few lines of the dac > controller code. > > Thanks once again for your prompt post. I was about to > use another D/A > > > Thanks > Makesh > > >> Makesh Soundarajan <makesh_s_e@hotmail.com> wrote: >> >> Dear Makesh, >> >> I have had some small problems with the LTC1654 as well. >> Have you also started with the DAC A output? >> >> If you close the jumper at least DAC B should work. To make DAC A >> running you have to lift the corresponding pin of the LTC1654 and >> connect it to GND with a short wire. There is one capacitor connected to >> GND close to that pin. This is a suitable point to get the GND signal >> from. >>
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