strange problem when doing post-synthesis simulation

[65nmCMOS]

Hi i am doing post-synthesis simulation now,and i have added my own rams in sp-ram.sv and replace timer with a simple two bit multipulier, i am using modelsim to simulate, my RTL simulation is correct, but there are something wrong for post-synthesis simulation, you can see, it looks like a knife cut my design down, but i have compared the datas with my RTL simulation, before that"knife" all datas are the same, if i make "fetch_enable" change from 0 to 1 later, my design will be cut later,if i force "fetch_enable"=0 all the time, the design will not be cut.

I change nothing in the core and it will be cut when i use both riscv and zero_riscy core, my clk period for synthesis is 5000ps and my slack is +207ps, but i delete all unsynthesisable blocks when doing synthesis,

i have tried to use original timer and original RAM(i make the size of mem in sp-ram.sv smaller, and use a whole day to do RTL simulation, synthesis and post-synthesis simulation) the RTL simulation is correct but the post-synthesis still be cut at the same point, i really don't konw how to deal with the problem now! so some suggestion is appreciated!

[barrydebruin]

Enabling the fetch enable signal starts the program counter and the core will fetch an instruction. If this instruction is somehow undefined, the complete memory might be corrupted. Try to see if no incorrect instruction or data is being fetched.

[65nmCMOS]

Enabling the fetch enable signal starts the program counter and the core will fetch an instruction. If this instruction is somehow undefined, the complete memory might be corrupted. Try to see if no incorrect instruction or data is being fetched.

yeah! i will try that! thank you for suggestion!

[65nmCMOS]

Enabling the fetch enable signal starts the program counter and the core will fetch an instruction. If this instruction is somehow undefined, the complete memory might be corrupted. Try to see if no incorrect instruction or data is being fetched.

yeah! i will try that! thank you for suggestion!

Enabling the fetch enable signal starts the program counter and the core will fetch an instruction. If this instruction is somehow undefined, the complete memory might be corrupted. Try to see if no incorrect instruction or data is being fetched.

i have tried that, but i don't understand what the wave means, the design runs then crushes, but these days i find the Uart in my design crushes at the very beginning so i think my problem may be caused by Uart

[barrydebruin]

if you look at the value of PWDATA when PSEL,PENABLE,PWRITE are all high (just before it crashes you will probably see that the value of PWDATA is (its not visible in the trace) 0xzzzzz...xxxxxxxx.

This implies that the core writes an undefined byte (character) to the UART controller. This byte is stored in dmem (the whole string "hello world!!!" actually), loaded onto the stack at the start of the program, and from the stack written to the UART controller. I assume that you maybe did modify the size of your DMEM, and did not change the linker script (i.e. sw/ref/riscv.common.ld)?

This simulation indicates to me that the hello-world functionality is there (the instruction memory), but that the data from the data memory is incorrect.

Maybe you could check the RTL simulation from hello-world and look at what is send to the UART controller (it should be "hello world!!!"). From there on you can look at the end of the data memory to see that its correctly stored and retrieved from the stack. The same behavior should happen in your netlist. If not, you have changed something.

[65nmCMOS]

if you look at the value of PWDATA when PSEL,PENABLE,PWRITE are all high (just before it crashes you will probably see that the value of PWDATA is (its not visible in the trace) 0xzzzzz...xxxxxxxx.

This implies that the core writes an undefined byte (character) to the UART controller. This byte is stored in dmem (the whole string "hello world!!!" actually), loaded onto the stack at the start of the program, and from the stack written to the UART controller. I assume that you maybe did modify the size of your DMEM, and did not change the linker script (i.e. sw/ref/riscv.common.ld)?

This simulation indicates to me that the hello-world functionality is there (the instruction memory), but that the data from the data memory is incorrect.

Maybe you could check the RTL simulation from hello-world and look at what is send to the UART controller (it should be "hello world!!!"). From there on you can look at the end of the data memory to see that its correctly stored and retrieved from the stack. The same behavior should happen in your netlist. If not, you have changed something.

we checked the rtl simulation for both the original pulpino and the one we added our own sp_ram. for our own code, we can print out "helloworld!!!" but our waves are different from original waves, there are some warning showing: Illegal instruction (core 0) at PC 0x6c6c6548, before the helloworld was printed. so maybe just print "helloworld!!!" is not enough? we need make sure every waves are totally the same with origional pulpino?

[65nmCMOS]

if you look at the value of PWDATA when PSEL,PENABLE,PWRITE are all high (just before it crashes you will probably see that the value of PWDATA is (its not visible in the trace) 0xzzzzz...xxxxxxxx.

This implies that the core writes an undefined byte (character) to the UART controller. This byte is stored in dmem (the whole string "hello world!!!" actually), loaded onto the stack at the start of the program, and from the stack written to the UART controller. I assume that you maybe did modify the size of your DMEM, and did not change the linker script (i.e. sw/ref/riscv.common.ld)?

This simulation indicates to me that the hello-world functionality is there (the instruction memory), but that the data from the data memory is incorrect.

Maybe you could check the RTL simulation from hello-world and look at what is send to the UART controller (it should be "hello world!!!"). From there on you can look at the end of the data memory to see that its correctly stored and retrieved from the stack. The same behavior should happen in your netlist. If not, you have changed something.

Hi! it is true that my ram has some problems, now i have made my waves of RTL simulation totally the same with orginal code, but when i doing post-synthesis simulation, it still breaks at the same point, i put the waves of uart, data ram and instr ram together and find that uart breaks first, then my ram breaks(about five clock cycles after uart breaks).

I have checked the peripherial.sv and found that there is a if-else statement for uart(if verilator....else....). and for post-synthesis, it runs the uart under the condition: "verilator", but in the config.sv, there is a sentence：always define ASIC when we do a synthesis run. Should i change verilator to ASIC? (i have tried that before, when i change verilator to ASIC, the synthesis will choose the uart under the condition:"else") and how to change that if i need to do so?

[phuong2403]

@65nmCMOS, Hi, I meet the same problem. Can I ask if you have already solved it? do you have any recommendations, please?

[65nmCMOS]

Sorry, i failed to solve the problem, i work Here for three month and find nothing

phuong2403 @.***> 于 2021年4月16日周五 上午11:33写道：

@65nmCMOS https://github.com/65nmCMOS, Hi, I meet the same problem. Can I ask if you have already solved it? do you have any recommendations, please?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pulp-platform/pulpino/issues/345#issuecomment-821050394, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOPPBIETICG3SO4ZKP53DBTTI776LANCNFSM4NGG6Z4Q .

[dasbacete]

Hi, same issue here. Did anybody manage to solved it? I would appreciate if some one could help us.

[gautschimi]

If you get an illegal instruction it means that something is wrong with your instruction/data memory. (or interface to the core)

either the memory is not correctly initialized before you start the program, or you have a problem with your simulation setup (different delay modes in rtl and macrocell or something like this)

I would probe the signals between core and instruction/data memory to see whats going wrong. (shortly before the illegal instruction occurs)

It could be that you read from an uninitialized memory location (X). and then the Xs propagate through the whole design and corrupt everything.