As an FPGA engineer who also writes C I am increasingly finding myself in the situation of having to create both the FPGA design and the software to interface to it. It never starts out that way, my boss promises additional resource for the software but once I get half way through we have the chat that enquires as to how much effort it is to do the C code also. As it happens I am the only FPGA engineer in my company.

I have always thought this as bad practise as the choices on interface and architecture are never seen by anyone else and don't benefit from a review. Another issue I am finding is it makes debugging and problem solving a lot harder. Additional pressure to get the FPGA design working means that complex issues such as timing etc may take a short cut (or at least - "I'll deal with that later"). Then debugging the whole system leaves one person (i.e. me) with the question "is the issue in the C code or the FPGA?" and then trying to decide what code needs to be modified to identify it. Thinking about one problem in two domains is much more of an issue than focusing on just one of them. Having two engineers for this process would make it far more manageable.

Is this the situation that many engineers find themselves in? Am I just being too fussy and should just get on with it?

What are the ways that others use to project manage this sort of work and does it generally work out fine?

I would appreciate your opinion!

@paulkushner, I have been in both situations but regardless if there are resources to write the application code I typically find myself writing the bare minimal software interfaces for two reasons: 1) I need the code to test 2) it is the fastest path.

As you note, in the situation where there are other developers writing the application code there are more eyes on the interface and it benefits from review.  But also, the software developers are never satisfied (more features, more documentation, must be the gateware/hardware, ...).  There are pros and cons.

In the cases where I have no additional resources I still break up the development as if I had the additional resources - in otherwords don't shoot the moon.  Implement your gateware and develop the test code to verify the gateware.  After the test code and testing is complete implement the application code.  The managers won't like this because it will require extra resources (in this case the resource is time) but as you note this will save you time debugging later.

Somewhat timely comment in the context of general development

"The cost and pain of developing software is approximately 0 compared to the cost of operating & maintaining it over time" @mipsytipsy ✨🦄✨

— Ines Sombra (@randommood) April 29, 2016

I find my self in a similar situation as the OP and cfelton. I go the route of writing the C code myself to get my FPGA logic tested out as it would take longer if it was someone else writing it. 

I do it because I like it, but sometimes I just wish there was someone to take care of the C part or the FPGA part.