HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Comments
You must login to participate in this chat. Please login.

First Time Right:  our designs always turn out better when bouncing ideas off of each other and not just using our first design... come up with improvements in design over a week or two.

Iron

Looking for good principles to apply to my own code in our projects

Iron

From Utah, Embedded Software Engineer

Iron

Thank you Gary and Alex

Great discussion about practises and principles.

1st time right for one person could be a second or third time right for other guy or vice versa

1st time right is very broad. It does mislead in the way that all people are not perfect from the beginning (teams are always updated with new members and their level of rightness is not equal).

Principle: Do what you say, say what you do. verify! next step!

Looking for more practical approaches to deal with issues at HW/SW/FW

Worked on the product that had some EOL component changes right after product release

Hello from Oregon, looking forward to learn more

Tough one, most of the designs I have worked on have worked the first time but all were fully functional before release to manufacturing.  Most were related to communications issues between software and hardware.

Iron

embeddded control systems

Iron

Remember an engineer sitting in a shipping crate making last minute modifcations on a protype system before they put the top on the crate.

Iron

Worked simlar issues when working with drive interfaces for optical and magnetic drives.

 

Iron

Hardware engineer, Manager - Project Manager

Iron

I have been able to get designs right "first time" -- never changed after release to production -- no bugs found -- more than a decade of use. It can be done -- those projects had thousands of circuits.

Iron

Great Class. Information was very well presented

Iron

See you tommorrowwwww

Thanks For the lecture

I just finished the audio

and notice the chat is still active

 

@LevitonDave - Most of the time the hw team is tasked with designing the interface because it is very hw-centric. But this is where it is important that sw/fw also be involved to make sure it works for them. We'll discuss this more tomorrow.

Iron

@LevitonDave - If the problem is clearly on the hw or the sw side, then assign it to that team. If it is unclear, then both should work on it. It may be assigned to one side or the other, depending on who has the best chance to solve it, but the other side would be obligated to assist.

Iron

@LevitonDave - My time in the HP LaserJet lab was in Boise, ID. I'm still in Boise. Earlier I was in Fort Collins, CO.

Iron

@luizcosta - Most of my work was with LunxOS and its driver have some differences from Linux and XINU. So I am not aware of good tutorials for you.

Iron

@RMRSS - Sorry, I don't have direct experience with JTAG. In most of my experience, JTAG was not available for us.

Iron

@williambreit - Determining which is more profitable between first time right and finish it now depends on where you are measuring your profits. If management is looking at maximizing this quarter's profits, then finish it now is the mantra. But when you look long term, first time right is much more profitable. If you want more specifics, send me an email.

Iron

Thanks for the lecture!

 

Iron

@LevitonDave - Getting management to buy into these concepts takes time. Some of the stuff I did anyway without management approval or knowing about it but it eventually became part of the process when they saw the benefits. If you want to talk specifics, send me an email.

Iron

Thanks a bunch, Gary and all of you.

Iron

@LevitonDave - I never was good at all those product-line numberings. That was stuff that marketing and upper managers dealt with. What was PL-13?

Iron

@GeoSei - Same book. See my previous post.

Iron

@pabobko - You can find all 300 best practices in my book, "Hardware/Firmware Interface Design". See www.garystringham.com/book for more info and links to Amazon and elsewhere.

Iron

@luizcosta - At HP we had to use an old ASIC as a workaround to a new ASIC the third-party supplier could not get working. I have seen FPGAs used for workarounds. So it does happen, but only if it can't be fixed in SW.

Iron

@BobDJr - There is probably not much new in here than what I gave in Boston ESC because the principles are still the same. So a lot of the examples and illustrations will be similar. So this would be a good refresher course for you if you feel you need it.

Iron

Looking forward to tomorrow - Thanks Gary and Alex

Thanks Gary for clarification

Iron

@JoeWojcicki - Could you clarify your question? What do you mean by "signal/frequenct eace" in "Can you give a simplified 'tool or merhod' to solve 'signal / frequenct eace' between SW and HW?

Iron

The same woudl apply to desing and interface requirements

