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
Many thanks, Alexander
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
Many thanks, Alexander
Hi Alex, you can also try to use the picoblaze C compiler on
Francesco
Alexander Werger schrieb:
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
John Adair Enterpoint Ltd. - Home of Hollybush1. The PC104+ FPGA Development Board.
Falk Brunner ( snipped-for-privacy@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 : >
: 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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.