Virtex4 FX12 - maximum frequency for Picoblaze

Hi,
in a test implementation (ISE 8.1) of a Picoblaze core in a XC4VFX12-10 
device the maximum frequency is about 110 MHz (55MIPS).
In the Picoblaze product brief 
(http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf) 
the performance is 102 MIPS -> 204MHz.
Anybody  has an idea how to increase the maximum frequency on our Picoblaze 
test implementation? Is there any reference implementation for the V4 FX12 
available?

Many thanks,
Alexander

Alexander Werger wrote:
> Hi,
> in a test implementation (ISE 8.1) of a Picoblaze core in a XC4VFX12-10
> device the maximum frequency is about 110 MHz (55MIPS).
> In the Picoblaze product brief
> (http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf)
> the performance is 102 MIPS -> 204MHz.
> Anybody  has an idea how to increase the maximum frequency on our Picoblaze
> test implementation? Is there any reference implementation for the V4 FX12
> available?
>
> Many thanks,
> Alexander

Hi Alex,
you can also try to use the picoblaze C compiler on www.poderico.co.uk

Francesco

Alexander Werger schrieb:
> Hi,
> in a test implementation (ISE 8.1) of a Picoblaze core in a XC4VFX12-10 
> device the maximum frequency is about 110 MHz (55MIPS).
> In the Picoblaze product brief 
> (http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf) 
> the performance is 102 MIPS -> 204MHz.
> Anybody  has an idea how to increase the maximum frequency on our Picoblaze 
> test implementation? Is there any reference implementation for the V4 FX12 

Register the IO-bus. If you dont need access to BRAM via the IO bus, 
this will increase clock speed significantly. I remember Picoblaze 
reacing ~ 80 MHz in Spartan-3.

Regards
Falk

There are a few tweeks that we have done previously in Spartan-3 
architecture and from my memory we got 30-50% increase. Basically there are 
some hacks arround the code memory that can give this improvement if Ken 
Chapman hasn't put these in since last time I looked. It may be possible to 
the same in V4 but I have not tried yet. If I get around to it I will put it 
with our other PicoBlaze material on out TechiTips website page 
http://www.enterpoint.co.uk/techitips/techitips.html.

John Adair
Enterpoint Ltd. - Home of Hollybush1. The PC104+ FPGA Development Board.
http://www.enterpoint.co.uk


"Alexander Werger" <awerger@web.de> wrote in message 
news:e5m52t$b0i$02$1@news.t-online.com...
> Hi,
> in a test implementation (ISE 8.1) of a Picoblaze core in a XC4VFX12-10 
> device the maximum frequency is about 110 MHz (55MIPS).
> In the Picoblaze product brief 
> (http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf) 
> the performance is 102 MIPS -> 204MHz.
> Anybody  has an idea how to increase the maximum frequency on our 
> Picoblaze test implementation? Is there any reference implementation for 
> the V4 FX12 available?
>
> Many thanks,
> Alexander
>
>
>
>
>
> 

Falk Brunner (Falk.Brunner@gmx.de) wrote:
: Alexander Werger schrieb:
: > Hi,
: > in a test implementation (ISE 8.1) of a Picoblaze core in a XC4VFX12-10 
: > device the maximum frequency is about 110 MHz (55MIPS).
: > In the Picoblaze product brief 
: > (http://www.xilinx.com/bvdocs/ipcenter/data_sheet/picoblaze_productbrief.pdf) 
: > the performance is 102 MIPS -> 204MHz.
: > Anybody  has an idea how to increase the maximum frequency on our Picoblaze 
: > test implementation? Is there any reference implementation for the V4 FX12 

: Register the IO-bus. If you dont need access to BRAM via the IO bus, 
: this will increase clock speed significantly. I remember Picoblaze 
: reacing ~ 80 MHz in Spartan-3.

I'd second that - the Picoblaze reads IO on the second clock of the instruction 
so you get one register for free (timingwise).  One design I have needs two 
levels of registers to meet timing and I can afford to compensate for this in the 
software.  (So actually the second level of registers are only there to placate 
the timing analysis...)

I don't think the scratchpad is in the critical path, but if it is and you're 
not using it you could try cutting it out.

Looking at page 14 of ug129 the mux between the ALU/INPORT and the register file 
may be critical, so again if you don't need the scratchpad perhaps using that for 
IO with direct addressing and removing the INPORT and the downstream mux could 
speed things up.

An interesting project might be to automate the examination of the assembly file 
for a design and remval of unused ports / ALU functions etc. and see how much 
difference it makes.

cheers
cds