09-11-2013 01:34 AM
Hi. I'm having issues in simulating a post-PAR ISE project, with a Microblaze instantiated inside it.
I have a top module that instantiates a Microblaze processor. In SDK I developed an application. Then I added the ELF file to my ISE project, setting it as a "simulation-only" ELF file. Then I created a test bench and I started a Behavioral simulation, that succeeded: you can see the attached image "Behavioral_sim" where it is possible to identify the processor activity.
Then I generated the post-PAR simulation model and started the post-Route simulation with the same testbench, but in the waveforms is no more possible seeing the processo activity (see image "post_PAR_sim").
Why? What am I doing wrong?
Thanks in advance,
09-24-2013 08:08 AM
I'm on ISE 14.4. I think it is a bug of ISE, because finally I have found a working procedure, that I'm going to describe.
After the "Generate post PAR simulation model" process, you should find the memory files (.mem) created from the ELF file by data2mem. There should be also the timing VHDL simulation file (or verilog, but in my case it is VHDL) in the /netgen/par/ directory.
Somewhere inside this last (close to the beginning of the file) there are the initialization strings for the BRAM used in the project. Every string looks like this one:
INIT_xx => X"00000000...",
where xx is an hex number between 00 and 7F, and the field full of '0' is a 64-digit-long word of zeroes (the valu '0' because they have not been initialized yed).
After the INIT_7F line, you can see the line to select which mem file initializes the BRAM inside the VHDL file. It is similar to this:
INIT_FILE => "NAME_OF_FILE.mem",
For some reason (probably a bug), the simulation procedure doesn't initialize the VHDL file with the mem file, even if it has been correctly generated, it is in the right location and it is not full of zeroes (I checked a lot of times).
The procedure I found is:
I launched data2mem from command line with this command:
data2mem -bm my_BMM_file.bmm -bd my_ELF_file.elf -o uvh OUTPUT_FILE_NAME (this generated 3 files: a verilog, a VHDL and a UCF file named OUTPUT_FILE_NAME. They contains the initialization values for the BRAM).
From the OUTPUT_FILE_NAME.vhd just generated, I took the INIT_xx strings and I wrote them in the VHDL timing simulation file.
In this file I also commented the line INIT_FILE => "NAME_OF_FILE.mem": this to avoid an overwrite of zeroes upon the values I just inserted.
I launched the post PAR simulation and it worked.
I want to underline that THIS IS NOT A SOLUTION BUT ONLY A WORKING BYPASS-PROCEDURE. I still would like to understand if the problem is an ISE bug or it is a wrong set-up.
Please, if there is any Xilinx employee reading this thread, could I have an opinion?
Thanks hgleamon1 for your attention :-)
09-11-2013 01:38 AM
The reset is correctly stimulated. Obviously it is not evident because of the dimensions of the window and the time-axis scale (microseconds).
09-11-2013 04:50 AM
You may need to set the ELF association to "implementation" (or "both") to see post-PAR simulation activity.
If you set the ELF to "Simulation Only", I don't believe it will be picked up during implementation, which you will need to produce a post-PAR simulation file.
09-11-2013 05:27 AM
Thanks for the answer. I will try the post-PAR simulation setting the ELF file for both the simulation and the implementation.
However there is something curious. After selecting also the "implementation" property for the ELF file, the icons of the implementation processes did not change. See the attached image taken after I checked the "implementation" radio button. I would have expected a lot of orange question marks, because normally if you change something in the project, all the processes depending by it become "to be processed".
I will try and report my results
09-11-2013 06:40 AM
Mmm... infact there is no change. I added the ELF file for both the simulation and the implementation, then I re-implemented the project and re-generated the post-PAR simulation model, but the post- PAR simulation still gives the same result: the processor appears not operative, like if the BRAM was empty.
09-12-2013 12:02 AM
I realise that I may have misdirected you. The ELF won't be picked up until bitstream generation so I believe you were correct to have originally specified it for simulation (although no harm done by including it for both).
My guess would now be that there is a difference between your behavioural code and the post-PAR implementation. You should, if possible, check that your resets and clocks are correctly handled throughout the design, particularly those associated with the Microblaze.
I would check the inputs/outputs of DCMs and Reset blocks if possible. Can you spot any problems from the Map or PAR reports that might indicate that signals you believe should be present have been removed?
09-12-2013 02:40 AM
The project is exactly the same for both the simulations. I firstly did a behavioral simulation (that worked fine) then a post-PAR simulation (that failed) without changing anything: the hardware and the testbench are the same.
Is there a manual (or Application Note) to understand how to perform a post PAR simulation of an ISE project with a MicroBlaze nested inside?
09-12-2013 04:00 AM
The project may well be the same but the results of the simulations can be very different (evidently).
A behavioural simulation will produce results based on the COMPILATION of your HDL and models of the units inside the design, e.g. FIFOs, RAMs, DCM/PLLs, etc.
The post-PAR simulation will produce results based on the synthesis, map and par processes, using your input constraints and proper timing representations of the connections in your design. Synthesis, map and par will all produce some level of optimisation that may or may not be what you want.
Can you guarantee that the post-PAR design is identical to the pre-synthesis design? Frankly, I doubt it.
Subsequently, you should check the status of the resets and clocks inside the post-PAR simulation. If the Microblaze is doing nothing, it could be because it is in reset or not being clocked correctly.
For example, does your testbench produce a top level clock that matches your input clock constraints and the defined input frequency for your embedded DCM/PLL (if you have one)?
09-12-2013 09:18 AM
To be sure about what's wrong, I created a new easy project only to check the post PAR simulation procedure.
I have created an ISE project with a microblaze. The processor environment has been created by the Base System Builder wizard, so it should be good, in hardware, because I haven't modified it. The system has only 8 leds, the processor and all the usual peripherals needed by an EDK system (debug module, clock generator, system reset system, etc...). Please, see the image "EDK_system" attached. The input differential clock pair has a 200 MHz frequency, while the processor works at 100 MHz freq. The Clock generator created by the wizard correctly provides the uBlaze clock (please, see the image "clock_gen_properties").
In ISE I created the top level VHDL file by selecting the Microblaze source in the Hierarchy panel and by clicking on "Generate top HDL source" in the Processes panel, so it is good also (I checked it and did a syntax verification).
Then I exported the design in SDK (without bitstream) and created a "blinky" application. In ISE I added such application for both simulation and implementation.
Then I started the "Generate Post PAR simulation model" and of course all the implementation processes have been executed. It succeeded.
Finally I created a test bench in ISE for the top module. As always, ISE automatically created the test bench model and I had only to give the reset for 100 ns, and correct the Clock pair period (5 ns). The Negative clock is inverted with respect to the Positive one. Here they follow the processes of my test bench:
CLK_P <= '0';
wait for CLK_P_period/2;
CLK_P <= '1';
wait for CLK_P_period/2;
CLK_N <= '1';
wait for CLK_N_period/2;
CLK_N <= '0';
wait for CLK_N_period/2;
reset <= '1';
wait for 100 ns;
reset <= '0';
With the same test bench and the same hardware created as described, I started a behavioral simulation and a post PAR simulation. The first worked and the second didn't (please see the "simulations" image).
From my UCF you can see the clock constraints:
NET CLK_N LOC = "E18" | IOSTANDARD = "LVDS";
NET CLK_P LOC = "E19" | IOSTANDARD = "LVDS";
Net CLK_N TNM_NET = CLK_N;
TIMESPEC TS_CLK_N = PERIOD CLK_N 200000 kHz;
Net CLK_P TNM_NET = CLK_P;
TIMESPEC TS_CLK_P = PERIOD CLK_P 200000 kHz;
I don't understand where I'm doing wrong
09-13-2013 06:18 AM
09-13-2013 06:28 AM
You're still not showing what is going on in the UUT. I can only see your testbench level signals.
What is happening INSIDE the embedded system?
09-16-2013 03:29 AM
I thought the images I attached were sufficient because I succedeed in the post PAR simulation with the same uBlaze environment (the same MHS file) but implemented only in EDK. In that case the processor worked as foreseen.
As the same EDK project implemented in ISE didn't show the processor activity in the simulation, I thought it was a problem in ISE (or more probably a my error) and not an error in the hardware design.
However I'm probably wrong, so when you ask what is happening INSIDE the embedded system, what would you like to know precisely? Do you want me to post some uut inner signals as showed by iSim?
In this case, as the post PAR simulation model generates signals with unintelligible names, I really don't know how to find (for example) the inner uBlaze reset signal between the thousands of signals listed in the "object" panel of the iSim simulator. Any help in that sense?
One more question...
Is my simulation procedure correct or did I miss something? The procedure is summarized below:
Thanks for your patience
09-16-2013 03:43 AM
One more thing. In iSim I tried to find out if the microblaze BRAMs were correctly initialized so I navigated inside the instantiation source code of the BRAMs. They appear to be empty.
I have attached an image from iSim to show what I mean. In the image it is possible to see that the ramb36e1_3 BRAM is empty, but I chacked also the other BRAMs and they are empty too.
If this is the problem, how can I correctly initialize the BRAMs?
09-16-2013 05:10 AM
With reference to message 4 of this thread, could you post your uBlaze_top VHDL, possibly your testbench, too?
Having now understood that you have succeeded with a post-PAR from XPS, I suspect that it is the way that it is being implemented under ISE but I can't put my finger on it yet.
09-16-2013 05:36 AM
09-16-2013 06:10 AM
OK, your instantiations look OK.
One last question, is your reset to the embedded system active high or active low (i.e. how is it stipulated in your MHS)? Your testbench acts like it is active high but if the clocks are running and (presumably) the DCMs are locked but the code does nothing, perhaps you are in reset still (because you are driving the reset incorrectly)?
I apologise if you feel you have covered this but it's such an easy and elementary error, it really is worth double checking ...
09-16-2013 07:21 AM
I know that is a common error, often due to distraction. But in this case the reset is active high, as you can see in the image. Moreover the behavioral simulation works fine with the same testbench.
09-16-2013 11:49 PM - edited 09-16-2013 11:49 PM
OK. Now I'm guessing :) I agree with your assessment that it is something with the ISE setup.
Can you show the process properties for the ISim Simulate process?
Can you look through the transcript when you execute the Simulate process and determine whether the ELF is being picked up? Particularly something like this:
Checking platform address map ...
Running Data2Mem with the following command:
data2mem -bm "system_sim.bmm" -bd
-u -p xc6slx25tfgg484-2
09-17-2013 02:00 AM
When I launch "Generate post-PAR simulation model" these are the last log entries:
Running Data2Mem with the following command:
data2mem -bm "uBlaze_sim.bmm" -bd "C:\Users\worktest\Desktop\Luciano\Progetti_ISE\solo_uBlaze_ModReset_noCstmIP_noPCI\uBlaze\SDK\workspace\ublaze_application\Debug\ublaze_application.elf" tag microblaze_0 -bx C:\Users\worktest\Desktop\Luciano\Progetti_ISE\solo_uBlaze_ModReset_noCstmIP_noPCI -u -p xc7vx485tffg1761-2
Mem Generator done!
Generated MEM file list:
XPS MEM file generation completed.
INFO:HDLCompiler:1061 - Parsing VHDL file "C:/Users/worktest/Desktop/Luciano/Progetti_ISE/solo_uBlaze_ModReset_noCstmIP_noPCI/netgen/par/uBlaze_top_timesim.vhd" into library work INFO:ProjectMgmt - Parsing design hierarchy completed successfully.
Process "Generate Post-Place & Route Simulation Model" completed successfully
09-17-2013 02:18 AM
09-18-2013 06:14 AM
Can you show or describe the ISim properties in ISE when you simulate?
Have you attempted to download a generated bitstream to a unit and verify that it works? One of my points is that if you can get behavioural simulations working and the hardware works, possibly post-PAR simulation is not such a necessary step. Additionally, it could further prove that you are not generating differences between HDL compilation and HDL synthesis.
Otherwise, I'm struggling to provie further assistance (if I provided any to start with!).
09-18-2013 06:32 AM
First of all I thank you for trying helping me.
I have implemented the design and downloaded the biststream into the board. It works. The same environment doesn't produce any processor activity in a post-PAR simulation launched by ISE. But if I create the same environment in EDK (same MHS and same processor application), the post PAR simulation succeds.
As the post PAR simulation in EDK is fine and the implementation of the ISE project works on the board, I'm forced to think that the problem lies in some setup of the post PAR simulation in ISE.
I would open a webcase but the Xilinx support service doesn't allow me to do it.
Help me, Obi-Wan Kenobi. You're my only hope!
09-18-2013 06:39 AM
Screen shot of the ISim properties dialogue from ISE, then, please :)
09-18-2013 10:16 AM
What is that NETGEN command line pointing to? That is not the same ELF as you previously described ...
09-19-2013 12:33 AM
Ah, yes. In the meantime I created a very simple test project called "blinky". It simply makes some leds to blink.
It is the project I said it works on hardware and with a working post PAR simulation in EDK but not in ISE.
09-23-2013 12:47 AM
Is there anybody that can say to me at least if the problem resides into a bad configuration or into a ISE bug?
In the past, did anybody succedeed in simulating a post-PAR ISE project with a Microblaze instantiated?
I think it is quite incredible that for almost two weeks no Xilinx employee has given his opinion in this thread...
Could you please allow me to open a webcase about this issue?
09-24-2013 06:17 AM
I have never tried to do a post-PAR sim using an embedded system (as I intimated in a previous message, they may not be necessary. If your behavioural sim works as expected, you meet timing and the physical hardware works as expected when configured, there is no real need for a post-PAR sim).
Anyway, I shall conduct a test with a simple system using the ISE 13.4 installation that I have and let you know how I get on.
What version of the tools are you using (haven't seen it in this thread)? Any chance you could update to the latest if applicable?