[SOLVED] Re: Multi cycle paths

[S S Rayudu]

Re: Multi cycle paths

Hello,

what are the practical problems occur by assigning multi-cycle path's to overcome setup violations. Any reply highly appreciated.

Thanks,
Rayudu

 

[ads-ee]

Re: Multi cycle paths

You don't arbitrarily apply multi-cycle paths to fix setup violations, you use a multi-cycle path if and only if the path was designed with a multi-cycle path, e.g. there is an enable strobe on both the source and destination flip-flops.

If the plan is to fix setup violations with multicycle paths your going to end up with an ASIC that doesn't work. Start looking for a new job once the ASIC is tapped out.

 

[slutarius]

Re: Multi cycle paths

Multicycle path constraint is NOT used to OVERCOME setup violation.
If you want to check whether you can apply or not, please the people who make the logic.

 

[ads-ee]

Re: Multi cycle paths

If the plan is to fix setup violations with multicycle paths your going to end up with an ASIC that doesn't work. Start looking for a new job once the ASIC is tapped out.

Given the amount of behind the scene discussion this has produced. I think it might be appropriate to tell a story from my past experiences.

Way back 20+ years ago I started working for a large company that was hiring ASIC engineers for a project that was already behind schedule. It turns out that I was hired to replace a bunch of "ASIC" engineers that were let go.

The reason behind this was a clueless manager had decided that ASIC engineers were asking for too much money and there weren't enough of them around to hire, so they saw/decided that VHDL was similar enough to ADA that they could hire cheaper and available software engineers to do the coding. The software engineers did not know anything about hardware and proceeded to write VHDL programs using every language feature available.

Needless to say their VHDL software would not synthesize. This only came up much later in the project after the "code freeze" occurred as they were always on-schedule with their unit testing, etc. This became a major schedule hit as the code was not even close to being done. The company ended up laying off all of these software "ASIC" engineers, replaced the manager and hired a team of experienced ASIC engineers. I was hired near the end of this hiring phase and had to pick up an ASIC design that was really bad. It had been worked over by an experienced ASIC hardware engineer, but still looked like a software engineer wrote the original code. Mostly the changes were attempts to pipeline the design and remove all the non-synthesizable code. The ASIC engineer that did this preliminary work quit (after finding a better job). I took this cruddy design and fixed more of the code, refactored a bunch of it and eventually got it to tapeout and first pass success. Fortunately the company I was working for had the money to continue the project though they had a very upset customer.

The lesson from this is if you screw up an ASIC job badly enough, there is a high likelihood of being fired/laid-off/company_going_bankrupt. It also depends on when that screw up is caught, before/during/after tapeout, with each step increasing the likelihood of disastrous results. If the company has spent millions on NRE charges and the ASICs that are fabricated don't work because you decided to fix setup failures by adding multi-cycle path constraints then the company loses millions on that single screw up....guess who's out the door looking for a new job...maybe everyone if the company is small and can't afford to loose that kind of money, maybe the entire ASIC team that worked on the project, or maybe just the person who added the constraint.

So advising you to start looking for a new job was actually a warning to you that if you try to do something like hide real setup violations behind multi-cycle constraints, then you might as well look for another job as your choices are between getting fired then finding a new job or finding a job before getting fired (the second option is easier). I've witnessed firsthand someone leaving before their design arrived in-house as I was stuck with the redesign effort.

 

[slutarius]

Re: Multi cycle paths

That's bad anyway. Using things without knowing the root of usage and applicability would bring unexpected results.

 

[barkha]

Re: Multi cycle paths

Multi-cycle constraints provided by Designer only , if that path is intended to meet only in multi-cycle.
You can always check with designer whether any MCP is missed there OR that is genuine path to meet only in single cycle.