element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Autodesk EAGLE
  • Products
  • More
Autodesk EAGLE
EAGLE User Support (English) freeDFM & via issue
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Autodesk EAGLE to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 19 replies
  • Subscribers 177 subscribers
  • Views 1595 views
  • Users 0 members are here
Related

freeDFM & via issue

autodeskguest
autodeskguest over 17 years ago

I have a board I've submitted to freeDFM. Their error report for that board

is at:

.   https://www.freedfm.com/freedfm/0011385401921358/results/summary2.htm

The .brd file (only that file) I've made available at:

.   http://www.RGMEusa.com/Misc/USBto64RW.zip

 

I've already addressed all the issues not related to vias in another board

version, my only remaining problem is the one concerning freeDFM's complaint

about every one of the board vias.

 

If you look at the freeDFM error report it appears to my eye that all the

vias have no drill and they appear to all be filled in as if they were pads

instead of vias going through all 4 layers. I've also made available a

screen shot combination picture of the board concerning just one of the via

issues (the X=0.7641", Y=2.2966" example):

.   http://www.RGMEusa.com/Misc/SampleVia.jpg

 

It all seems ok to me so I haven't a clue as to why freeDFM is complaining.

In the combo screen shot I see it reports a drill for the example via as

0.015" and a diameter of "0.031/0.031 (auto)". I don't understand the

diameter syntax being used, meaning it looks to me like it is reporting 2

parameters separated by a "/" character. What is the definition of the 2

parameters which in the screen shot are identical to each other? If one

parameter is mathematically divided by the other the result is a zero value;

is THAT the reason freeDFM is complaining?

 

I need help understanding the nature of the problem and how to fix it. I did

generate the Execellon file while the board was displayed in the editor,

that's what was sent to freeDFM. TIA!

-Ron

 

 

 

  • Sign in to reply
  • Cancel