@GStringham - Is there value in team ownership of all issues until they can be isolated to one area? In other words - until we can find the problem the entier team owns it. 

Thank you  Gary and Alex

Iron

@raghu - My reference to bank loan employees is to say that my principles also apply to areas outside of embedded systems development, that it can even apply to employees working on loan applications at a bank.

Iron

@Henador - Benivelent dictatorship is the most efficient approach to organization for fast action (that's why the military uses it). But it relies on skill and wisdom at the top to be successful.

One of the books that I'm currently readiing is titled "Elements of User Interface Design" by Theo Mandel. Have you heard of it before?

 

Iron

@garysxt - Was your "both HW and SW is guilty until proven innocent" by design or the way everybody angrily thought? It is a good way to go in that both side have the burden of proof, rather than, as someone else said, wait to see if they fix it first.

Iron
Thanks. I know what an ASIC is usually assigned to do. My question was a sequel of Gary's point about an ASIC block problem that they had to "WORK AROUND."
Iron

Gary - HP Vancouver? if so are you still enjoying the rainy weather today?

Thank you, Gary, for bringing up best practices, standards and principles. I know companies that have rocketed to the forefront by setting up top down management and design.

Iron

Gary: Please, point me to a "driver programming tutorial" that add a /dev/xxxdriver to Linux or XINU. The simpler the hardware the better.

Iron

Better late than never

Finally got connected

 

@cnorton - And I see others with the same sentiment, that engineering is more fun.

Iron

Gary, your presentations have been very pragmatic and clearly presented. Great stuff!

 

Iron

Leviton, I know of companies that are so hung up in doing it their own way that it took a massive failure out in the field for the management team to get punished so severely that upper management had to face the customer and do what he said. It resulted in a top down restructuring of the company along with Six Sigma and Kaizen training for the company to get back into the good graces of the customer. It cost the company about 9 months of profits.

Iron

Excellent mix of hw and fw/sw attendees. Glad to see that.

Iron

Thanks so much to you both, I can't wait for the next round of classes.

Iron

At HP Spokane we had a saying " Standard is better than better" while this may limit the fun of I can do it better, it did keep issues to the primary area of expertise.

Any thoughts on JTAG abd how to better use it and its use w.r.t. code and emulators.

Iron

Thanks Gary for the informative lecture.  It was very interesting.  

 

Iron

Is your approach (FTR) more profitable than meet the schedule ( Finish it now)?

@JCheetham - I agree; engineering is more fun. :-)

Iron

@JSP - I have not developed my own "version" per say of collaboration and standards. There are enough out there already. My principles will apply no matter what standards are used. And best practices must be analyzed to ensure correct application.

Iron

LUIZCOSTA, ASICs are part of the design and usually implement functions that are very time sensitive or involve too much functionality for existing ICs such as micros.  Sometimes ASICs are used to protect IP as they are harder to reverse engineer. An example of a function that typically goes into ASIC is a real time DSP function such as a multiplier/accumulator that implements a Finite Impulse Response filter.  ASICs can produce a result every clock cycle, whereas micros take many execution cycles to produce the final outcome.

Iron

Any recomendations on how to get management to buy into adopting principles like this in existing schedule driven design processes?

 

Thanks Gary and Alex.  very interesting.

Iron

Thanks Gary (from an old PL-13 employee :)

See ya tomorrow Alex.

Iron

Gary,

Are there any books which you recommend for help in bridging the gap between hardware and software interface design issues?

TIA

Iron

Thanks Gary, Alex & Digi-Key!

See you tomorrow.

Iron

Can we see the list of 300 best practices that Gary came up with?

 

Iron

Thank you for today's lecture Gary, Alex and Digikey

Iron

Thanks Gary! great presentation.

Iron

Managers may want to ship before done, marketers want to ship as soon as they see the prototype light up!

Iron

@luizcosta - ASICs are an expensive proposition for a solution.

Iron

I am a registered patent agent, and the First Time Right principles also applies to patent practice, wherein First Time Right means allowance on First Action from the USPTO.

Iron

Do people in a company such as Apple or HP add ASICs as work around for some portion of an expensive chip that doesn't work?

Iron

