The flexibility of an FPGA’s capabilities makes it a very powerful tool. However, in order to fully utilize the device’s capabilities it is important to manage the FPGA project with expertize and properly identify the correct deployment methodology in each phase of the development life cycle.
Are you facing
disasters,
magic "contractor" work,
decision mistakes,
last minute surprises,
"no idea" assignments,
panic mode situations,
just make it work stage,
documentation that needs documentation,
overcommitment,
"will it ever meet timing" psychology?
Are you fighting mystery bugs,
pushing the FPGA limits?
Are you a small print victim?
Did you realize FPGA design is more than just RTL coding?
Are you rushing student thesis or billion dollar project?
Are you suffering from HELK (High ego Low knowledge) Managers?
CONSULT
CONNECT
COLLABORATE
<
Harness my management and technology capabilities with dedicated expertise in FPGA. Engage with me today and begin delivering results;
Hyper complex functionality but simple design
Ultra fast speed but easy on timing
Super strict process but ease of execution
Ridicilusly short schedule but on time delivery
Vast amount of options but highly predictable and repeateble results
Minimal stress but tremendous success
Minor effort but spacious product
Invincible competitiveness but preposterously low cost
CONSULT
CONNECT
COLLABORATE
<
Lack of
Knowledge
Plan / Process
Methodology / Discipline
leads to
Inconsistency
Ineficiency
Inability
engaging
Experience
Expertise
generates
Success
Quality
Competitiveness
Broad range of specialised skills. Any vendor, any tool, any industry...
Structure. Process. Systems. Strategy. Creativity. Quality FPGA product requires it all. And we have it in spades. We have developed tools and frameworks that establish a strong foundation for our clients’ FPGA projects, thereby producing greater revenues and a stronger brand.
We do FPGA, and we do exceptionally well. By focusing on FPGA, we have in-depth knowledge of FPGA and can contribute to meeting your specific business’ and technical objectives.
The FPGA Project Management tool is designed with FPGA specific activities in mind. Make FPGA project management easy and engaging by measuring progress, analyze resources and anticipating and directing FPGA specific activities.
Deliver FPGA projects successfully
The FGPA projects methods and procedures tool provides step by step procedures assuring the project manager does not miss any step or makes a wrong decision during the life cycle of the project. Our tool combines and consolidates all the aspects of a FPGA project management in to one place. All outputs of the project are structured, sorted and organized. Single point of interface for planning, scheduling, resource management, design, development, testing and storing.
Our well tested and improved methods guarantees any FPGA project is completed successfully. FPGA Project Managemenet Tool's visually rich and contextual interface will guide you through the project notifiyng and advicing you for the required actions on every stage of the project.
Be Efficient, Prioritize and Stay in Control
Project Planning, Reporting and Communication, Budgeting and Cost Control, Scheduling, Risk Management, Stakeholder Engagement and Regulatory Approvals, Design Management, Change Management, Monitoring, Project Acceptance and Turnover, Final Project Close Out aspects of projects are managed professionally with FPGA specific prioritasion.
Every component of an FPGA project is linked, syncronised, organizsed, combined, consoldidated, located and traceable to each other: Requirements, documents, RTL, builds, releases, changes, schedules, resources. And all these are done automatically for you by our FPGA management tool. the tool takes the manager through every step and ensures no step is forgotten going forward.
Process is your friend
No more forgotten actions, broken procedure, design mistakes, bad planning, no more asking what is the next step, no more worrying if a document or a review is missed or can be found. Spinning back and forth on an ineffective procedure
Step by step FPGA development from scratch to delivery
Guidelines and templates
Deliver like a PRO
All the what to do and how to do in atomic steps. You just execute!
Universal procedure
Automated document generation
Automated content management
Automated Traceability
<
When it comes to FPGA; specialization and expertise matters most. Whether starting a major project, trying to stay ahead of competition by delivering better product, or needing urgent short term highest level instant FPGA expertise or miracle for new FPGA projects, ongoing FPGA projects, challenging FPGA projects, failed FPGA projects, or out of control FPGA projects; don't fear or stress of failure. I support every stage of the FPGA development lifecycle with management and implementation services that meet the unique needs of customers.
From strategic consultative guidance to the provision of technical support, I help drive forward momentum and fuel rapid success. I participate directly with your team, guiding your approach, helping ensure that key outputs and documentation conform to requirements, and driving efficient development of world-class products.
CONSULT
CONNECT
COLLABORATE
<
Simplicity is not that complicated. Lean engineering
There is a fine line between a butcher and a brain surgeon.
We recovered, improved, helped, saved, and delivered catastrophically failed projects.
Let's discuss your needs our abilities and combined possibilities.
CONSULT
CONNECT
COLLABORATE
<
Embedded
Porting legacy desings into embedded FPGA platforms.
Creating custom fsbl, bsp, u-boot and devicetree for linux operating systems.
Designing custom device drivers for maximum efficiency and performance.
Coordinating software and rtl interaction.
FPGA Based Embedded
Platform
Device
Processor
OS
SDK
IDE
Xilinx
Zynq
ARM
Ubuntu
Xilinx SDK
Vivado
Altera
NiosII
Xilinx
MicroBlaze
Board based Embedded
Platform
Device
Processor
OS
SDK
IDE
TMDSICE3359
AM3359
ARM Cortex A8
TI-RTOS
Code Composer
GOBI
Freescale
PowerPC
Snapdragon
CONSULT
CONNECT
COLLABORATE
At this stage the overall requirements of the product are created based on the need that initiate this activity.
This stage is the high level architecture of the product.
FPGA is the part of the product and its high level functionality is assigned at this stage.
Architect stage defines the project by answering "What is the product?" question.
This is partially concurrent process with architecture. A preliminary estimation of resources, operating conditions and points are required for the selection stage which follows estimation.
Only an expert can generate an efficient and relatively accurate and safe estimation without going to either extreme between fortune telling and actually implementing
Selection phase is critical as it will physically limit future capability and the flexibility of the product.
FPGA Vendor, Model, Size, Pinout, electrical (lvcmos, sstl, lvds), configuration method, external interfaces (DRAM, pcie,...) are selected at this stage. Specially pinout selection requires FPGA specialization as straight forward pin selection may cause major issues in later stages.
Design stage include multiple activities. This is the stage where the internal FPGA architecture is defined and functionality is split in relatively isolated modules.
Software interface is defined collaborating with the SW team. Internal Modules and interfaces defined. Assignments of human resources and schedule for each module are also defined at this stage.
A broken product can easily be money draining then money making. In this aspect testing and validation is more important than actual design itself.
Testing is partially concurrent stage with RTL design. Each module should individually be unit tested by its own test bench and test cases.
Ideally Self generating self verifying managed or randomized test benches and test cases should be used.
Coverage tools verify the quality and efficiency of the code.
Place and route or fitting also called "back end flow" requires special ASIC development like skills with FPGA physical familiarity for high frequency high utilization projects.
For FPGA, it is technically selecting the components and wires already placed and routed and configuring the switches between them. So theoretically everything you can do with FPGA is already in the FPGA.
Validation is where the rubber meets the road for an FPGA project. This stage may be the easiest or the hardest stage depending on the quality of the design. The FPGA is verified on real environment.
Ideally it should be plug and play if the project was run by a highly specialized FPGA expert.
Please give detailed description of yor request / problem.
Documentation is the survivability determining factor of a project. Neglecting the documentation is a typical error. Over killing of the documentation is also a big problem.
An expert can go through the existing project and improve the documentation.
A good document completely defines what a product is, how it works, how it is tested. It will comply with any standard in the industry. Size matters in other things but for documentation it is not the size, it is how and what you write matters.
Please give detailed description of yor request / problem.
Being an "expert", "top-notch" has quantitative measures. How many products are delivered successfully, how competitive are the products, quality of the product, binding to the existing projects and teams seamlessly, detecting and analyzing the problems timely and accurately, delivering solutions instantly, improving the quality effectively makes you an expert.
Some of the many factors that determine the FPGA performance are pinout selection, and FPGA optimized RTL. These days FPGAs are powerful and compensates for many mistakes.
On the other hand functionality and bandwidth demand are also increasing. That is why all FPGA projects must have specialized expert supervision.
PCB interface is almost already finalized for ongoing projects. Very rarely FPGA PCB interface changes are allowed by the PCB designers as they are in later stages of the PCB design. FPGA small print restriction gets the inexperienced FPGA designers as incorrectly selected pinout either completely kills the project or causes substantial performance and functionality degradations.
On the other hand it is definitely not the end of the road for an expert. There are many documented and undocumented ways of getting the FPGA project out of a critical PCB interface mistakes. It requires manual surgeries and spcial tricks deep inside the FPGA binaries to convince the FPGA to work. This can only be achieved by bypassing all the FPGA impelentation tools and interfering with the generated binary images.
If you just realized that you can not have the FPGA product as your pinout, electrical standard, termination, or clocking selections do not comply with the FPGA implementation tool rules, or your FPGA performance is teribbly lowered because of convoluted routing bacause of improper pin selection, or you have to sacrifice some of your functinoality to eliminate some pins or change some pin configurations, or voltage levels, it is time to consult an expert.
What kind of product? what needs to be achieved or realized?
Control, processing, transmitting.
Stream to packet, packet to packet, image to image, RF to RF
Digital, analog, sampled, quantized
Packets, bit streams, signals
Standards: PCI, TCP/IP, ...
PCI to quantized analog
A course estimate of resources. For the FPGA, memory, DSP blocks, FLOPs and LUTs are estimated. There are several methods for estimating resources.
One is to create and build dummy modules and see the report generated by tools. Another is to check the similar existing modules. Calculate the resource usage based on the actual function of the module.
Bandwidth, throughput calculation. Calculate how much data is required to be processed. This will determine the architecture, bus widths and working frequency of the FPGA. Throughput can be increased by increasing the bus widths or working frequency. But routing resources or FPGA max working frequency might limit these. Also complexity of the functionality may limit the throughput if it has feed-backs, searches or store forward requirements.
Power of the FPGA has to be estimated in the beginning to enable the board power calculations and design. It must not be exceeding the power allowances limited by the board design. Also FPGA it self has certain limitations on using power that the architect should be concerned.
Temperature of the FPGA must be estimated to make sure it stays within the limit determined by the board design or FPGA characteristics. Exceeding temperatures will cause timing errors and functionality errors as well as permanent damage to FPGA nd the board.
Temperature is generally a function of resource utilization and toggle rate.
fmax has to be determined based on the throughput required. It must be verified against FPGA frequency characteristics. It is good to have some margins on the fmax.
Unless you have infinite budget and can effort the biggest and fastest FPGA, you have to make estimation. Sometimes even the biggest FPGA may not be enough and you do not want to find it out after investing time, money, and your reputation.
As much as there are scientific methods to make an accurate estimate, they should still be complemented and it still requires experience and familiarity with FPGA and the functionality to make the estimation relatively close to the actual implementation without actually implementing.
One practical method for resources (MEM, DSP, FLOPs and LUTs) usage, bandwidth, throughput, power, temperature, or fmax estimation is to write some place holder rtl and run it through the tools. But it is definitely not enough and safe itself. Most of the time it will not hit the limitation and restriction of the FPGA.
If you do not want to find out your functionality can't fit, selected FPGA can't run fast enough or it turns out to be a hot potato, or it hogs all the power leaving nothing to other components on the board, you need to consult and expert.
FPGA selection is a layered and complex activity itself. First you need to decide the FPGA vendor. Each vendor has different strong areas. Some has better hardware some has better tools to compensate their relatively less functional hardware. One thing is for sure that they are all different and that is why they are all in business.
You must find out which one meets your needs best. some has better DSP structure while other has better memory or logic components, and some others favors dense routing. Some has longer product support, some has better backward compatibility. Of course pricing are all different. Only an expert can evaluate your project and match the best vendor to enable you.
Selecting a vendor is definitely not the only and hardest part of the process. Once you decide the vendor, you have to select a part. Device price, availability, life time, footprint compatibility, usable pins, supported standards, size, max frequency are some of the items to be decided and you can't simply guess or study in a short time. An expert will see the big picture and apply previous experience to the selection process.
Tool (design, simulation, content management), and environment (UNIX, PC) decisions must be given at the selection stage as well.
If your FPGA selection criteria is biggest and fastest, your only concern is the price, you compare number of pins to find out the capability, you need to consult and expert.
This is a job for both technical lead and the Manager.
Drawing rectangles and connecting them with arrows is not architecture. Structuring an FPGA requires specific concerns. Modularizing the functionality, isolation of modules, interfacing and handshaking between modules are generic issues to be decided but FPGA needs more than that. Over modularizing causes duplication and inefficient use of resources while combining many function in one module may cause routing issues as well as making the module convoluted, inflexible and hard to maintain. The architect has to know the restriction on specialized pins, hardcore module locations, clock tree distribution, and many other small print FPGA limitations while making FPGA architectural decisions.
A high quality and efficient RTL is the key to the success of the project. Engineers must learn to thing horizontally rather then vertically as in SW development. Despite it is hard to master to write RTL code, rules to make it high quality is easy. Think like a synthesis tool and act like a router.
The difference between an expert and an FPGA designer is, every line they write, the expert can calculate the number of logic levels, visualize how it will be realized, what components will be inferred in the Hardware, how will the routing density be, what is the load (number of destinations) for a given signal, where an FPGA engineer thinks of 'if's, 'else's and assigns.
Straight forward RTL design may cause major issues in high frequency high utilization projects.
Technical issues such as handshaking, feed-backs, search, store forward, math functions (cos, sqrt) must be resolved.
If you can't see the beginning and the end of an RTL line at the same time in one line (a highly possible candidate for timing violation), number of assign lines noticeably and annoyingly high, you need to consult an expert.
FPGA verification is usually and mistakenly overlooked. Despite FPGA projects are easier to recover from mistakes and bugs then ASICs, it does not mean it is less costly or damaging.
Testing is usually executed by the designer for individual units. Verification is ideally prepared and executed by a different group of engineers for the complete FPGA.
Carefully selected test cases and scenarios for both functionality, failure conditions, recovery is a minimum set to start. Tools for simulation and environment, sanitized behivoural models, self generation self verifying stimulus generators and monitors need to be ready.
Remember any savings or shortcuts, quality sacrifice at verification stage multiply and add up to the validation and support stages which are not only more costly but also may cause a total failure of the product. The more hurry you pass this stage, the longer you come back later. A successful verification process should obsolete the validation stage.
Again expertise is a key player in preparing and executing high quality and successful verification process. Buggy behavioral models, missed failure cases, or not automatized test benches slow down the process and leads to declaration of success mistakenly.
If you are still manually testing your product, using patches, skipping regression as it is too time consuming, ignoring some test cases, declaring success for partially passed test cases, having to many "To be determined" in the test document or have no adequate test document at all, you need to consult an expert.
Despite its invisibility, FPGA routing resources are the most valuable resources in the entire PCB design. Place and route or fitting process is the most neglected but also the most important stage when it comes to the FPGA experience.
The FPGA tools are advanced and do most of the thinking. Most projects plan the place and route stage as the push button and let the tool do the work stage. This is true if your project is a blinking led FPGA or somewhat equivalent. But if your FPGA is %99 is full or it is running the entire FPGA at frequencies that are %10 off maximum specified FPGA frequencies you need a place and route expert.
Despite the many claiming FPGA experts, there is only a few engineers including in the FPGA vendor companies that could achieve these. If you want to pack more functionality in your FPGA, run faster and beat the competition, you must have this expertise in house.
A placement problem or a timing violation can be resolved by
- Guiding the place and route tool by configuring:
- Guiding the synthesis tool: Reducing inferring, preventing certain optimisation, isolating modules in different levels in synthesis. Forcing the tool to use certain structures rather than inferring.
- Changing the rtl
- Hand placing critical components
- Hand placing and routing critical components
- Hand placing and routing majority of the FPGA.
Expertise makes big difference even in relatively easier function as tool configuration. Hand placing and routing and FPGA is very rare expertise but a life saver when needed.
The tools are very smart and successful to solve generic problems and can be efficiently guided by correct configuration. Even configuring tool to let it know what is important requires expertise.
If you are having place and route problems after spending months and hundreds of runs, if you started adding ignore path or multi-path constraints to relax the design, if you are removing functionality and trimming the specifications to fit; it is time to consult and expert.
Seeing a green light on LEDs, or reading registers are not validation. Debugging bugs using Chipscope or Signaltap is not validation neither. In a high quality project designed by experts, there should be zero time spent in the lab for debugging. Validation is simply engineering test in the lab for all the cases executed in verification stage.
Basically validation is verification effort by the designers with real hardware using production or a temporary SW provided by the SW group.
Although it might look like validation stage requires relatively less expertise, it is definitely a job for any engineer. An experienced eye can catch many clues of problems, enable process by providing expert solutions where otherwise would stop validation effort.
If you are uncomfortable that your validation test plan may not be covering everything, don't know how to interpret the results, eliminate test cases as it can not be executed because lack of knowledge, unorganized and lost control as a result of novice lab planning, your engineers think using a scope, vector signal analyzer, or protocol analyzer is a major achievement in their career, you need to consult an expert.
The goal of technical documentation for and FPGA project is to help the readers to understand the product and its implementation not to impress them. A good document should be organized, classified, categorized, hierarchical, in natural flow of the actual product. It should be packed, as short as possible while telling as much as possible. Document boundaries and scope must be clear. A verification document is not the place to tell the structure of the product, or a register description is not the olace to tell how the logic works.
It has to be lean. Duplication is the worst damage than can be done to a document. The goal should be the least possible documentation telling the most possible about the product. "Ochams Razor" is a good guide to keep in mind while writing the document.
If the size of the documentation is twice the number of lines as your RTL code it is probably inefficient. Repeating paragraphs in different sections, regenerating a DOC document in PPT format does not make your product look better. Same thing repeated over and over will bore the reader lose focus reduce credibility. Splitting the document or picking certain paragraphs to generate new documents will significantly reduce productivity of both the creator and the reader.
Each project stage should have its own document. Having a great detailed design document without the test document does not make a good project.
If you prefer to look at the code rather then the documentation, if it almost needs a description tool to understand, if it covers all the floor when opened, you need to consult an expert.
Duplication
Unorganized
Unclassified,
Unsorted
Does not follow the natural flow of the actual product,
Broken links,
Unreachable references
Convoluted, unclear, boring, tiring.
Unnecessary unrelated information
Ballooned paragraphs losing focus on the actual information
Looks like encrypted almost needing a decipher to understand
Inconsistent, not synchronized, not updated along with the actual product
Missing information
Harder to understand than reading the actual product SW or HW code lines.
These are the major indications and red flags of a low quality document and most probably a low quality product. A high quality document should eliminate all the calls to support department or the designer. The goal of the product is to maximize the utilization, efficiency, quality, and marketability of a product. Not to satisfy a manager or a standard. Despite the common belief a short document is a good document as long as it includes all the information. A document can be and should be compact, clear yet complete.
It is understandable that most mangers overkill the documentation without looking at the content as they have been burned by lack of documentation in earlier projects. As a matter of fact it is surprisingly rare that a project has a good balance of documentation and product quality. Again it all comes down to subject matter expertize. An expert knows how to produce a high quality document as well as he knows to deliver high quality product.
If you prefer to look at he code then the document, you need to call many people to make any sense of the document, you are flooded with calls form other departments who are asking questions rather then reading the document, you need to consult an expert.
A SW engineer, an experienced ASIC designer, or a novice FPGA designer will deliver a working FPGA RTL with no problem. But it is the place and route engineer that will pay the price and in the worst case the entire team.
FPGA favors sequential logic where ASIC favors combinatorial. Parallelism is the toughest concept for a SW engineer while developing RTL code. FPGA will eventually (most of the time) work regardless. But at what cost. Resorting the regeneratability of the FPGA is not a smart choice. Quality of the RTL code is very important in FPGA design and it can only be achieved by an expert.
Some simple ways to detect a low quality code are the number of assign lines (mostly infers combinatorial code), length of lines or number of tabs in the lines ( mostly indicate high logic level), encountering the same variables over and over ( high fanout).
Comments are also important for maintainability. Usually inexperienced designers flood the code with comments almost telling their life story. Sometimes number of comments exceeds the number of code lines or even the actual design document. Code is hardly visible and readable buried in comments. And the other extreme is no comments. Although there is no consensus on this topic, my rule of thumb is comment only if you are doing tricky things such as checking a variable to decide something unrelated, and simple explanation of main blocks. Remember inconsistent comment that has been forgotten to be updated makes more harm then good and also remember if someone is reading your code he is probably a smart engineer who is assigned to understand your code anyways.
For ongoing projects it is usually harder to recover and increase the quality of the RTL as tight schedules, personal egos, but nothing is more important than delivering a competitive product with high quality, full functionality, on time.
If you are having problems meeting timing, place and route issues, you prefer to read the document rather than the actual code, you can't see the end of lines in your editor, you need to consult an FPGA expert.
PCB interface for an ongoing project is mostly finalized in the early stages. But there are always going to be minor changes throughout the project. Most of them minor, but sometimes FPGA limitations prevents certain pinout or electrical standard changes.
En expert would verify these changes running the complete build process with the new changes to see if the FPGA tools are reporting any problems.
Pinout selection is usually done by PCB designers and given to the FPGA designer. There are two thing that are missed most of the time. The routing resources of the FPGA are the most valuable and critical resources in entire PCB design and pins must be selected with this in mind. There will always negotiating between the FPGA architect and the PCB designer, but t must be known that FPGA is the higher priority if there is conflict or concerns by the experienced FPGA architect. The other thing is that pins on the FPGA are not always aligned with pins on the FPGA die. Inexperienced architects usually think that the pinout based on the outside is well organized and optimized for FPGA timing but end up having major timing problems or technical issues.
An FPGA expert can fix pinout or electrical standard problems even at the very late stage on a binary FPGA files without the need of going through the entire FPGA process.
Here's a sample PCB which is RO4350B 30 mil substrate for 4 way dividers.
PCB dimension: 122 x 92mm=1PCS
Basic stack up: 2 Layer PCB
copper ------- 35um(1oz)+plate TOP layer
RO4350B 30mil (0.762mm)
copper ------- 35um(1oz)+plate BOT Layer
Minimum trace and space 11.97mil
Minimum / maximum holes 0.3/2.8mm
Number of different holes 2
Number of drill holes 195
Number of milled slots 0
Material: RO4350B 30mil (0.762mm)
Surface finish: Immersion gold (2 microinch) 190% area
Our Turn-key Project serivce allow you to outsource your entire project. We take full responsibility for the planning, management and execution of your project, with or without the help of your experts.
We offer a flexible and scalable solution.
The Turn-key Project Process
Hold an initial kick-off meeting with a combined team of your and our experts,
We describe the specifications of the deliverables and intermediate milestones
We describe the planning, budget and risk management for the project
We deliver, discuss and consolidate our project plan
We assemble a team of experts to manage and execute the project
We manage and execute the project, and we provide status updates as agreed
We deliver the deliverables according to plan
We discuss the project and the lessons learned in a post-project meeting
The Turn-key Project Advantages
We take full responsibility.
You offload the planning, management and execution of your project.
We can start today or at a very short notice
capitalize on the experience of our experts to maximize quality and minimise execution time
very tight time schedule; we do have backup resources for guaranteed delivery.
Cooperation with your experts
We hink and act proactively to prevent issues that may arise
you are always in control
We review each document, evidence and artifact for content relevance, compatibility with regulatory requirements, and appropriateness to the broad range of aerospace manufacturers.
We verify:
Scope outlines the purpose of the practice and identifies those who may wish to consider its application;
Background discusses the history on the subject and reasons for consideration;
Definitions defines unique terms used throughout the document;
Body includes the information necessary for developing a program;
Conclusion highlights the expected results of implementing such a program.
We ensure
Management Responsibilities
Quality System and Configuration Management
Design Control
Document and Data Control
Product Identification and Traceability
Process Control
Inspection and Testing
Control of Inspection, Measuring and Test Equipment
Inspection and Test Status
are complete.
We analyse four stage of involvement (SOI) and ensure that the data is mature enough so a reasonable review can be conducted and sufficient transition criteria evidence exist to ensure they are being applied to the project.
(1) SOI#1, a hardware planning review.
(2) SOI#2, a hardware design review.
(3) SOI#3, a hardware validation and verification review.
(4) SOI#4, a final review, after the final hardware build and verification are complete.
FPGA Consultant Rate Schedule
FPGA Consultancy rate is $200/hour. A retainer fee of minimum 8 hours is paid prior to starting work for a new client, or on a new case.. When the initial analysis is complete and report is provided, one of the following options is offered.
hourly rate
daily rate
consultant fees by the project
consulting fees based on performance
Solution-based Fees
*All hourly rates will be billed with a 10% markup for all out of pocket expenses and reimbursable expenses.
*These rates are subject to change at the Consultants discretion. Rates will not be changed more than once every six months in any given contract term.
* Hotel charges are to be prepaid by the client. Cost of business or first class air travel is to be prepaid prior to the start of travel. If hotel or air travel costs are not prepaid by the client, a 10% service charge will apply. Rental car, postage, international long distance phone charges (if any), photocopy charges, meals, taxis, ferries, parking, and miscellaneous travel expenses will be billed at the conclusion of the trip.
Code of Ethics
We, in recognition of the importance of our technologies in affecting the quality of customer products, and in accepting a personal obligation to our profession, customers and the communities we serve, do hereby commit ourselves to the highest ethical and professional conduct and agree:
to work to achieve the highest quality and deliver customer products as required on time;
to accept responsibility in making decisions consistent with the safety, health, and welfare of the public, and to disclose promptly factors that might endanger success of the customer;
to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;
to be honest and realistic in stating claims or estimates based on available data;
to improve the understanding of technology; its appropriate application, and potential consequences;
to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;
to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;
to assist colleagues and co-workers in their professional development and to support them in following this code of ethics.
Client Agreement
AGREEMENT FOR LIMITED ADVICE AND TECHNICAL SERVICES BETWEEN YOU AND LEVENT OZTURK
This “Agreement for Limited Advice and Technical Services” (“Agreement”) is made between Levent Ozturk (collectively “Levent Ozturk” or “We” or “Us”) and the individual(s) and/or entity(ies) to be indicated on the online order form (referred to as “Client” or “You”).
This Agreement is different than the usual consultant-client agreement, particularly because it is for a set amount of time of technical consultative advice and not a full array of technical services connected with a particular matter. Levent Ozturk does not engage in employment practice; hence, this Agreement will never apply to providing appearances in customer premises or to drafting any documents for product with Levent Ozturk as designer of record for the product.
Our agreement to advise you begins one business day after the time you accept this completed Agreement and we have received payment of your fee through our credit card system and will end after we have provided you the task or service that you have purchased. An online “click through” affirmation of these terms will be treated the same as a personal signature to formally accept the terms of this Agreement.
You are making no commitment to use our services at any time in the future. We have not agreed to provide any technical assistance other than the limited technical advice services listed on the page that describes the particular service that you are purchasing from this web-site (the “Services”). We have no further obligation to you after completing the Services you have purchased.
This means that unless Levent Ozturk expressly agrees to undertake services after the Services, you don’t expect us to do anything else, and we don’t expect you to pay us anything else. We have not agreed to providing any technical assistance other than the limited technical advice and technical document preparation services authorized by this form.
If we prepare a document for you, such as design or testing documents, and it requires physical procedures, you have agreed to take responsibility for having the document created properly and in compliance with any technical procedure, according to the instructions that we provide to you. We not don’t promise or guarantee any particular outcome and are prohibited from doing so.
We have made no further investigation of the facts and we rely entirely on you, the client, to provide us with the facts of your situation.
We will not pay any fees or costs associated with your matter. These costs are your responsibility to pay.
By affirmatively accepting this Agreement, a consultant/client relationship is created. This means that all communications with you will remain confidential and we may decline to give you advice if we have a conflict of interest. For example, if we find that we have already consulted a business partner on a matter, or for any other reason set forth in the Maryland State Rules of Professional Conduct.
If we determine that we represent another client whose interests conflict, or are likely to conflict, with Client’s interests, Levent Ozturk reserves the right to terminate this Agreement, while protecting the confidentiality of any privileged information that Client has provided to us.
You agree that you have read, understood, and agreed to be bound by the terms above, and you authorize Levent Ozturk to prepare your technical documents, or provide you with technical advice, based upon these terms and conditions
You understand that there is no obligation or fee charged for registering as a client on this web site and becoming an on-line client of Levent Ozturk.
You understand that once we provide services to you our fees are Non-Refundable. If you cancel an appointment of 30 minutes or less on less than 24 hours notice (as logged via receipt of email, fax or voice mail if made outside of business hours), the fee is deemed fully earned by Levent Ozturk having held the time available for you and is non-refundable. If you cancel an appointment of more than 30 minutes (or for 30 minutes or less on more than 24 hours notice), then half of the fee is earned for having held the time for you and the other half may be applied to technical services within 30 days of the date of the canceled appointment. If not used after 30 days, the balance becomes fully earned for having reserved availability for you and becomes fully non-refundable.
Client has carefully read this Agreement and considered the additional information and advice that Levent Ozturk has provided to Client, if any. Client understands the possible risks and benefits of a limited-service consultancy described in this Agreement. Understanding those possible risks and benefits, Client voluntarily, knowingly and intentionally enters into this Agreement with Levent Ozturk.
Notwithstanding any of the foregoing, if Client has previously executed a complete consultant-client agreement, then the terms of that agreement apply to the same matter, but only to the extent of the Services ordered at this time.
Feel free to contact me to inquire about my expertise and consultancy service. Email to , or reach me at (647)390-3690 for FPGA emergencies. You may also publicly bookmark me on facial media.
Over 20 years of hands-on experience in designing, leading, and successfully delivering over 20 complete FPGA projects and helping many others to work; I am offering my technical leadership and experience in FPGA projects, and coordination skills to reduce development costs, improve quality and deliver competitive products for my customers. See if one of my online tools and hardware IP Modules may help you.
Review the procedure
Improve the process
Train the engineers
Advise decision-makers
Guide development
Guide development
General FPGA Services
Full cycle FPGA design; turnkey delivery complete with documentation
Verify against DO-254 design assurance guidelines Level A and B compliancy. Implement DO-254 compliant procedures and process. Prepare for certification.
Implement general hardware project ensuring build process, review process, checklists, bug tracking process are in places and followed. No surprises, no forgotten steps, no discovering the wheel.
Implement FPGA Specific project flow so that all the resources are coordinated preventing blocking, idleing, waiting.
Train the engineering stuff to develop FPGA efficient product. Add quality into your FPGA designs by providing engineers with the information they need to analyze and critique designs.
Analyze and validate requirements, prepare plans and procedures, review RTL code, report problems, risks, mistakes, inefficiencies, and deliver the product and document
As an electrical engineer I have designed the first mobile banking application in the world, most complex satellite transmitter, fastest FPGA running at 470MHz, that out performed and outlast the competition. I have delivered every single project I started last 20 years and they are still running in the field.
Specialized FPGA Services
Reorganize RTL architecture and appy my industry proven coding guidelines to improve maintainability; perform fast design performance exploration, maximize design performance, and achieve rapid timing closure
Visually synthesize and review every single line of RTL code against efficiency, speed, compartmentalization rules;
Hand place and route your FPGA to meet the highest possible FPGA speed. Bring the practical clock frequency limit to or almost near the theoretical limit;
Migrate between vendors
Reverse engineer your obsolete, or legacy FPGA (RTL or binary files) and upgrade to a newer FPGA;
Apply surgery to your binary files to modify functionality or fix bugs without the need of going through the entire FPGA process;
Migrate from ASIC to FPGA. Convert RTL code that is designed or optimized for ASIC to FPGA type of RTL which is significantly different.
Migrate from VHDL to Verilog and Verilog to VHDL. Convert RTL code between VHDL and Verilog and never versions of Verilog and VHDL.
Management
Ever faced unsyncronised code and document versions, code document and implementation are unlinked and untraceable, scattered documents with no fixed location, missing requirements, orphan codes, idle engineers, engineers running like headless chickens but doing nothing?
We offer management services for our customers to complete an FPGA project fluently smoothly stress and risk free.
All aspects of FPGA project management such as scope, schedule, procurement, engineering and development is performed with proven methods with your existing or future team. Our management of FPGA projects includes:
Planning: Identifying requirements, developing concepts, evaluating alternative methods and accessing required resources, social ramifications.
Scheduling: Establishing interactions and constraints, developing activity or task schedules, allocating resources, assesing the impact of delays, determining and assesing multiproject interactions.
Budgeting: Developing conceptal and detailed butdgets, identifying labour, materials and overhead, assesing risk of cost escalations, revieving budgets in regards to change.
Supervision: Leadership and professional conduct, organizing human resources, motivating teams, managing technology.
Risk: Assesing and mitigating operating equipment and system performance risks,technological risks product performance, environmental impacts.
We also developed an FPGA project management tool for our customer. For details please see FPGA Project Management Tool.
Expertise
Technology
Hardware: FPGA, circuit design
Digital Signal Processing: Application of theory, analysis, design, synthesis, validation , and implementation of simple and complex mathematical algorithms in control, analog modelling fields in time and frequency domains
Software: Gui, application, kernel, driver, embedded, internet software architecture, design and implementation
Database: Relational Database archirtecture, design and administration
Management: Maximum resource efficiency, clear visible management, guaranteed delivery of committed objectives
Since I earned my B.Sc. degree in Electronics and Telecommunication Engineering, I have delivered major SW projects for over 10 years; complex FPGA projects for another 10 years mostly single-handedly. I have designed several PCB boards as well.
My professional background can be summarized as race to learn and deliver. Constantly seeking new knowledge and strictly sticking with design work made me methodical, well organized, competent, resourceful, dependable, and technically astute.
I usually accept projects where others have failed to complete or wouldn't dare to start. My unique approach is being result oriented. Usually the term "consultant" is incorrectly used in place of contractor. A "contractor" does not necessarily indicates expertise. Keep in mind that expertise matters most in FPGA projects. I rather solve the problem, create the solution, and deliver the product in short time and move on, than residing like an employee for years whose priority in not necessarily to deliver a high quality successful product. Despite there are well defined standards for executing a project technically and management wise, every company has it unique culture of bringing the product to life. Accumulating all the FPGA practical knowledge, facts, and science for years gives me the agility and the edge to be able to solve problems and deliver in very short time where most other "consultants" would have no idea.. I only accept unique and challenging projects that I can guarantee to deliver.
Professional Achievement Highlights
Professional Achievement Highlights
Prime Technical Liaison between Switch and the Data processing groups for a Major Cellular operator. RDBMS Managed Terabytes of data in 1993
First in the world complete mobile banking application in 1994
Project Prime for deploying a Network Management system in 2000
Delivered a complete Traffic Manager System Virtex 2 FPGA that operates at 250MHz system clock in 2001.
Delivered a complete Satellite Hub Transmitter Virtex 6 FPGA that operates at 470MHz system clock in 2013.
Expertise and specialisiation are fundamentals to the success of your FPGA project. Not all contractors are consultants. Not all consultants are specialized. Not all specialized engineers are experts. When you need immediate help to solve a critical problem, make sure who you hire is an expert. We’re here to help.
Get instant expertize to your urgent FPGA problems, and projects.
For inquiries, request for quote, initiate a project fill out the form below to request FPGA specialized consultancy.
FPGA Request Details
Please give detailed description of yor request / problem.
Stage of the FPGA project:
Requirements, High Level Design, Low Level Design, RTL Coding, Verification, Debugging
What is consulted?
Full design, Device selection, Pinout, Simulation, Clock/reset distribution,
RTL Optimization, Floor planning, Lab Debugging, Timing closure, Current fmax (MHz), Target Frequency (MHz),
Test benching, Fitting/Place&Route, Utilization percentage (Slice-Lab/MEM/DSP/Clock Domain)
All the material listed and linked at this World Wide Web domain are strictly private property and copyrighted. Copyright -∞-∞ Levent Ozturk. All rights reserved. Reproduction or use of any material, documents and related graphics and any other material from this World Wide Web server is strictly prohibited. Code of Ethics | Terms of Use | Refund Policy | Contact Us | Site Map
, or reach me at (647)390-3690 for FPGA emergencies. You may also publicly bookmark me on facial media.
About
Achievements
Services
Management Tool