06-06-2011 05:13 AM
Hello all, hello Ken,
I use Picoblaze (PB3) with Spartan3 since many years without problems.
Now I do a design first time with PB6, target is the eval board SP601 with S6LX16.
While debugging my complete code I figured out, there is something wrong with the shift/rotate operation group.
To demonstrate the strange effect, I wrote this simple test program:
Main: ENABLE INTERRUPT
Isr: LOAD s0, 00
OUTPUT s0, 80
LOAD s0, 01
OUTPUT s0, 80 ;trigger output for scope
LOAD s1, 00
Loop: ADD s0, 01
OUTPUT s0, 80 ;output to 8-bits scope port
ADD s1, 01
JUMP NZ, Loop
EndIsr: RETURNI ENABLE
Output to the scope (8-bit-port "80") you can see in figure "ADD.jpg". Output is like expected.
Now I change just line 8, nothing else, same FPGA bit file:
Loop: RL s0
Now output is expected to get 255 times a "running '1'". But as you can see in "RL.jpg", nothing happens, although WriteStrobes apply. Output is just "01", Register "s0" is not being changed!
This applies to all 10 shift and rotate operations!
The strange thing is: In VHDL-simulation with Modelsim, so with original hardware, everthing works correct.
Could there be a wrong implementation of Picoblaze 6 by ISE? I use the latest (today) Picoblaze source files and ISE 13.1 (newest release).
Clock is just 33MHz, so I can't believe, there is a timing problem or something (no timing errors apply), because everything else of Picoblaze, besides shift/rotate operations, is doing fine.
Unforunately there is no reasonable workaround for me for the shift operations.
So please check this on your own hardware.
Harman Automotive Division
06-06-2011 08:16 AM
I figured out there seems to be a problem with a Mapper setting.
In that case, I described the failure of shift operation above, the setting "Global Optimization" of the Mapper was set on "Speed".
Now I tried the setting "Off". Then all the 10 shift/rotate operations work again!
So I assume there is a problem with the Mapper while optimiziation process concerning this switch.
Further investigation would be very interesting.......
06-07-2011 01:57 AM
I had a similar problem using PB6 with the new uart6, with global_opt set to anything but off, the mapper would remove most of the logic including the RX pin.
I raised the issue with Ken Chapman, and he verified there is a problem with the mapper, and raised an internal bug report. Apparantly there are a few outstanding bug reports against global_opt.
06-08-2011 03:10 AM
With a very simple hardware design I implemented the same fundamental loop as your code to output the “running 1” to a port when targeting a Spartan-6 device. First I performed a functional simulation in ISim to makes sure it was doing what I expected it to do. I then run the design all the way through XST and PAR using default options before trying a timing (back annotated) simulation and everything still looked Ok. I then set the ‘global_opt’ property in MAP to ‘speed’ and run the design through PAR again before repeating the timing simulation but still everything was Ok. I know you run a simulation which looked Ok but did you try a back annotated timing simulation as well? It would be ‘good’ if you could make a simulation fail in the same way as your hardware as that avoids any issues with hardware or the need for someone to set up hardware to repeat the experiments.
I then tried the same design on my Spartan-6 Drigmorn3 board (from Enterpoint) which has really nice rows of 0.1” headers that I can easy clip my scope probes to. I tried the design with ‘global_opt’ set to ‘off’ and ‘speed’ but both designs worked perfectly showing nice “running 1” pulses.
I was using ISE 12.4 which is a difference to your experiments and could potentially be the cause. However, it could relate to your specific design in some way. Regardless, we know that KCPSM6 and your design works when ‘global_opt’ is set to ‘off’ but broken when it is set to ‘speed’. I therefore think you should open an official case with Xilinx Technical Support related to MAP and ‘global_opt’ so that this is investigated further. If you do manage to show the failing situation in a back annotated timing simulation then that would be really useful.
Thanks for bringing this issue to the PicoBlaze forum. Whilst it isn’t a clear cut case of failure in all situations, raising awareness of a potential could help save other users a lot of head scratching. Hopefully we can isolate this issue soon and add an update to this thread.
Principal Engineer, Xilinx UK
06-09-2011 08:41 AM
I implemented the same design with ISE 12.4: The failure does not occur. So this problem seems to exist at Version 13.1 only.
Then I made a little test design, only with PicoBlaze in it, including an endless loop of output of the "running '1'".
After that, I did a timing simulation (post place&route). And - as we assumed - with GlobalOptimization OFF the "running '1'" applies, with setting to SPEED the shift operations do not work (see GlobalOpt.pdf in DESIGN). --> There is a problem in the mapper concerning this switch.
I attached the complete design, so if you like you can try it on your PC.
We will raise a case at Xilinx, including the test design. With the help of that design, the ISE SW guys should be able to locate the bug.
By the way: At setting POWER, the shift operations will not run, too. With setting AREA, the mapper reports 2 errors due to some slice mapping issues.
06-10-2011 04:44 AM
MANY thanks for taking the time and effort to conduct further tests. You certainly appear to have isolated this issue to ISE v13.1 and being able to demonstrate the failure in a simulation is ideal. As you said, opening your official case with Xilinx Technical Support combined with your worked example should see this on its way to the right people to get it resolved.
Excellent work on your part and thank you again on behalf of all the KCPSM6 users that you will continue to help simply because they will be able to read this thread on the forum.
Principal Engineer, Xilinx UK
07-25-2011 06:38 AM
today I opened a case (my collegue didn't got the time currently).
I decided first to check the situation with newest ISE13.2 first. Failure still occur.
12.4 is fine, in 13.1 and 13.2 there is the bug.
Case # is 885081
Best Regards from Germany,
11-01-2011 09:34 AM
I also ran into this problem using ISE13.2. I have two questions:
1) Is this fixed in ISE 13.3?
2) Where can I find this GlobalOptimization setting in ISE 13.2?
11-02-2011 07:25 AM
You would see ‘Global Optimization’ (-global_opt) as one of the process properties for MAP. Unless you have set it otherwise then the default is ‘Off’ anyway.
Here is the description of this issue in the ‘READ_ME_FIRST.txt’ provided with Release 3 of KCPSM6. I think the message to take away from this is that ‘global_opt’ has not been carried forward to the 7-Series devices and is therefore it is slowly falling into history!
'global_opt' may result in incorrect implementation
Setting 'global_opt' to anything other than 'off' (the default) in MAP when using ISE v13.1 may result in incorrect implementation of the KCPSM6 logic and therefore a failure to execute code in the way expected (e.g. shift and rotate operations may not work properly). This issue has not been observed when using ISE v12.4 so use this version of the tools or set 'global_opt' to 'off' at least to isolate this potential issue. Please check with Xilinx Technical Support for tool updates to determine if there is a later version of the tools in which this has been fixed. Note that when using ISE v13.2 is used to target a 7-Series device the 'global_opt' option is not available and therefore this issue can only occur when targeting Spartan-6 or Virtex-6.
Principal Engineer, Xilinx UK
11-03-2011 02:38 AM
I need to apologize for giving too little information.
I'm using ISE13.2 for a Spartan-3E and use a KCPSM3 picoblaze and accompanying UART. It appears that the UART stops after transmitting 4 bytes and I assumed it was a result of the above mentioned uart problem.
When I look in the MAP process properties I do not see ‘Global Optimization’ (-global_opt). I do see 'Optimization Strategy (Cover Mode)' (-cm) and it is set to 'Area'. This is probably a result of having run SmartXplorer and choosing Design Strategy 'maptiming2'. I need that for other parts of my design as the default gives me timing violations on my I/O. However, setting this to 'Off' did not take away my problem. And a pre-simulation shows correct behaviour.