@Alex – Typically, managers are very schedule-centric.  A manager often will ship before the product is completely baked.

Iron

reloading the page did not help, had to open new explorer.

Iron

F5 worked, but I still have to bail. And the buffering is glitching repeatedly. We need to apply some "principles" here, apparently. Tomorrow, guys! Thanks for the lead-in, Gary!

Platinum

I agree. I'm designing a digital filter whose interface to the computer is exceedingly difficult, because it's designed to a computer back in the 1980s. Today's computers are much faster, so SW has to design loops to slow down its interface, not knowing that the filter can run much faster.  It has a 10 ns cycle time, whereas the SW guys are slowing it down to 1 ms! I've talked to them about it, and management said "Nope, keep it as is."

Iron

pause then replay

Iron

refreshing the explorer worked

Iron

re-logged.  audio came back

 

Pause then play. sound will start

Iron

@Alex and everyone else - F5 REFRESH.  Audio will come back.

Iron

To all:  hitting F5 sometimes brings back the audio...

 

Iron

Today all the time I had audio problem.

Iron

Refresh of this page brought audio back for me.

 

Iron

Hardware or Software problem?

Iron

the DesignNews Radio bar shows BUFFERING

Slide 11, point 6 ?

Iron

Audio is back - servers buffered for a little while.

I see "buffering" and 29:04 on my widget

Gold

player says "buffering"...

Iron

Audio came back after refreshing the page

audio is good for me.

Iron

lost audio.  reloaded page.  still "buffering"

 

must be an escaping defect

Iron

The funny thing is that awsome tech developpers such as Steve Jobs, they want three things: First Time Right, Doit Now, Do it Within Budget.

Iron

yup.  audion is gone.

Iron

also no audio

 

Iron

can u hear us now

 

Blogger

"interface problem"

Iron

audio is gone...

 

Iron

we lost you Alex!!!

No sound.

Iron

Audio lost here.  Are we still connect Alex?

Iron

Alex, lost you at "pushback" you cut out

 

Iron

audio is gone...

Iron

Often sought very seldom achieved.  This is why reuse of proven code and hardware is often used.  WHile good at one level for a perfect first build in may be bad for better designs overall.

Iron

I hate working on the prototype they've pressed into production !

C'mon it's just a few bucks, do it properly for goodness sake.

 

Iron

a hardware house has no understanding of software design and complexity and does make a lot of assumptions (collaboration is a good thing)

Iron

Too often schedules are pulled in and management just decrees it will be right the first time

Just Get it Done; Has always been the mantra.

 

Iron

FTR: not realistic in must cases I've encountered. Regardless of how much effort was put forth up front there is always an aspect that is missed.

getting it right the very first time.. how often dose it really happen?

Iron

Be user friendly.

Iron

I think it's much better to plan for a disposable protype in the project schedule.  It will produce a better product, with lower blood pressure on everyone's part.

Iron

Prefer to target First Time Usable.

Silver

First Time Right on Time

Iron

it's typical that you don't have time to do it right the first time, but you have time to fix it later on, although it costs a whole lot more

Iron

ha. lip service perhaps, but it is not ignored

Iron

First time right - scheduled as reality but implemented in Lip service only.

Proper Planning and Preparation Prevents P*** Poor Performance.   :)

Build in "hooks" to make use of idle resources.

If you have the ability to change the configuration, unused "configuration spaces" let you use all of the primary-configuration's resources in often-unanticipated ways.

Become familiar with concepts like "configuration space", "input/output space", etc, similar in context to "time domain" versus "frequency domain".

Need to allocate some time for sitting there, with your feet up, thinking -- can't "invent" on demand, so set things up so you HAVE some quality "AhHAH!" opportunities.

Platinum

Never heard of First Time Right as a mantra

Iron

First Time Right: insist in investing tones of time planning and producing detailed documentation. It will closer to that goal.

Iron

lip service, but that's life.

Gold

First time right: lip service.

Iron

@Alex - hell yes (reality)

Iron

lipservice.  Totally.

 

Iron

I had to laugh when one day I received a "we have the time and staff to do things right the first time" then the next day found out that the same group did a poor cooling design that caused our whole system to shutdown!

