PULPino inplace CM3 core in SYSTEM

[thotaraghava]

HI all,

I have replaced cortex-m3 with PULPino in my system which is under test. I have generated slm files for "helloworld" testcase. In my system, we have only one ROM in which both instruction and data should sit. So, I have put instruction data on top of the ROM and data just below that. I am not using "peripherals" block, as we dont have such peripherals in our system. So, I am trying to drive boot_addr_i.

@FrancescoConti mentioned on other ticket that the given boot code is specific to pulpino stand alone platform, it needs to be changed for other cases.

I have following questions.

1. How this boot code should be changed in current scenario. Absolutely, its gray area for me.
2. What should I drive boot_addr_i.

Thanks,

[quangdaovu]

Why do you want to touch boot_code? Isn't make helloworld.vsim enough????

[quangdaovu]

1. You don't simulate PULPino alone but the test scenario is still the same. Just follow whatever provided testbench does. Software needs strict address space relationship. Your generated instruction and data will only work with instruction RAM and data RAM, if you messed up the address space then it won't work at all. In your case, you just print out instructions and data then copy paste them together to make your ROM then surely your software will NEVER work.

If you don't understand how the system works then just follow the normal procedure, don't be too creative.

2. Clue: Read README about regenerate the bootcode, modify boot_code.c, generate new boot_code.sv and change MEM_LOAD method to STANDALONE.

[FrancescoConti]

@quangdaovu when he says he took PULPino, he actually means mainly the RISCY core. He does not use a PULPino system, apparently. And he uses the phrase "standalone PULPino" to mean the opposite of "standalone", that is a RISCY integrated in a PULPino system. He did the same in many many other issues he opened.

I reiterate: the boot code depends on fundamental system-dependent parameters such as the memory map. Of course you can reuse part (maybe most) of the current boot code, but you'll have to adapt it significantly and we have no clue how (because we have no clue about your system).

Given that you're replacing an expensive ARM IP, I suppose you're working in an organization which most likely has documented the previous ARM-based system. You can use:

1. that documentation
2. the previous ARM boot code
3. the PULPino RISC-V boot code

to create a new boot code for your system. More than that, we cannot possibly help you.

[FrancescoConti]

So to handle the problem on HW, you have to:

1. check that your instruction / data interfaces are appropriately connected to your memory (or your interconnect)
2. modify the boot address by driving the primary RISCY input boot_addr_i appropriately: https://github.com/pulp-platform/riscv/blob/26875bef48c3d051ef414d6a0dfec0def8b7c2f3/riscv_core.sv#L65 e.g. if your reset vector will be located 0xbeef0000, you drive boot_addr_i with 32'hbeef0000. This address depends on your system memory map. I don't think you need to remove anything in riscv_prefetch_buffer.sv to be honest, this is used to compute the next address for prefetching (necessary to make compressed instructions work).

That said, I'm not sure that I understand what is your problem - it seems to me that you already have these 2 points going. Do you see the wrong instruction being fetched/executed?

[zarubaf]

fetch_enable is high?

[FrancescoConti]

Two things:

1. as the name suggests, you must drive fetch_enable to 1'b1 to enable the core to fetch instructions and hence start it.
2. in general, you must always drive all primary inputs to something. You cannot leave them undriven, or the core might enter an undetermined state.

If you are unsure what an input does, have a look how it is tied in PULPino.

[thotaraghava]

ok. Sure.

[zarubaf]

Pls read the RISCV datasheet.

[FrancescoConti]

In this case I must say the datasheet is not too clear (or rather, takes a few things for granted). I copy-paste and modify from the docs for hwpe-stream, which uses a very similar protocol. "Master" is the core in this context, "slave" is e.g. the memory.

Signal	Size	Description	Direction
req	1 bit	Handshake request signal (1=asserted).	Master -> Slave
gnt	1 bit	Handshake grant signal (1=asserted).	Slave -> Master
add	32 bit	Word-aligned memory address.	Master -> Slave
we	1 bit	Write enable signal (1=write, 0=read).	Master -> Slave
be	4 bit	Byte enable signal (1=valid byte).	Master -> Slave
wdata	32 bit	Data word to be stored.	Master -> Slave
rdata	32 bit	Loaded data word.	Slave -> Master
rvalid	1 bit	Valid loaded data word (1=asserted).	Slave -> Master

req and gnt are used to handshake transactions between masters and slaves. Transactions are subject to the following rules:

