PLD Blog

Package Generated Alpha Particles: They are a Problem and Here is the Information

austin.lesea — Thu, 12 Nov 2009 22:47:22 GMT

There are two sources of alpha particles and both cause upsets

Helping the Customer Drive to ‘Zero Defects’

austin.lesea — Thu, 15 Oct 2009 22:19:38 GMT

For this blog, I have invited John Latimer, a director of world-wide customer quality engineering, to provide us with a view of our philosophy in how we are improving our quality.

Targeted Platform Design

austin.lesea — Thu, 01 Oct 2009 23:10:09 GMT

What in the heck are we talking about?

Re: Welcome to My World

wellion990 — Sat, 05 Sep 2009 00:10:44 GMT

It Is All About Quality

austin.lesea — Thu, 03 Sep 2009 22:55:12 GMT

Recently I was asked to deliver a presentation on design techniques for a meeting with some customers. Just before I delivered my presentation, a friend from the Quality organization here at Xilinx presented on our quality.

Re: That Dangerous Asynchronous Reset!

kcmman — Wed, 29 Jul 2009 10:42:23 GMT

Dear jnm,

Sorry to hear of your problems but I’m afraid they are not unsurprising to me. As long as people continue to design using these ‘global asynchronous reset’ signals these problems will be there to bite just when you don’t want them too. Clearly it is better top avoid them by design rather than look for ways to patch them afterwards and I’m sure you will now be motivated to do that in your future designs.

The suggestions made sound reasonable but probably still will not provide a solution in most real designs. All the suggestions are really a way to enforce a synchronous operation onto an otherwise asynchronous design. In each case they are ways to make sure that the reset signal (when going active or inactive) has been distributed to all loads meeting set-up time before the next clock edge then it will be safe and work. The key point about these paths is that simply reaching a flip-flop reset pin is not enough; the path from that flip-flop that gets asynchronously reset to its load(s) is also part of the path that must meet timing. The net effect being that the clock frequency needs to be rather slow (like in the good old days when most designs were less than 20MHz) so if your clock is faster then your design just won’t meet timing. Using a global signal to distribute the reset sounds good but again this global signal will not be that fast and still you have the path from the flip-flops as well as to them to consider. Once again the net effect is a rather slow design. Finally the idea of stopping the clock is valid providing it is possible to stop the clock. DCM, DLL and PLL are all about locking to free running clocks. If your design doesn’t use these clocking components then you would be able to stop your clock but that again means that your application has relatively slow communication requirements on the I/O pins.

In summary, if a design is low frequency like most were in the olds days then you can probably get away with using global asynchronous resets. In a modern design you almost certainly need to apply modern design techniques. It is just a pity that ther are so many old examples of coding out there that continue to see the younger engineers learning bad habits today.

Good luck getting your design to work reliably and for sharing your misfortune with others. I really hope it helps to motivate more readers to take this fundamental issue seriously and change their ways.

Regards,

Ken

Re: That Dangerous Asynchronous Reset!

jnm — Tue, 28 Jul 2009 14:28:43 GMT

The STARTUP_SPARTAN3E primitive appears to allows the global reset to be synchonized to a clock.

If a design uses a single clock, then this primitive can be used to sync the global reset to that clock.

My FAE tells me Xilinx told them that this is an acceptable way to address the problem in WP272.

Do you agree?

I also understand that if you have control over the clock, then it would be acceptable to stop/gate the clock,

assert the async reset, then start/ungate the clock. Can you comment on this approach?

Could I use the DCM CLKFX in combination with a BUFG_MUX primitive to implement such an approach for each clock in my design?

Re: That Dangerous Asynchronous Reset!

jnm — Tue, 28 Jul 2009 14:23:08 GMT

I've been told by FAEs that including in the UCF

ENABLE = reg_sr_q;

ENABLE = reg_sr_r;

ENABLE = reg_sr_o;

will not only report violations of async reset use,

but will be used by ISE for timing driven placement and routing.

I've been told this has solved this problem for other customer.

Is this true?

Does ISE actually figure out the clock period and ensure that all FFs are reset in the same clock period without having to actually synchronize the reset to the clock?

Re: That Dangerous Asynchronous Reset!

jnm — Tue, 28 Jul 2009 13:57:39 GMT