Iron

We've tried to design leading-edge complex ASIC first-time-right, or at least first-time-shippable.  I guess if you don't swing for the fence, you'll never hit a home run.  But we've rarely succeeded.

Iron

as "right" as possible should always be the target! but reality says there will be mistakes, unknowns and there will be design changes...

Iron

yep: "Do it right the first time" policy...

 

Iron

FTR = Pay attention to detail

Another principle: Foreseeable misuses of the product.

Iron

@raghu - seems like... (we are talking about 6 sigma principles without naming them so...)

Iron

Yes, very important to understand what needs to be done.. and then comes how to do

Iron

@Alex – Concerning your interest in interfacing practices outside the circuit board, I found that performing the job of company/project liaison with a contracted software/firmware house to be a good example.  If I didn't put forth the effort and stay on top of everything going on, things got "hosed up" pretty quickly.

Iron

are we talking about 6 sigma?

Iron

Principal: Determine fully WHAT the system is to do before starting to design HOW it's to be done.

Silver

Know your customer and don't just include something because you can.  They may not care about those features.

Iron

Big fan of peer review.

Iron

DFM, Design for Manufacturability

Iron

Test early and often.

Iron

Principal: Assume you did something wrong in the design and work hard to test and prove to yourself that you didn't!

 

Iron

The first fault is necessarily the ONLY fault.

Iron

bank loan employees?

 

Iron

Design for testability

Iron

WHEN ALL ELSE FAILS, I THINK OUTSIDE THE BOX (HOW THINGS SHOULD WORK)

JP Morgan is still working on #5! (Anticipate the Impacts)

Iron

Interest in Interface Design: I want simply to know how to write a C driver code bvased on a simple interface such as a RS232, integrated to XINU or Linux.

Iron

I am working on debugging the embeded system.Some times we cann't test the software unless hardware is fixed.

Iron

Individual contributor, not managing but often project lead

The best practices might have worked, but there wasn't time to digest it before we had to ship the embedded system.

Iron

I don't have any specific items I want to learn this series. Just hope to come away with one or two new ideas.

Iron

Yes, happens all the time

Iron

Primarily s/w developer but more h/w related as mobiel etc. get more in the mix. Looking for general method improvments.

Iron

Forcing best practices:  no, not really.

Iron

Hi

I am trying to learn to develop embedded hardware/software interfaces for simple medical applications.

Thanks.

AJ

Iron

I design MCU based Motor controller boards for water pump

Iron

sw guy working on hw/sw project.

Iron

My interest in this presentation is to learn more about the line between hardware and software for use in FPGA SoC designs.  How to make the hardware easier or more efficient to program and how to define which parts to place in hardware and which parts to put in software. 

Iron

I'm an integrator dealing mostly with PLCs and operator interfaces. I am looking for a broader background.

better interface design for medical device design

 

Iron

Job - Hardware Engineer including PCB layout for 25 years.

Not to learn anything specific, just to see if there is anything i can learn.

Iron

2 attendees - Engineering Manager and HW/SW Engineer.  We are ostly interested in User Interface design considerations balancing with other important tasks ? Do we use DMA, things like that ? Using SPI interface. 

Iron

I'm Embedded systems designer. Do both HW and SW. Looking for better ways to interface.

Iron

I took a class like this that Gary taught at ESC Boston a couple of years ago, and want to see if he has any new information.

Gold

Re: Interface design?? You can't design a tool without having some idea HOW you can make it DO something.

Platinum

@bill.whitehead: While in a seperate browser window on www.blogtalkradio.com I clicked on the "...in progress" and could hear the person there before proceeding with the other steps I mentioned below.

Iron

@Alex: Job, as a Mech Eng, to bring hardware and software together in system design. Also digging into both hardware and software in my hobbies. Very interested in the synergy between these two areas.

 

Iron

SOFTWARE DEVELOPMENT AND SYSTEM DEBUGGING

Iron

@MazianLab.. Thanks.. All I am saying is people must have a practice to make a list of things that worked.. that way they can check em later..

Iron

application and driver software for data acquisition system

 

Iron

