Design ALU in microblaze using nexys 4

[uzmeed]

Hi 

 

I am new to microblaze. I have to design an efficient ALU using microblaze in Nexys 4 

Anyone can guide through me the procedure ( I know the general guide line) and refer any document to do it 

Regards

Uzmeed

[D@n]

@uzmeed,

You might need to explain more of what you want to do here.

MicroBlaze is a complete and working CPU.  It already has an ALU within it.  Further, since it's a closed source ALU, I think you will struggle to modify or add anything to it.

Are you trying to create a bus-based peripheral that you can interact with from the MicroBlaze which will act as an ALU?  I've seen instructors ask for this before.  You know, something where you write to values to the "device" and then write an operation to the device, and when you read from it later it has the right answer?  That I've seen.  If that's what you want to do, then you'll probably want to read this article on how to build a working AXI-lite peripheral.  (Xilinx's demo code is quite broken--so is Intel's.)  I have another article that discusses what it takes to build an ALU in general--perhaps that would be of interest as well.

Dan

[uzmeed]

@D@n
My task is to write a code that can calculate the eigen value decomposition of a 3x3 matrix 
Infact that is not exactly the ALU . I need to perform multiplication addition and subtraction along with cordic square root and arctan So I named it as ALU
I need to do the following
k = −(a b c)
 l = ab bc ac−f2 −e2 −d2
m = af2 −abc−2fde be2 cd2
p =− 1 /3k2 l,
q = 2/ 27k3 − 1/ 3lk m
along with cordic function
Following is the block is the block diagram that needs to be implemented in microblaze
 
Best Regards

[zygot]

That's quite a project. I think that I know how I'd do it  but then I'm not taking your course, don't have a deadline, and have no idea what exactly it is that your instructor expects you to demonstrate as knowledge gained from taking his course; and this is important.

One thing for sure is that I'd implement the task in OCTAVE using the simplest statements, no short cuts, simple structures with a mind to HDL implementation. Then I'd work on the HDL implementation. And here's the important point: I assume that you are expected to use an HDL and not pre-packaged IP or MATLAB code producing scripts. You don't want to jump into the English Channel if all you are expected to do is demonstrate that you can stay afloat on you back for 20 minutes.

For an HDL project this is both interesting and somewhat challenging. You need to understand fixed point signed  binary, bit growth, and more. This makes me think that I should be very cautious in suggesting an approach because I'm not the one needing a working solution by some deadline....

[uzmeed]

Hi @zygot

Thank you so much for an encouraging reply

In fact my instructor dint ask me to make this project . Taking an opportunity of studying this course I myself requested my instructor to learn microblaze programming ( i had been doing HDL for years , but never went for microblaze)

He asked me to see initially how I can go about.

For understanding fixed point signed  binary, bit growth , synchronization of different modules I have simulated the entire code  and its working well 

I will be looking forward for your further help

Best Regards

uzmeed

[zygot]

My only advice so far then is to write lots of single task components and lots of testbenches and get simulating. Since you are experienced in HDL that isn't anything new to you. I'd certainly spend the time to consider the overall structure of your design and how you plan on moving data into and out of it. It should be both challenging and fun. An ounce of preparation is worth pound of debugging; if you can get past my habit of mixing metaphors.

[uzmeed]

Hi @zygot

Thank you I will definitely follow your advice and looking for your help

 

Best Regards

Uzmeed

[xc6lx45]

So you have working fixed point RTL (sounds like quite an achievement BTW) and want to hook it up to the Microblaze.
I'd look for info how to implement an AXI lite slave. Vivado has several built-in options to help with that - not necessarily the best way, depending who you ask, but it did work for me. For example "Tools / Create and package new IP / create a new AXI4 peripheral". Finish the wizard, then take the Verilog file with its implemented dummy registers and continue editing it by hand.

My first step would be

- plain registers for input data
- a write-sensitive registers for the final input data word or a dedicated "control / start" word that resets/starts the processing state machine and clears an "output-is-valid" bit
- a register for the first result that blocks on read for "output-is-valid" from the state machine
- plain read-only registers for the remaining output data

The control flow of the program is simply "write data, read results, repeat".

I'd sell this as "minimum-size approach"... It can be improved in many ways (e.g. output-side FIFO, input-side FIFO, pipelined processing in RTL, full AXI / stream, ...) depending on your specific requirements e.g. throughput, bus utilization, avoid blocking the CPU.

[zygot]

There are two general approaches to dealing with the Soft processor or ARM processor flows when these are embedded into a design. One is to do the whole design within the framework of the tools, in VIvado the board design flow. I've done that using Xilinx IP and creating and packaging my own IP. I much prefer the other approach which is to constrain the whole IP stuff into a "black box". I use interfaces that have external pins exposed that are easy to connect to HDL. BRAMs are useful or sometimes it makes sense to package my own interface IP. Once the board design is complete and generated I have Vivado create an HDL file encapsulating the entire mess and then instantiate that as a component in my own toplevel HDL. Make sure to let Vivado know that you want to control the heirarchy not Vivado.

There's no right way to do it; it depends on you own preferences and convenience. A good general rule, in my experience, is that letting the tools control things is never as good as having the tools let me control things. In the end the price of convenience usually results in unwanted constraint. Also, vendor IP is happy to use up resources with functionality that I don't need. I still use ARM based FPGAs but can't remember that last time I felt the need to use a MicroBlaze or Nios.

[edit] Oh... and most important is that vendor IP is prone to being broken with new tools versions. Upgrading old IP, especially for soft processors, is rarely as simple or trivial as the vendors want you to believe that it is. Just yesterday I was testing a demo release for the Project Vault by rebuilding it on another host. The design was created in Vivado 2016.2 and the test build was created in Vivado 2019.1. There were only two IP, an MMCM and a FIFO and Vivado 2019.1 choked on both because it has restructured it's internal IP handling. This was the first time in quite a while that basic FPGA resource IP got trashed by a tool version; but it happens. For most of the other IP this happens a lot more frequently. If the SDK is involved then schedule a few days or more to figure out how to resurrect old designs created by past tool versions.