My Risc-v Processor Running in Operation Does not Work in FPGA.

[drkome]

I gave a pin out from the register file to test it. It works very well in simulation. I have a Zybo Z-7-20 card. When I embed my project in it, it doesn't work. I programmed the blink command with assembly. In FPGA, only the light is on. In case there is a clock problem. I used a clock divider. The LED is on at first. Then it doesn't go off. But this process succeeds in simulation. If I need to send output or a document for this, I can post it. Can you help me?

[zygot]

2 hours ago, drkome said:

I used a clock divider.

• How did you use your clock divider?
• What was your intended effect for doing this?
• How did you implement this?

2 hours ago, drkome said:

The LED is on at first. Then it doesn't go off.

How do you know this? By looking at the LED? If the Signal driving the LED is on for 10 ms and goes off for 100 ns, and repeats this cycle would you expect to detect this by looking at the LED? You say that it works in simulation. Perhaps. Does you simulation last long enough? Is it complete?

You ran a timing report of course and carefully looked over the results.

Since the project is pretty self-contained you might want to try a simulation of your placed and routed implementation netlist and see how that works.

[drkome]

@zygot Hello!
 

module counter1(
    input clk, rst,
    output reg [7:0] counterout
    );
    
 always @ (posedge(clk), posedge(rst))
 begin
     if (rst) counterout <= 0;
     else counterout <= counterout + 1;
end
endmodule

I using this clock divider, bcs if I dont use this clock divider, My processor dont work bcs of worst slack ,that's why I using this.

and this is my risc assemby instructions.   I made loop code in venus(web sites), maybe  I can try to raise li x4,10000000 number.  x3 register is my led register. and and I left using clock divider. I using clock_wizard now.  and "How did you implement this?" I dont understand this. 

 

 

I still new this fpga sorry. Maybe I'm asking a simple question. But it is difficult to get answers to some questions.

[zygot]

You're showing me a counter, not how you use the counter. I'm guessing that you are trying to slow down the processor by somehow using the counter, correct?

An embedded processor, not supported by your FPGA tools is not a good beginner's project.

In modern programmable logic devices clock signals and logic signals are two separate and distinct parts to how the FPGA functions. Clocks have their own resources such as PLL and in Xilinx MMCM blocks for creating related clocks having a different frequency but related to one clock. Clocking infrastructure has its own routing fabric. The logic has its own resources and routing fabric. Logic doesn't need to be clocked but usually is.

Creating a clock in logic is a very bad idea. Having said that you can pace clocked logic with a counter, implemented in logic, but you still have to clock all of your logic with a real clock. 

Before you even think about starting on your first logic design, whether you are designing the whole thing yourself or trying to implement someone else's design, you need to have a basic idea of how your FPGA device is organized and works. Open your Document Navigator that Vivado installed on you PC and read through UG474, UG472 and UG471 to understand how the logic elements, clocking elements, and IO work.

A design with no timing constraints may not show timing problems and still not work because the tools need this kind of information to do the timing analysis. Once you get through implementation and open the implementation results, going to the timing section is just the beginning. You need to look inside all of the subsections, like clock summary, intra-clock paths timing, inter-clock path timing, etc. Even then you you aren't done. Earlier versions of Vivado generated a general timing report based on delays. Now you have to request a specific timing report. Vivado is pretty good at helping you along at creating constraints once you learn how to use the GUI. There's a couple of user guide for that as well.

Would you jump into a helicopter and try to fly 200 miles a night with no instruction and no idea as to what the indicators indicated and what the controls were? Doing this with Vivado won't kill you but will certainly frustrate you more that it does experienced users.

 

Edited July 15, 2023 by zygot

[Niță Eduard]

Hi @drkome,
It seems that you are building your own RISC-V processor.
Depending on how you implement it (single cycle, pipelined, multicycle etc.), you may encounter different problems.
What type of microarchitecture are you building?
Can you post a screenshot of what you are simulating? Double check your simulation.
At what clock frequency is your processor running? Perhaps your LED is blinking, but at a much faster rate that cannot be seen with the naked eye.
I recommend connecting your signals (instruction, RS1, RS2, ALU result etc) to an Integrated Logic Analyzer (ILA) and then using the Hardware Monitor to analyze what is happening. Perhaps there are some issues with one or more of the IF/ID/EX/M/WB phases. This can help find the cause.

[drkome]

@zygot thanks for answer, I looking this UG474, UG472 and UG471.

@Niță Eduard Hello, now I try to make  RV32I  and pipeline architecture. Actually my project is finished. But dont work in FPGA. I will try to explain everything in order. you may be right. Maybe I can't see the led. But when I extend the timing excessively, the led lights up and it should not light up. Or not appearing at all.

1_)Since I don't have any IO outputs, I wanted to see a physical led operation. For this, I connected a bit of the outside led from the x3 register in the register file. that's my only goal right now.

My constraints file 

2._)By the way, I gave up on using a clock divider. I am using ClockWizard. My FGPA working at 125mhz. 

 

My clock wizard is like this.

(very little loop number photos bcs of you can see pin clock edge)

I knew this pin periods is very little.  I am increasing the loop before embedded FPGA.

 

 

This is my register file.  like this because it is an infinite blink command.   