Looking to learn from Gary's experience.

Iron

Hi,

I'm in Hardware Development an ddoing som SW development right now

Iron

raghu! There are lots of debugging techniques in Archive that ware discussed before.

Iron

@krhohio:  I tried the same, but it is just stuck on "buffering...".  It doesn't look like a firewall issue, but I may be wrong.

@Alex – This week I'd like to see/hear about specifics.  HW interface solutions, test/development equipment used and not used.  Get down to components specifics, component specs and associated problems.

Iron

If you can't hear the audio, you might want to try Firefox.

Iron

Keep a list of debugging techniques that worked in a particular situation.

Iron

@bill.whitehead: I was not getting audio either - first checked that I could open www.blogtalkradio.com and then www.llnwd.net (LimeLight Networks) - both worked.  The did a <F5> (refresh) and it started working...

Iron

Interested in Gary's take on how to convince collaboration and standards prescription/enforcement. Slide 5.

Iron

Can you give a simplified "tool or merhod" to solve "signal / frequenct eace" between SW and HW?

I'd like to learn best practices for h/w-s/w interface design, with a view towards extensibility, clear documentation, and implementability.

Iron

Sorry, what slide please?

Iron

Had to design an additonal small circuit board that was retro-fitted into all units that were produced.

Iron

@Alex - what I'm looking to learn this week - maybe something new (that I don't know yet) or some new aspects of known things...

Iron

looking for general approach ideas - design, debug, usability, etc...

Iron

I'm interested in hearing about debugging tools/techniques used in interface Design

Iron

Yes the experience was big endian little endian.

 

Iron

best practices for solving interface design issues.

Blogger

Several times we've discovered an issue late in the development cycle -- not fun!

Iron

Interfacing to sensors and EM , remote controllers

embedded software engineer

Gold

in that case, the HW eng tells the SW eng, "yes it's HW, but it's too late to fix, you need to write a SW work-around.  By tomorrow.

Iron

Often able to build in "hooks" for test access?? I was lucky enough to have lots of indicator LEDs and configuration toggle-switches. Being able to build diagnostics into the device has been VERY productive.

Platinum

Interest this week: setting up the hardware/firmware relationship early on, properly, to be efficient.

 

Iron

Usualy do testing until the procuct ships.

Iron

Yes - and SW usually has to fix hardware issues late in the project.

Focus is to determine how to smoth out the touble-shooting process.

I am a Systems Engineering Manager who deals with interfaces weekly.

Iron

sorry for no audio here...What is bank loan employees again?

Iron

I'd like to learn more about hardware/software tradeoffs

Iron

Dealing w h/w issues in a nearly-ready-to-ship system?  Often!  We design in as much debuggability as possible...

Iron

Yes, I've had to deal with HW issues on buttoned up systems (manufacturing line, customer returns)

Yup, frantic bandaids at final testing with customer waiting !

Iron

Yes among major subsystems

Iron

Oh yeah - even deal with those issues AFTER production is underway!

Iron

yes. clocking issue

Iron

Wow... some amswers re. h/w vs. s/w look like CVs... ;)

Iron

Some times Hardware bug creates Software problem as well.

 

Iron

Systems engineer, inventor, test engineer

not following common conventions is a big problem.. others cannot understand our program and they cannot debug it..vice versa

Iron

Hardware, software (mainframe, mini, desktop, embedded - instrumentation, industrial controls, textile machinery, wood product machinery, medical device, product testing), machining, business analysis, 3D modelling, 3D printing (low end), development in virtual worlds.

Silver

Looking forward to this serries.

embedded, test engineer.

 

Iron

Been in many SW vs. HW finger pointing sessions. In groups I manage both HW and SW is guilty until proven innocent.

Iron

HW & SW.  Have managed projects before but not currently.  Engineering is more fun.

Iron

Mostly hardware, with firmware, and some software.

Not too many heated discussions, but a bit of "let's wait to see if they can fix it in Xxxxware first."

Iron

Those "heated discussions" were motivation for being able to software-ish exercising of hardware.

Platinum

High Alex Hi Gary!

Iron

Hardware, software, test

Iron

