OpenFire - public domain MicroBlaze clone in verilog

Another ( maybe the same ;-) ) is at

Sandro

Sandro schrieb:

its not the same at all - the OpenFire docs explain why they did not use the aeMB but rather designed a new core.

the author of the aeMB has other priorities (university study) and has dropped the development ASFAIK

Antti

You are correct. I wrote the OpenFire from scratch after encountering difficulties understanding and modifying aeMB. From what I remember aeMB departed from the MicroBlaze three-stage pipeline to obtain better performance. For my purposes, however, I desired a simple pipeline and controller. Performance did not suffer much, as I am able to obtain 100 MHz in a Virtex-II Pro.

The processor should be posted to OpenCores in the coming weeks. In the meantime, the official website is:

While the processor correctly executes a large subset of the MicroBlaze instructions (minus the optional instructions), there is much room for improvement. If anyone would be interested in contributing to the processor, please contact me.

Stephen

Stephen Craven schrieb:

contact!

:)

• missing feature: byte enables in toplevel, they are internally there but memory writes seem to be only 32 bit wide as byte enable signals are not going to memories or to toplevel

Antti

It has been a while since I looked at it, but byte and half-word addressing should be completely supported. To keep the memory interface simple, all accesses are 32-bits wide. Byte and half-word loads occur in the registerfile and byte and half-word stores operate on a read-modify-write basis within the execute stage.

This does cause some difficulties in completely integrating the processor into the EDK flow, among other things, so I may look into adding an LMB interface.

"Stephen Craven" schrieb im Newsbeitrag news: snipped-for-privacy@m79g2000cwm.googlegroups.com...

read-modify-write - thats not sufficent - the external memory interface must be able todo real byte writes as well, in the case that some stupid ip core is connected with 8 bit registers and side-effects on register reads. there are other reasons as well.

the byte_sel signal seems to be the signal that should go to toplevel and optionally be used by external memory interface

Antti

Indeed. However, for my purposes the simple memory interface and the reduced BRAM requirement justified the internal byte steering. For the MicroBlaze, RAM must be added in groups of 4 BRAMs, so that an individual byte can be stored by selecting a specific memory. The read-modify-write of the OpenFire permits a single BRAM to be used.

Regardless, the OpenFire code is (hopefully) fairly easy for others to customize to their needs.