Here, the pin led does not light because I have increased the loop too much. It does not appear in the simulation. In the assembly command I wrote, the led does not light at first, it goes into a loop. Then the led starts to light. But when I press reset once in the system, the led lights up. Then the LED should not have been on at all. Because there is a 3b9aca00 value loop in front of it in the above register file. (Don't be confused, the pin in the other photo is made in less cycles, so the led seems to be blinking.)

EDİT= I seem to understand why the problem started. It's about branching operators. But I still haven't been able to solve the problem. Let me explain how I found the error.

 

If I write a command like above, branches, Led does not light. Because it's always in a loop.

 

this time if i write code like above. Branch does not loop because x4 and x5 are equal. running li x3.1. BUT!

 

If I want to count 5 times and then exit the loop and turn on the led, as in the code example above. The LED stays off. But when this branching condition appears in simulation and works correctly in simulation . The card does not work. If I saw that the led was lit only with this code, there would be no problem.

 

Edited July 16, 2023 by drkome

[Niță Eduard]

Hi @drkome,
Thank you for your screenshots and answers.
Since you are implementing a pipelined design, you should make sure that there are no hazards.
Are you dealing with hazards? If not, you should choose how you fix hazards (stalling instructions or dedicated hardware). I don't think venus detects data hazards, so in your case you will need to add bubbles (noop instructions) to stall.

Take a look at this presentation:
https://inst.eecs.berkeley.edu/~cs61c/su20/pdfs/lectures/lec14.pdf

Study the Data Hazards and Control Hazards sections.

Here is how to add an ILA to your design. You should use this to visualize your signals inside the FPGA:
http://web.mit.edu/6.111/www/f2017/handouts/labs/ila.html

Also, how are you writing data from the register file to the LED pin? If you just connect bit(0) from the ALU Result it probably won't work, because you will change your instruction. You should verify that you are writing data at address 3 and if so, write the value to a flip flop that is connected to the LED.

[drkome]

@Niță Eduard  thanks for try helping to me.
I have control_unit.v, this module has Hazar_unit and forwarding Unit. I looked at the simulation and there is no danger and the system works in the simulation. Also, there is no problem in the simulation. All registers are added correctly and on time. Finally, I get the led output I want. If I want to light the led with only one command assembly command, I can light the led. But when the event enters the branches, the system breaks down. Branches work very well in simulation. Without any hazard. I don't understand why it doesn't work on the card. Maybe there is a problem with the reset. But I need to try ILA. 

OR

Negedge is problem for bram ?  Maybe system is working in simulation but Bram may not working in physical system.

Edited July 16, 2023 by drkome

[zygot]

1 hour ago, drkome said:

Branches work very well in simulation. Without any hazard. I don't understand why it doesn't work on the card

There isn't one kind of simulation, even for ISIM in VIvado.

What you are doing is behavioral simulation. This only simulates the behavior of your Verilog as the simulator understands it. There's no attempt to predict how it will be synthesized and placed into the logic elements. That means that it doesn't analyze signal delays inside your design. There's another kind of simulation that ISIM can do based on the actual netlist reflecting the implementation. This more accurately shows potential timing problems. Behavioral simulation helps debug bad logic and code. Timing simulation, usually done after the behavioral simulation appears to work, helps identify delay related issues. If your combinatorial logic and routing delay exceeds the clock period your design will either not work at all or have periodic failures. Timing issues for very complex designs, like Soft-processors, with almost no connections to IO can be difficult to debug. Even if you get your processor working, you might find that connecting to mode IO in order to add new external interfaces changes your placement and routing, and therefor timing, leading to a new round of timing closure effort.

I'm not sure why you are using positive edge and negative edge clocking for your memory module. Dual clock memory structures have a purpose, but not in the way that you are using it. Using both edges of your clock in a design makes timing, and therefore place and route twice as hard. as a general rule, only use one clock edge throughout your design.

Keep using your Document Navigator and keep reading. All FPGA vendors have information that help you write VHDL or Verilog so that synthesis produces common structures in a consistent manner. Alternatively, you can use the Block Ram memory Generator to produce FIFOs or RAM as a guide until you are more experienced.

The fact that you had to slow down the clock that drives your logic suggests a larger problem. One thing that you can do is increase the clock period excessively as a test to see if internal timing is the issue.

Another problem that you are facing is that you are troubleshooting HW and SW concurrently. Try to break up the complexity by working on smaller parts of your design and getting all of those working.

Timing issues are inherently difficult as the same logic structure can exhibit widely different delays depending on the state of the input, and possibly the last state of the structure. This means that a timing simulation that only test a couple of all possible combinations of inputs and states might work fine but your hardware experiences a scenario different than what your simulation did and hardware fails; or that a better testbench succeeds in finding the failure for you.

 

Edited July 16, 2023 by zygot

[drkome]

 

 

@zygot

Thank you very much for helping me, I learned a lot of different things while reading what you wrote. I found the problem. But I couldn't find how to solve it. But this is success for me for now. The compiler runs the lui command in the background even if I'm not using lui. As soon as the system enters the lui command. That's why the system doesn't work. LED is flashing now. The compiler adds the upper immadiate command to the li command if I type an over 11-bit number, so it doesn't work. The problem is that the lui command is a verilogal error? Is it a bug with the timer? I'm relieved to have found this now. This was my thesis project. If I hadn't found some more, I would have cried. Thank you very much for helping me. I learned a lot.

 

 

 

 

 

 

Edited July 16, 2023 by drkome

[zygot]

Beside device family user guides, there are quite a few user guides on Vivado. In particular read the one about Vivado synthesis as it has important information about its support for HDL languages. Only a subset of HDL keywords can be synthesized. Also read the Vivado Implementation guide.

There's more of course for when you are ready. It's a lot to ingest but my approach is to speed-read through all of the most important and return to them as needed. You need to understand how the tools work in order to get your HDL implemented without timing problems.

So, one thing that you've learned is that getting a design to work on hardware, even if behaviorally there are no major errors, isn't enough. More importantly, being able to build something that gets through synthesis, implementation and bitgen is one thing... having the skills and insight to debug your design is quite another thing.