1. A valid handshake occurs in the cycle when both req and gnt are asserted (i.e., transactions happen in the cycle when req and gnt are 1). This is true for both write and read transactions.
2. The rvalid signal must be asserted in the cycle in which rdata is valid (for loads) or in the cycle in which the write transaction is concluded from the point of view of the master (for stores). For memories with one cycle of latency, this is always the cycle after the handshake happens.
3. The assertion of req (transition 0->1) cannot depend combinationally on the state of gnt. On the other hand, the assertion of gnt (transition 0->1) can depend combinationally on the state of req (and typically it does). This rule avoids deadlocks in ping-pong logic.

[thotaraghava]

Actually, I was reading datasheet which is in github. @zarubaf pointed datasheet which is very clear in all aspects.

[zarubaf]

@FrancescoConti The datasheet is more than clear in all aspects. Even with timing diagrams.

[gautschimi]

if you don't know how to interface the processor core I strongly suggest to first look at the full pulpino system, simulate the "helloworld" there and then observe the interfaces, etc. this will give you much more insight than asking random questions and wasting our time.

if you don't want to do that have a look at the following three points:

1. verify that all inputs of the core driven by meaningful values

2. when the core requests an instruction, check if you give back a gnt, rvalid and the instruction. and if the core asks for more instructions after this.

3. maybe a screenshot of your interface would help

On 03/02/2018 02:43 PM, thotaraghava wrote:

HI,

Though I am driving boot_addr_i with 32'd0, after reset core_instr_addr is pointing to 32'h00000004 and core_instr_req is asserted when core_instr_addr is 32'h00000080.

And I do not see any core_lsu_req here. Is it expected for "helloworld" testcase.

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pulp-platform/pulpino/issues/179#issuecomment-369924002, or mute the thread https://github.com/notifications/unsubscribe-auth/ARsRnSymLMLPG2MgbjUVE9zNy_79jROBks5taUyegaJpZM4SUm5K.

[gautschimi]

how do you connect two interfaces to one ROM? and where does your data interface write to? you might want to use a WOM http://repeater-builder.com/molotora/gontor/25120-bw.pdf aswell.

no seriously, simulate pulpino as it is and first study the design before you go and modify anything. your knowledge is not big enough to do such simple modifications. you will never succeed if you don't invest time on your own and first study processors and how they work

On 03/02/2018 05:20 PM, thotaraghava wrote:

I have copied instr and data to my one and only ROM. Above error message related to instr and data placement in ROM ? What should I do.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pulp-platform/pulpino/issues/179#issuecomment-369970535, or mute the thread https://github.com/notifications/unsubscribe-auth/ARsRnc80LFybFJpYdz4_ggLPaGj83hIaks5taXFJgaJpZM4SUm5K.

[FrancescoConti]

Could not see any comment on this yet. !!!

This is not the attitude that is going to get any answer anywhere on the internet. You know, we have a job, and this job is not centered on answering questions on GitHub.

In my scenario, when I load all my instr and data into ROM, I am getting below error while simulating. 504474000000: Illegal instruction (core 0) at PC 0x000019ba: Can anybody guess, where was the issue and how I should have dumped data in ROM.

The key word here is guess as this is all we can do. What the simulator is telling is that @0x000019ba you have an illegal instruction.

[thotaraghava]

Hi all,

Could you please point me linker script used in this PULPino setup. I am also searching from my end.

I could see in sw/ref directory. Please confirm.

crt0_boot.S and crt0_riscv.S are linker scripts ?

thanks

[FrancescoConti]

crt0.riscv.S is a boot script. link.common.ld is a linker script.

[nasahlpa]

yes, there should be a message printed on UART - try to run it in ModelSim with make helloworld.vsim, there you see the output message

[FrancescoConti]

The boot script sets up the minimal runtime stuff necessary to use C compiled code (basically, zeroes out a few data structures and creates the stack). It is therefore quite essential. Regarding any changes, in particular to the linker script, they depend on your system not on PULPino. For info on how to manage linker scripts, see here: https://sourceware.org/binutils/docs/ld/Scripts.html#Scripts

Regarding the various stim.txt files, they use indeed the ADDRESS_DATA (32 bit address, underscore, 32 bit data) format. Ignoring the address is not a good idea, as the data words are not necessarily contiguous...

[thotaraghava]

Hi all,

 For helloworld testcase, I have dumped instructions and data into RAMs.
 To my surprise, simulation is running for more time. Not ending.
  In terminal, I could see message "setfile Done".
Any clue why its been like that.

Thanks,

[thotaraghava]

Is my pre-loading is okay ? I suspect that.

Thanks,