Parents
  • autodeskguest
    autodeskguest over 17 years ago

    Ron wrote:

    Others said similar and John Giddy wrote:

    Ron,

    Even low speed logic circuitry can generate transient oscillations due to

    the fast rise time of common digital ICs. This fast rise time causes the

    power supply to "see" sharp changes in demand for power, giving quite

    large voltage transients due to circuit inductance. This can propagate to

    adjacent circuits. The bypass capacitor provides this transient power to

    prevent or at least greatly reduce the spike on the supply line. I think

    you are being too optimistic that all will be well, just because the

    prototype worked OK.

    If this is a production board, with many to be made, tolerances could well

    give you a reasonable proportion which cause problems. It is easier, and

    not very expensive to add bypass capacitors at the start.

    John G.

     

    I agree with everyone that bypass caps are good design practice and, as you

    say John, easier and cheaper to add at the start of a project than to have

    to implement the practice after a production run. As was also pointed out,

    power planes are also good design practice. I wish I could divulge the

    schematic so that my arguments about both being unnecessary in this

    particular design could more easily be examined, but I'm not at liberty to

    divulge it.

     

    The  UM245RUM245R USB module has 7 I/O pins programmed as latching outputs one pin

    as an input, and operates in self powered mode. It is only at the USB cable

    connection, part of the chip module itself, are there any repetitive signals

    that even approach a frequency that might cause unwanted parasitic

    oscillations of any resonance. Everywhere else on the board the signals are

    latched.

     

    Logic level changes that, for whatever reason, would tend to start an

    oscillation quickly get swamped by the fact that the circuits are latched

    and continually refreshed (at a chips settling time rate, very fast) as a

    state machine rather than being sampled in reoccurring clocked time states.

    State machines, unlike clocked machines, inherently suppress oscillations

    and that's an important design fact. Just because signal patterns do change

    doesn't mean all patterns are going to induce transient oscillations

    (resonance) and that's because only one bit pattern state might have such a

    tendency in a particular board location. In this design any one physical

    location only has 1 chance in 128 of instigating a parasitic oscillation

    but, even if the tendency exists, the bit pattern isn't changing (it is

    latched) and so the resonance tank does not get pumped and so the tendency

    to oscillate is greatly attenuated to the point where oscillation is super

    unlikely. MUCH more so than in clocked circuits.

     

    Even if an oscillation started it will not affect the latched source

    signals and those latched signals from the  UM245RUM245R will quickly suppress any

    tendency to oscillate. This is the advantage of a state machine over a

    clocked machine; by their very nature oscillations are suppressed (thus

    greatly decreasing needs for bypass caps). Since only a changing output

    pattern from the  UM245RUM245R might tend to instigate an oscillation it is still

    a latched output that fights that tendency, it does not rely on "data valid"

    clocking that would have a MUCH higher tendency to oscillate (the clock

    itself getting spurious signals Yes I use one  UM245RUM245R output pin to

    establish a read or write condition to the rest of the circuitry, but it too

    is latched and not clocked. It wouldn't hurt to add the bypass caps, but in

    this design they would be redundant and an unnecessary expense because the

    bottom line is that latching suppresses oscillations.

     

    Not having power planes isn't really what I wanted. The bigger the power

    trace then the less voltage drop will appear across it, and anywhere there

    is a voltage drop there is also a potential avenue into oscillations. But I

    have too many connection points, I would need to have more than 4 layers if

    I use power planes. So I compromised by using huge power traces and keeping

    them all to the bottom layer (I route them first). 6mil distance for power

    traces is bad, I need to pick a distance value that is not a harmonic length

    of chip settling time, even in a latching circuit. I forgot to do that when

    I created the class in Eagle but it will be in the final routing.

     

    I have chosen not to implement the additional safety of adding bypass caps

    because in a 100% latching based circuit the need is redundant, it would

    require around 100 more drills and the project surely would then be

    unroutable in just 4 layers. The same reasoning went into my decision not to

    use power planes in this particular design, I simply could not route for 4

    layers at the needed board size even if I included just a ground plane only.

    Too many connection points. I don't like the compromises at all, but the

    effect of those 2 decisions in this particular case is so near to being a

    zero impact as to be considered very tolerable.

    -Ron

     

     

    Good luck...

    John G.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • autodeskguest
    autodeskguest over 17 years ago

    Ron wrote:

    Others said similar and John Giddy wrote:

    Ron,

    Even low speed logic circuitry can generate transient oscillations due to

    the fast rise time of common digital ICs. This fast rise time causes the

    power supply to "see" sharp changes in demand for power, giving quite

    large voltage transients due to circuit inductance. This can propagate to

    adjacent circuits. The bypass capacitor provides this transient power to

    prevent or at least greatly reduce the spike on the supply line. I think

    you are being too optimistic that all will be well, just because the

    prototype worked OK.

    If this is a production board, with many to be made, tolerances could well

    give you a reasonable proportion which cause problems. It is easier, and

    not very expensive to add bypass capacitors at the start.

    John G.

     

    I agree with everyone that bypass caps are good design practice and, as you

    say John, easier and cheaper to add at the start of a project than to have

    to implement the practice after a production run. As was also pointed out,

    power planes are also good design practice. I wish I could divulge the

    schematic so that my arguments about both being unnecessary in this

    particular design could more easily be examined, but I'm not at liberty to

    divulge it.

     

    The  UM245RUM245R USB module has 7 I/O pins programmed as latching outputs one pin

    as an input, and operates in self powered mode. It is only at the USB cable

    connection, part of the chip module itself, are there any repetitive signals

    that even approach a frequency that might cause unwanted parasitic

    oscillations of any resonance. Everywhere else on the board the signals are

    latched.

     

    Logic level changes that, for whatever reason, would tend to start an

    oscillation quickly get swamped by the fact that the circuits are latched

    and continually refreshed (at a chips settling time rate, very fast) as a

    state machine rather than being sampled in reoccurring clocked time states.

    State machines, unlike clocked machines, inherently suppress oscillations

    and that's an important design fact. Just because signal patterns do change

    doesn't mean all patterns are going to induce transient oscillations

    (resonance) and that's because only one bit pattern state might have such a

    tendency in a particular board location. In this design any one physical

    location only has 1 chance in 128 of instigating a parasitic oscillation

    but, even if the tendency exists, the bit pattern isn't changing (it is

    latched) and so the resonance tank does not get pumped and so the tendency

    to oscillate is greatly attenuated to the point where oscillation is super

    unlikely. MUCH more so than in clocked circuits.

     

    Even if an oscillation started it will not affect the latched source

    signals and those latched signals from the  UM245RUM245R will quickly suppress any

    tendency to oscillate. This is the advantage of a state machine over a

    clocked machine; by their very nature oscillations are suppressed (thus

    greatly decreasing needs for bypass caps). Since only a changing output

    pattern from the  UM245RUM245R might tend to instigate an oscillation it is still

    a latched output that fights that tendency, it does not rely on "data valid"

    clocking that would have a MUCH higher tendency to oscillate (the clock

    itself getting spurious signals Yes I use one  UM245RUM245R output pin to

    establish a read or write condition to the rest of the circuitry, but it too

    is latched and not clocked. It wouldn't hurt to add the bypass caps, but in

    this design they would be redundant and an unnecessary expense because the

    bottom line is that latching suppresses oscillations.

     

    Not having power planes isn't really what I wanted. The bigger the power

    trace then the less voltage drop will appear across it, and anywhere there

    is a voltage drop there is also a potential avenue into oscillations. But I

    have too many connection points, I would need to have more than 4 layers if

    I use power planes. So I compromised by using huge power traces and keeping

    them all to the bottom layer (I route them first). 6mil distance for power

    traces is bad, I need to pick a distance value that is not a harmonic length

    of chip settling time, even in a latching circuit. I forgot to do that when

    I created the class in Eagle but it will be in the final routing.

     

    I have chosen not to implement the additional safety of adding bypass caps

    because in a 100% latching based circuit the need is redundant, it would

    require around 100 more drills and the project surely would then be

    unroutable in just 4 layers. The same reasoning went into my decision not to

    use power planes in this particular design, I simply could not route for 4

    layers at the needed board size even if I included just a ground plane only.

    Too many connection points. I don't like the compromises at all, but the

    effect of those 2 decisions in this particular case is so near to being a

    zero impact as to be considered very tolerable.

    -Ron

     

     

    Good luck...

    John G.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube