If you could automate one part of your design workflow, what would it be? We are asking e14 in our Join, Share & Win Competition

If I could automate one thing in my design workflow, it would be the whole timing closure issue. You know that feeling when you have a design that works perfectly in simulation, and then you run it through the synthesis tools only to find you’re missing timing by 3 nanoseconds on some random path you didn't even know existed? Yeah, that’s it.

I remember this one time, must've been quite a while back, I was working on an image processing pipeline for a camera system. The design looked pretty good, or so I thought. It had a nice modular structure and was well pipelined, with simulations showing promising results. When I ran the first build, though, timing violations popped up everywhere. I spent the entire day trying to figure out what was wrong. I added pipeline stages, adjusted synthesis attributes, and reorganized some logic. Each build takes about 30 to 40 minutes, so I make a change, grab a drink, come back, check the report, mutter under your breath, and repeat.Finally, after going through the iterations, I was reviewing the timing report for probably the ninth time. I noticed this path that made no sense. It went from a data register in one processing block, passing through half the design, then into some control logic that shouldn’t even interact with that data. After another hour of digging through the elaborated design, I discovered the issue. There was a simple debug signal I had added weeks earlier during development. It just combined a bunch of status flags from different modules for easier probing. I completely forgot it was even there. The tools routed this signal across the whole block, and since it touched logic in different clock domains, it created all these incorrect timing dependencies.So after fixing it up, ran the build again, and everything passed with 2 nanoseconds of slack. I sat there laughing at myself. Four hours, probably eight synthesis runs, and it was just one forgotten debug signal. What would make a real difference is if the tools could communicate in plain language about these issues. Instead of saying, "path from inst_47/gen_block[3]/data_reg to inst_892/ctrl_logic/state_reg fails by 1.2ns," how about saying, "Hey, your debug signal 'all_status_flags' is connecting unrelated logic and causing timing problems is probably not what you intended?" , since the code's already commented out, it checks the debug reg block signals instead of giving me the raw netlist regs. Or when it detects a critical path, it could suggest specific fixes based on the actual code structure. For example, "This path has too much combinational logic between registers, so consider adding a pipeline stage after the multiplier on line 156." These kinds of automated, source code aware suggestions would save so much time instead of going through multiple reports and browsing the designs, which honestly takes forever. The elaborated designs are massive and take minutes just to load in the GUI, and navigating through them without the GUI using just text reports is like reading the Matrix.

Another big time drain is managing constraint files. Every project feels like it takes at least half a day to set up the XDC or SDC files. I need to ensure all the clocks are defined correctly, the I/O standards match the schematic, and the pin assignments are accurate. Then, the hardware team always seems to change something on the board, or I switch to a different FPGA variant, and I have to go through it all again. I’ve definitely spent hours debugging strange behavior only to find a pin got swapped in the constraints.It would be great if there was automated integration between the schematic tools and FPGA constraints. For instance, the hardware team exports a latest version of schematic, that automatically generates or updates the constraint file with the correct pin mappings and I/O standards. It should also validate against the FPGA's capabilities like, "Hey, you're trying to put a 3.3V signal on a 1.8V bank; that's not going to work." , these basic automated checks would save a lot of time before wasting a synthesis/implementation run.

If I could automate one thing in my design workflow, it would be the whole timing closure issue. You know that feeling when you have a design that works perfectly in simulation, and then you run it through the synthesis tools only to find you’re missing timing by 3 nanoseconds on some random path you didn't even know existed? Yeah, that’s it.

I remember this one time, must've been quite a while back, I was working on an image processing pipeline for a camera system. The design looked pretty good, or so I thought. It had a nice modular structure and was well pipelined, with simulations showing promising results. When I ran the first build, though, timing violations popped up everywhere. I spent the entire day trying to figure out what was wrong. I added pipeline stages, adjusted synthesis attributes, and reorganized some logic. Each build takes about 30 to 40 minutes, so I make a change, grab a drink, come back, check the report, mutter under your breath, and repeat.Finally, after going through the iterations, I was reviewing the timing report for probably the ninth time. I noticed this path that made no sense. It went from a data register in one processing block, passing through half the design, then into some control logic that shouldn’t even interact with that data. After another hour of digging through the elaborated design, I discovered the issue. There was a simple debug signal I had added weeks earlier during development. It just combined a bunch of status flags from different modules for easier probing. I completely forgot it was even there. The tools routed this signal across the whole block, and since it touched logic in different clock domains, it created all these incorrect timing dependencies.So after fixing it up, ran the build again, and everything passed with 2 nanoseconds of slack. I sat there laughing at myself. Four hours, probably eight synthesis runs, and it was just one forgotten debug signal. What would make a real difference is if the tools could communicate in plain language about these issues. Instead of saying, "path from inst_47/gen_block[3]/data_reg to inst_892/ctrl_logic/state_reg fails by 1.2ns," how about saying, "Hey, your debug signal 'all_status_flags' is connecting unrelated logic and causing timing problems is probably not what you intended?" , since the code's already commented out, it checks the debug reg block signals instead of giving me the raw netlist regs. Or when it detects a critical path, it could suggest specific fixes based on the actual code structure. For example, "This path has too much combinational logic between registers, so consider adding a pipeline stage after the multiplier on line 156." These kinds of automated, source code aware suggestions would save so much time instead of going through multiple reports and browsing the designs, which honestly takes forever. The elaborated designs are massive and take minutes just to load in the GUI, and navigating through them without the GUI using just text reports is like reading the Matrix.

Another big time drain is managing constraint files. Every project feels like it takes at least half a day to set up the XDC or SDC files. I need to ensure all the clocks are defined correctly, the I/O standards match the schematic, and the pin assignments are accurate. Then, the hardware team always seems to change something on the board, or I switch to a different FPGA variant, and I have to go through it all again. I’ve definitely spent hours debugging strange behavior only to find a pin got swapped in the constraints.It would be great if there was automated integration between the schematic tools and FPGA constraints. For instance, the hardware team exports a latest version of schematic, that automatically generates or updates the constraint file with the correct pin mappings and I/O standards. It should also validate against the FPGA's capabilities like, "Hey, you're trying to put a 3.3V signal on a 1.8V bank; that's not going to work." , these basic automated checks would save a lot of time before wasting a synthesis/implementation run.