It really depends on how your hardware team will deliver useful artifacts that your software team can use to develop against, and how the teams are set up to communicate with each other.
Typically, you'll find the hardware team will build a product, get it to a prototype stage for testing, and only then will the software team get any sort of requirements documentation from the hardware team. Needless to say this isn't always the best way to go, as the software is usually developed very late in the process, and you generally find yourself with little choice but to work with a waterfall-based methodology. On the upside from the hardware team's point of view, if they suddenly need to change something, the software team won't need to modify their software. The problem here of course is that your average hardware guy needs to develop products in this way, and expects that anything that will benefit him with help out the software team.
As an alternative, if your hardware team is building a product and updating the software requirements as they go, and even better, if they involve the software team early on as each hardware feature is being planned and simulated, then you have the opportunity for the software team to work in a much more Agile manner. Naturally by this I mean that the hardware team is the customer, and gives the software team a list of problems that need to be solved in software. The software team can discuss with their customer the relative priorities of each requirement, and as soon as the hardware prototype is ready, the software will likely be available in an early release form, and can be used to help in testing the hardware. If the requirements change, the software team will hopefully have the agility to change the software as they go, and can provide early feedback to the hardware team before the hardware design is committed to prototype. The software team also have direct access to the customer very early in the project, which means that they can get a better idea about what they need to mock out - and how to do it - while waiting for hardware to test against.
Realistically, you won't find an ideal methodology that just fits off the shelf, and I can guarantee that you will have a lot of tweaking to do no matter which methodology you choose to adopt, or develop. The real issue is that you want to try and make the synchronization between the teams easy to manage, and means that you need to find a way to increase the amount of contact and input between the two teams as early as you can in the process, even if it seems "wasteful" or "counter-intuitive" to do so. This is a big problem in the company that I am presently working with. Our European "parent" is struggling with this exact problem, while the team here in Oz seems to be able to keep things running a little more smoothly, and it's really all due to giving the software team more involvement early in the design and simulation stages of the hardware development.