cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
maria.ax69
Visitor
Visitor
706 Views
Registered: ‎05-09-2019

custom ip creation in vivado

Hi

i am trying to implement an for matrix multiplication (4x4 multiplied by 4x4 matrix),where inputs are given from the sdk. each input 8 bits.

The problem is i am not getting the values which have changing values.what ever value at the done signal is getting at the output. Also if i give some constant value at the temporary variables a1,a2,b1,b2,etc output is getting correctly.But not when assiging values from slv_reg.

i am also attaching the file containing the code.

can anyone please help me with this.

Regards

 

0 Kudos
5 Replies
dgisselq
Scholar
Scholar
657 Views
Registered: ‎05-21-2015

@maria.ax69,

Care to try attaching that code again?  It would give us something to talk about.

Dan

0 Kudos
maria.ax69
Visitor
Visitor
638 Views
Registered: ‎05-09-2019

sorry i thought i added the code file previously but it didn't  get uploaded. now i have attached the code file. The use logic is towards the end of the code.

regards 

0 Kudos
dgisselq
Scholar
Scholar
623 Views
Registered: ‎05-21-2015

Okay, yeah, let's see ...

  1. First, the AXI-lite code you are using is buggy.  While they've fixed some of the problems I discussed in my blog, they haven't fixed all of them.  You are likely to find that the bus will lock up when using the Vivado generated code.  (Others already have.)
  2. The AXI-lite code is also crippled.  Even if it were to work, it would never work that fast.  I'm not sure if this would be of interest to you or not.  The cool part is that, were you to rewrite the bus logic, you could get it to run faster for less logic--but that's neither here nor there.
  3. You have some state transition code that ... I can't quite follow at a quick glance.  I'd need to run it through SymbiYosys to have any confidence in it working.  Alternatively, you might consider using the ILA (Internal Logic Analyzer) to check that as well.
  4. Personally, were I to write something like this, I would have it start immediately on writing the last value to the core, and to hold the ARREADY line low until the core was done computing.

Just my two cents,

Dan

0 Kudos
maria.ax69
Visitor
Visitor
609 Views
Registered: ‎05-09-2019

First of all,Thank you so much for replying .

Actually i am a beginer ,so what you are telling about AXI i didn't get that much.

what i want is work that state machine correctly. i have simulated the state machine separately and it works also, but when i tried to create an ip using it it doesn't work.

In the custom ip if i am giving some fixed values to a1,a2,a3,a4,b1,b2,b3,b4 , i am correctly getting the cout.

example: a1=8'h01, a2=8'h02, a3=8'h03 etc

But if i am giving a1=slv_reg0[31:24] then zero is getting at the output.

with this i am attaching the code for state machine i have simulated.also attaching the sdk code.

 

regards

0 Kudos
dgisselq
Scholar
Scholar
591 Views
Registered: ‎05-21-2015

@maria.ax69,

Perhaps this might help: Notice how two AXI read requests generate only a single read response.  That's called a bug.

axi-read-fault.png

Sadly, given that this is a bug in the Vivado generated portion of your code ... it's a pretty common mistake.  (Any Xillinx employees listening?  @demarco perhaps?)

I might offer to spend some more time with your code, but you have some other bugs you need to fix first.  For example ...

  • Using <= in a combinatorial always block is generally bad practice.  Use "=", and avoid any mismatches between simulation and synthesis
  • Your tabbing is atrocious.  Consider the following code, and tell me ... should slvreg0 bet set on any non-reset event, or at all times?

badtabbing.png

  • You should define your statex values using localparam's, not parameters, since you really don't want them ever being overridden
  • On a reset, you set nstate to zero rather than pstate.  (See image above)  Vivado should have produced an error  for this, since nstate is set in a different always block as well.  The general rule?  Any given value can only be set in a single always block--never more.
  • As a matter of style, when most individuals use multiplies, they do it for speed.  What that means is that you want to place the multiplies in a block by themselves, with little to no other logic, and you'll want to take an entire clock cycle to do the operation.  In other words, you might want ...

better-mpy.png

  • Finally, your giant always @(pstate) block will be generated with many latches within it.  This is generally very bad.  What is a latch?  A latch is sort of defined as a memory but without the clock.  An example of a latch might look like:

basic-latch.png

  • If, within an always @(*) (or equivalently an always @(pstate)) block you ever set some variables but not others, the hardware that gets implemented will form a latch.  There are some strategies you can use to keep this from happening: 1) Be aware of any warnings Vivado generates, 2) Assign to *every* value you intend to assign to at the top of the always block and before your case.  That way everything is guaranteed to have a default value.  3) Break those giant always blocks up.  That way it'll be easier to see what's going on.

I've also noticed, going through your code, that you are thinking of things that will happen one at a time.  Try to think instead of how everything will happen at once, and then use that to your advantage.  An example of that would be the multiplication implementation shown above.  Consider setting as few variables as possible in an always block, and only merge variables together when the if-then-case structure is (nearly) identical.

One final thing: Verilog is an easy language to make a mistake in.  Consider 1) Adding the line `default_nettype none // to the top of your Verilog file, and 2) running "verilator -Wall -cc matrixp.v" on your file.  That'll run a lint pass to highlight bugs for you.  It won't necessarily find all of them, but it will find many of them and its a lot faster to run than Vivado Synthesis is.  These two steps will save you from a multitude of troubles further on.

Oh, and ... No, I still haven't pointed out the problem you are having with your state machine.  Try fixing these problems first, and then you'll have a better chance of being right later.

For more information, consider my beginner's tutorial.  I think you might learn a lot from it, especially in the way of how to debug your code.

Hope that helps,

Dan

0 Kudos