I have a design (xc3s1600e-4fg320) with an async reset that is IP which has been implemented successfully by several people. In my implementation the design is operating properly and passes board-level diagnostics. However, the default value for several status registers does not match the value designed. Sometimes following reset a value is correct, other times it is not. It appears this is a problem addressed by WP272. I've implemented the circuit that synchronizes the reset to the clock - see below - and now the design fails board-level diagnostics. All timing constraints were met. What could cause this problem?

A 20MHz clock (ref_clk) from an external oscillator is brought into a DCM and multiplied to 40MHz (cpu_clk).

rst_async_n is the external async reset. It will pulse low for 300ms, then 300ms will pass before access to the part begins.

DCM cpu_clk_dcm (
.CLKIN(ref_clk), // 20 MHz
.CLKFB(), // use CLK0 or CLK2X
.DSSEN(1'b0),
.PSINCDEC(1'b0), // unused - no phase shift
.PSEN(1'b0), // disable phase shift enable
.PSCLK(1'b0), // no phase shift clock
.RST(!rst_async_n), //
.CLK0(), // freq = clkin, can drive clkfb for DLL ops
.CLK90(), // freq = clkin, phase shifted 90
.CLK180(), // freq = clkin, phase shifted 180
.CLK270(), // freq = clkin, phase shifted 270
.CLK2X(), // can drive clkfb for DLL ops
.CLK2X180(), // freq = clk2x, phase shifted 180
.CLKDV(), // clkin/clkdv_divide
.CLKFX(cpu_clk), // clkin*clkfx_multiply/clkfx_divide, 40_MHz - set in ucf
.CLKFX180(),
.PSDONE(), // unused - no phase shift
.STATUS(),
.LOCKED(cpu_clk_locked)
);

always @(posedge cpu_clk or negedge rst_async_n) begin
if (!rst_async_n) begin
    cpu_rst_n <= 1'b0;
    cpu_pre_rst_n <= 1'b0;
end else begin
    cpu_rst_n <= cpu_pre_rst_n;
    cpu_pre_rst_n <= 1'b0; //cpu_clk_locked;
end
end

Also, it is clear that the sync'd reset must be distributed faster than a clock period of the clock,

so a MAXDELAY constraint is needed. The best I can tell this delay must be PERIOD - JITTER_BUDGET - CLK_TO_OUT_DELAY - FF_SETUP. If this is a common technique necessary for building reliable designs, why isn't there a Xilinx document that describes the necessary implementation details (i.e. MAXDELAY).

Re: That Dangerous Asynchronous Reset!

kcmman — Mon, 13 Jul 2009 10:52:51 GMT

Synchronising the switching of an asynchronous reset to the clock is effectively a way to make the global reset synchronous even when using asynchronous reset inputs to flip-flops. However, to do so requires that everything is clocked by the same clock source (again something I advocate but just isn’t possible in all cases and why we have to provide multiple DCMs and clock buffers in our devices).

It also requires that the synchronised reset signal can be distributed globally within a single clock period to meet set up and hold times at all the loads. This is possible when the clock rate is slow enough but it rarely is! The DLL (the heart of a DCM and similar to a PLL) was introduced into Xilinx FPGA’s many years ago simply because it was not possible to distribute a clock globally fast enough. So the same applies to any global signal. The issue is that a reset signal is not repetitive like a clock and therefore can not be predicted in the same way that a DLL exploits.

Ultimately, you are correct but only if you are using a single slow clock. Since a Xilinx flip-flop can be synchronously or asynchronously reset there is no real saving (the transistors are there already).

Re: That Dangerous Asynchronous Reset!

billhunter — Mon, 06 Jul 2009 14:44:37 GMT

Ken, The primary reason I have seen the global async reset used is It also allows the user to reset the part without having to reprogram the whole part, and to get the simulation to work as you noted.

There are many problems you pointed out that can arrise, but if you address each of them then can't the asynchronous reset be far more efficient than coding a synchronous reset?

If you coded the design such that the async reset uses the global reset resource, and synchronize the global reset to your primary clock, then is your primary clock safe? If the secondary DCMs are reset by the same asynch reset, and also the lock signal from the first DCM, and then if you gate these clocks with thier own lock signals, are they not also safe?

Re: Power to the PCB!

austin.lesea — Mon, 22 Jun 2009 15:11:42 GMT

tj,

I get excited very easily.

No, no, no! Do not be sorry to have asked the question! It is a good question. We changed completely our methods, and our recommendations. It is a huge change. Did we supply all the deatils? No we did not. Did we publish a thorough technical paper on why? Nope.

If I appeared "annoyed" it was probably a lack of coffee in the morning, or something else.

I can be wrong (I have been wrong), and I will be wrong again in the future. Sometimes it is also difficult to explain something without tipping off our competition on how to do the same thing.

I have heard the competition sometimes when challenged by a Xilinx new feature say "oh, we do that too" even when they do not (and don't have a clue). Now that is annoying.

Of course, they will do that regardless, so I shouldn't be afraid to "tell all."

And, as I said, this new bypass method has worked (is working) and that is the best indication that we did the right thing.

I do understand that we have done something pretty radical, and there will be many who don't quite believe it.

For a complete technical explanation, you would need to make a request through your Xilinx FAE. It would be good for them (too) as they would have to get the full technical details (which are not in a form that can be presented today) refined, reviewed, and turned into a customer presentation. Then a technical expert would have to present it. After all, that is their job.

Again, don't ever be sorry you asked anything of me, it is part of my job to answer customer questions. I get pretty passionate about E&M theory, as it is so poorly understood (and it was my undergraduate major). I have fought for 11 years to get people here to use E&M CAD tools to do everything from package design, to pcb analysis. I am winning (and as a consequence so are our customers).

Austin

Re: Power to the PCB!

tjnash — Fri, 19 Jun 2009 21:51:50 GMT

Austin,

I appear to have really pressed your buttons. A desire to understand is not necessarily an expression of doubt. I'm sorry I asked the question.

Re: Power to the PCB!

austin.lesea — Fri, 19 Jun 2009 20:40:15 GMT

tj,

Well. If you want the right answer, use a field solver. ALL documentation prior to the change in the decoupling recommendations becomes obsolete. So just because we say somewhere that something is a good method, that is not true once we find a better method. We try to go back and update all documentation, but this is just the sort of thing we try to do, and will probably never completely find, or fix.

Is this perfect? Probably not. Is this a soultion that everyone can use? We think so. The constaints of the building a pcb to do what is required so constrains the problem that it is virtually impossible to do anything that is not covered by this recommendation (we believe based on the work done). The complaints from the hotline bear this out: after this was published, cases on the subject plummeted to nearly zero. What other measure would you believe in? I like to think that "the customer is always right" and if the customer isn't happy, then we have room to improve.

So, you are free to doubt us.

I would ask you, why would we make the claim if we didn't feel that we had sufficient engineering experience and facts to back it up?

It isn't like this recommendation doesn't matter: it makes, or breaks EVERY pcb that gets made!

Austin

Re: Power to the PCB!

tjnash — Fri, 19 Jun 2009 20:25:31 GMT

Austin,

Thanks for your reply. I really enjoy using Xilinx products, as they are clearly well designed and supported. I do my best to fully understand the parts and the overall system I'm trying to develop. With that said, though, I'm a bit confused by your response:

While I agree that the only way to know FOR SURE how a PDN will behave is via Maxwell's equations utilizing a 3D field-solver, I wouldn't go so far as to say that the method I described was a "best guess" or even based on a rule of thumb, nor would I imply that Xilinx no longer uses or promotes what you describe as "best guesses". This quote comes right out of UG203:

"Basic lumped RLC simulation is one of the simplest simulation methods, and though it does not account for the distributed behavior of a PDS, it is a useful tool for selecting and erifying combinations of decoupling capacitor values. Lumped RLC simulation is performed either in a version of SPICE or other circuit imulator, or by using a mathematical tool like MathCAD or Microsoft Excel. Istvan Novak publishes a free Excel spreadsheet for lumped RLC simulation (among other useful tools or PDS simulation) on his website: http://home.att.net/~istvan.novak/tools/Bypass_sweep_6v0.xls"

(The app note continues to list alternative methods including many of the available field solvers)

My simulation goes a step further than that which I quoted. It includes many of the additional (albiet, lumped) parasitics described throughout the app note (i.e. spreading inductance based on plane geometry, via models, interplane capacitance, etc...). So, while I'd love to have a 3D field solver at my fingertips, I would hardly call what I am doing a "best guess".

Secondly, none of this really addresses my basic question - Is what Xilinx provides in UG203 sufficient for me to claim that I don't need to do any further analysis, whether it be on the back of an envelope or via a 3D field solver? What I am hung up on is that I can't see how Xilinx can claim that they have completed all of the necessary PDN analysis for the customer (implied by the statement "...it benefits us to spend the time, and money, to get the right answer..."), when the response is not just a function of the decoupling caps chosen, but also their interaction with a board makeup that Xilinx didn't develop. While I agree that the app note goes into the notion that you need to keep loop inductances small (WRT cap breakouts), manage interplane capacitance, etc..., it doesn't give the user any sort of concrete limits as to how much interplane capacitance is truely needed or how much inductance is too much to keep from breaking the PDN, etc.... I'm not saying that it SHOULD provide this information - just that it doesn't. So, while Xilinx has gone a long way towards attaining the right answer, I'm not sure that you can safely claim that you HAVE the right answer, since you only control PART of the overall power distribution network.

Re: Power to the PCB!

austin.lesea — Thu, 18 Jun 2009 14:21:10 GMT

Tjnash,

These recommendations were confirmed by use of E&M CAD tools (basically, solve's Maxwell's equations -- no estimates) and then we built a series of boards to prove that physics' is what it is'.

Not surprisingly, everything else is just a series of estimations, and often guesses.

Even Ohm's Law is a (huge) simplification of Maxwell's Equations. Of course, if I am faced with a voltage drop, and a current, I am not going to reach for my EMI/RFI CAD tool: if the "problem" in DC, the Ohm's Law is fine. But if the "problem" is a complex issue of currents, and voltages, from thousands of nodes which all interact with the fields and waves, then the right tool for the job just might give you a surprising, and correct, answer.

So: solving for the electromagnetic fields using Maxwell's equations, along with then building the structure, demonstrates the guidelines are adequate, if not still a bit of overkill. As for anyone's "rules of thumb" or methods, they are fine if you need an answer. But, if you wish to get the right answer, you need the right tools. As we make FPGAs for a huge number of customers, it benefits us to spend the time, and money, to get the right answer, and not some "rule of thumb" best guess.

Previous to this study, we used (and promoted) the "best guesses" just like everyone else. We one day realized that we were asking customers to provide too much bypassing (and still having problems), and a great cost savings could be attained if we took the time to analyse just what was going on.

Re: Power to the PCB!

tjnash — Wed, 17 Jun 2009 23:05:14 GMT

I've tried to simulate the effects of the recommended decoupling scheme and I must be missing something, because the recommended decoupling, at first glance, appears insufficient. Using the "Larry Smith" method of analysis (same method that XAPP623 and subsequently UG203 appears to follow), if I assume a dynamic current need for VCCINT of ~2.5 amps (from Xilinx's power estimation spreadsheet) and a tolerable ripple voltage of 5%, this would mean I could have a Zmax of 50 mV / 2.5 A = 20 mOhms. If I then include the parasitics of the recommended capacitors, as well as the noted device substrate capacitors (and their parasitics), and include ideal but realistic values for plane spreading inductance and capacitance, my PDN doesn't appear effective beyond ~15 - 25 MHz.

Am I missing something (i.e. additional capacitance in the die substrate), or are we to assume that we don't need to analyze the decoupling of the device assuming we follow the app note's recommended capacitor values?

Note: I even looked up the approximate value of ESL for the 8-terminal ceramic X7S caps used on the substrate (~100 pH), as Xilinx doesn't provide that value in the app note.

Re: Reducing BRAM Power Consumption

kcmman — Thu, 14 May 2009 16:24:21 GMT

Yes, the memory keeps its contents. Only turning off the power supply or reconfiguring the device will change it (except for the write you want to do of course).

Ken

Re: Reducing BRAM Power Consumption

oschuppe — Thu, 14 May 2009 15:47:03 GMT

Hi!

Really interesting article!
Just to be on the safe side: the BRAM does consume less power if not enabled but it still keeps its content?! (I know, if it wouldn't, there's no sense to connect the write_enable signal to the enable port of the BRAM...)

Thank you!

The ‘Programmable Imperative’

austin.lesea — Fri, 08 May 2009 22:31:14 GMT

What are we talking about? Is this something new? Or is this something that has been around for 25 years, and has suddenly become more important?