Detlev Zundel wrote:
Hi Xyyiezi,
I am in an IC design company.And there ia an object of my company it isabout mpc8260.We have the circuit netlist of mpc8260,but we cann't guarantee the circuit netlist to be correct.The circuit netlist was on a SUN server which supported Linux and Cadence. We want to use the u-boot as a software verification tool to verificate the netlist. We have write a platform which was used as an hardware in the verification. And we want to load the u-boot code mpc8260 to the RAM block of the circuit netlist.In this method,we could verificate the circuit netlist by both u-boot and the platform.It will be a mode of hardware and software co-verification. But the difficult is I don't kown how to load the u-boot.Now I have read the source code of the mpc8260 in the u-boot,and I kown I could use the GCC to translate them.I didn't kown how to configure the mpc8260.What material should I read?In my opinion,the circuit netlist will be similar to the hardware mpc8260 expect the speed while it is running.But the hardware mpc8260 has its board ,for example mpc8260ads,which is not in the circuit netlist in the SUN server.And I don't kown whether I could configure the u-boot take the board information. I earnest hope to obtain your help! Thank you!
Gone are the days when hardware was something you could knock your head against :)
No honestly, I don't understand completely what "netlist" (what is that anyway?) you are simulating, but you either have to
a) simulate hardware supported by U-Boot or b) create a U-Boot port for your simulated hardware.
Considering the fact that you simply want to _use_ U-Boot, I guess a) would be the most viable option. However it sounds that you simulate your own custom hardware, so very likely things will not turn out to work out of the box.
Taking route b) will take some time and very likely defeat your original intention of verification.
Cheers Detlev
Hi xyyiezi, Detlev,
My guess is that xyyiezi _does_ want to do b) - create a u-boot port for his simulated hardware which will be used to verify the simulated hardware before it becomes real hardware. This requires him to port u-boot to his hardware. Non-trivial, and not something we can help much via email.
Xyyiezi: You want to start with the README section on porting. While you are loading into a "RAM" block in the simulation, you should configure/consider it to be flash, hooked to CS0. I'm assuming your simulated hardware has simulated or physical SDRAM - if you are using a RAM block to represent SDRAM in your simulation, then your port is much simpler but won't be as realistic (a large percentage of hardware problems have SDRAM as part of the problem - including layout problems that won't show up in your simulation anyway :-( ).
FWIIW, I've been down this path before and had very limited results, especially compared to the level of effort involved. If your simulated bus cycles are OK, and your real hardware layout is OK, your system will work OK. The lack fidelity of simulation (e.g. not really running SDRAM, not really using a MPC8260, not really using your physical board layout, etc.) means that almost all of the real problem areas are not simulated accurately enough to say whether your real hardware will work or not.
The simulation will always predict "yes, your hardware works" but the confidence level with respect to that answer will be very low.
Just to emphasize, the answer of your simulation WILL ALWAYS BE "yes, your hardware works" but it is still a crap-shoot whether that answer applies to your real hardware. Making sure the details are correct (bus cycle timing AND LAYOUT!!!) are a MUCH better predictor of success than running in a simulation.
Good luck, gvb P.S. Did I mention LAYOUT IS CRITICAL and you cannot simulate that?