not very often heated, but many debates

Iron

always point fingers at each other, always blame each other, but then work together to troubleshoot, nothing hostile

Iron

Manager?  I haven't had my lobotomy yet.

Iron

Predominantly hardware, but more than enough software to make the hardware walk and talk, and debug if it DOESN'T do either... NOT a manager (even though that's typically the end-of-life-cycle for engineers).

 

Platinum

hw/sw/fw/everyware/everywhere/..

Iron

Primarily SW but both when needed.

... also a manager

Iron

Hardware, software and firmware

Iron

ME/Physics, no firm/SW. No apps presently. Manage HW design.

Iron

Firmware (w/influence on h/w design)

Iron

Engineers cannot be managed. They need to be herded like cats.

 

Iron

Was a manager.  Engineering is more fun.

Iron

Software and Hardware.

Iron

mostly software, but do some hardware.

Blogger

Avoid being a manager !

Iron

individual contributer

Iron

I program for firmware and PC. I also do the testing for our new hardware.

 

Iron

Both - primarily firmware

 

Iron

Primarily hardware engineer, but also firmware and software. 

Iron

Software, firmware and a little hw

Hardware and software

Iron

Both Hardware and Software

Iron

HW/SW development engineer

 

Iron

Both - h/w and s/w

Iron

@Gary - HW/SW/FW

Iron

hardware & software

Iron

Alex! Is this last week of the program?

Iron

Embedded software eng

Iron

software engineer

Iron

HW/SW development engineer

Iron

Good afternoon Gary.

 

Iron

Hi Gary.  Welcome to our forum.

Iron

Hello All, looking forward to today's lecture. 

Iron

Good to hear you again Alex.

Iron

i am just hearing locktalk radio!!?

Good afternoon Alex.

Iron

@Gary - is this prescription of collaboration and correct standards your own or distilled from others in the field ?

Iron

Should we be able to hear anything yet on our computer?

 

hi from south texas

 

Iron

Good afternoon folks

Iron

Hi from rainy NoVA.

Iron

Good afternoon everyone, from rainy New Jersey

Iron

Guess I could read through today's slide deck and get a feel for whether we're going to see "top-down" vs "bottom-up", or "holistic", "conceptual", etc. Hey, all! Everyone enjoy the "break"?

Let's see: currently unemployed (searching, available on short notice) recent/nontraditional BsEE with years of professional experience in MANY areas (telecommunications, industrial lasers, biomedical devices, satellite dish positioners, etc). No specific current projects (although I've got a few "percolating", as usual).

Platinum

hello from sunny MIAMI

Hi everyone, it's good to be back in "class."

Iron

Welcome to this class. I'm looking forward to presenting this subject which is something that I feel strongly will improve your development processes. If you have any questions, post them here and I will answer them after the lecture part is over.

Iron

I hope this starts its self in abour 35 mins.

Iron

Be sure to click 'Today's Slide Deck' under Special Educational Materials above right to download the PowerPoint for today's session.

Blogger

Please join our Digi-Key Continuing Education Center LinkedIn Group at http://linkd.in/yoNGeY

Blogger

The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

Blogger


Partner Zone
Latest Analysis
Watch BMW's newest electric car, the i3, being charged with an everyday Home Depot-rented, gas-powered generator.
Asking yourself the simple question, “Is this a strength problem or a stiffness problem?” can prevent many design mistakes.
New manufacturing is changing more than just the plant floor. It's changing how manufacturers do business.
Made By Monkeys highlights products that somehow slipped by the QC cops.
Venture capital guru Steve Vassallo looks for companies that think about design, not just technology for technology's sake.
More:Blogs|News
Design News Webinar Series
9/10/2014 11:00 a.m. California / 2:00 p.m. New York
7/23/2014 11:00 a.m. California / 2:00 p.m. New York
7/17/2014 11:00 a.m. California / 2:00 p.m. New York
6/25/2014 11:00 a.m. California / 2:00 p.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Sep 22 - 26, MCU Software Development – A Step-by-Step Guide (Using a Real Eval Board)
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.
Next Class: September 30 - October 2
Sponsored by Altera
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service