for the first time I have been facing a task to develop software for a given embedded hardware (Xilinx Zynq 7000 - datasheet) from scratch. The software which I am going to develop will control electric drive of an electromobile. I have been looking for how to proceed in this situation. What is necessary to know about the hardware platform from the software developer point of view before starting coding? What is the appropriate sequence for studying individual features of new hardware? Thanks for any suggestions.
The Zynq 7000 is a complex chip, but presumably you're part of a team that includes one or more hardware designers who are doing the PCB and FPGA fabric parts of the design.
For your purposes, you need a document that I usually call the "Hardware-Software Interface Specification". This document provides all of the details that the software developer needs in order to communicate with the hardware — the layout of the address space, and a complete description of how all of the hardware registers are laid out and what they do.
This document is mostly prepared by the hardware engineers, but you will have some input into the process, too — you will describe to them the kinds of information the software will need from the hardware and the kinds of things that the software will need to be able to do to the hardware. All of this will derive, of course, from the system functional specification, which all of you have already worked out with the marketing team.
In the meantime, you need to be reading up on the Xilinx SoC software development and debugging tools — there is plenty of documentation on these topics on their website.
In parallel with all of that, you'll also be developing the "Software Functional Specification" — a document that defines which parts of the system functionality are implemented in software and goes into greater detail about each of the tasks that must be performed. This will include things like power system status, motor control and the user interface. Based on this, you will make decisions about what kind of operating system to use — high-level (e.g., Linux), RTOS, or maybe even "bare metal". You will negotiate with the hardware developers about any tasks that need FPGA fabric support (hardware acceleration) in order to meet their requirements.
I'd like to extend on Dave's excellent answer (really, upvote that answer.):
The Zynq 7000 even gives you an even more important role in this project: It's a Frankenstein's system-on-chip that includes both a medium-sized FPGA and a (slow-ish, by modern standards) ARM applications processor.
So, if your job is to "own" the Zynq, it's your job to both design software to run on the ARM (typically, you'd run Linux or a similar operating system on that CPU), and to design the FPGA image, so you're doing both, hardware and software design.
That is quite a bit to do, and I can only stress what Dave said:
In the meantime, you need to be reading up on the Xilinx SoC software development and debugging tools
... and honestly, get one of the many evaluatioon boards for 7000-series Zynq (the zedboard is quite popular), and work through the examples. You'll be happy if you know how to blink an LED through your FPGA from your CPU, I promise. That's basically what engineers in companies do, too: Learn how to use the device in an environment designed by those who took part in the design of the device. Without that, you'll spend far too many engineering hours on learning to take baby steps with the device, and thus, it's financially often a no-brainer that you buy the eval board, even if it costs a couple of thousand euros.
Looking at your application specifically: Your application
will control electric drive of an electromobile.
If that just entails "telling the motor controllers that right front should go faster", well, then you can probably do that in software, and all you need the FPGA for would be electrically interfacing with these controllers.
If, on the other hand, you're supposed to be collecting back-EMF and hall sensor data to control the switching of power MOSFETs or IGBTs directly, then, well, you've got a problem that implies hard real-time constraints in the sub-microseconds order; and then, you can do practically nothing in software on an ARM applications processor core architecture with known uncertain interrupt latency, complex external memory, and all in all no optimization for these kind of workloads. You'll have to do most, if not practically all, of your processing in the FPGA – and that means that you're not a software developer anymore; you just got promoted to digital hardware designer, and possibly signal processing guru!