Unknown message type/value = 36

[Marcelo Ruaro]

Hi,

I have been simulating OpenPiton in very simple scenarios.

Happens that sometime there is a message type with value 8'd36, which is not listed in table 6 of OpenPiton Microarchictetural Specification document.

I did a message header decoder tool which breaks the header's fields. You can check the full header value looking to figure below:

Someone has a glue about what this message value could represent?

Best,

Marcelo

[Marcelo Ruaro]

Hi,

Just to register that I found where the type of message. It is described in piton/design/includes/define.tmp.h

//Requests from L15 to L2

// Should always make #0 an error

`define MSG_TYPE_RESERVED 8'd0

`define MSG_TYPE_LOAD_REQ 8'd31

`define MSG_TYPE_PREFETCH_REQ 8'd1

`define MSG_TYPE_STORE_REQ 8'd2

`define MSG_TYPE_BLK_STORE_REQ 8'd3

`define MSG_TYPE_BLKINIT_STORE_REQ 8'd4

`define MSG_TYPE_CAS_REQ 8'd5

`define MSG_TYPE_CAS_P1_REQ 8'd6

//condition satisfied

`define MSG_TYPE_CAS_P2Y_REQ 8'd7

//condition not satisfied

`define MSG_TYPE_CAS_P2N_REQ 8'd8

//Both SWAP and LDSTUB are the same for L2

`define MSG_TYPE_SWAP_REQ 8'd9

`define MSG_TYPE_SWAP_P1_REQ 8'd10

`define MSG_TYPE_SWAP_P2_REQ 8'd11

`define MSG_TYPE_WB_REQ 8'd12

`define MSG_TYPE_WBGUARD_REQ 8'd13

`define MSG_TYPE_NC_LOAD_REQ 8'd14

`define MSG_TYPE_NC_STORE_REQ 8'd15

`define MSG_TYPE_INTERRUPT_FWD 8'd32

//RISC-V AMO requests

`define MSG_TYPE_AMO_ADD_REQ 8'd36

`define MSG_TYPE_AMO_AND_REQ 8'd37

`define MSG_TYPE_AMO_OR_REQ 8'd38

`define MSG_TYPE_AMO_XOR_REQ 8'd39

`define MSG_TYPE_AMO_MAX_REQ 8'd40

`define MSG_TYPE_AMO_MAXU_REQ 8'd41

`define MSG_TYPE_AMO_MIN_REQ 8'd42

`define MSG_TYPE_AMO_MINU_REQ 8'd43

//RISC-V AMO L2-internal phase 1

`define MSG_TYPE_AMO_ADD_P1_REQ 8'd44

`define MSG_TYPE_AMO_AND_P1_REQ 8'd45

`define MSG_TYPE_AMO_OR_P1_REQ 8'd46

`define MSG_TYPE_AMO_XOR_P1_REQ 8'd47

`define MSG_TYPE_AMO_MAX_P1_REQ 8'd48

`define MSG_TYPE_AMO_MAXU_P1_REQ 8'd49

`define MSG_TYPE_AMO_MIN_P1_REQ 8'd50

`define MSG_TYPE_AMO_MINU_P1_REQ 8'd51

//RISC-V AMO L2-internal phase 2

`define MSG_TYPE_AMO_ADD_P2_REQ 8'd52

`define MSG_TYPE_AMO_AND_P2_REQ 8'd53

`define MSG_TYPE_AMO_OR_P2_REQ 8'd54

`define MSG_TYPE_AMO_XOR_P2_REQ 8'd55

`define MSG_TYPE_AMO_MAX_P2_REQ 8'd56

`define MSG_TYPE_AMO_MAXU_P2_REQ 8'd57

`define MSG_TYPE_AMO_MIN_P2_REQ 8'd58

`define MSG_TYPE_AMO_MINU_P2_REQ 8'd59

`define MSG_TYPE_LR_REQ 8'd60

...

[Jonathan Balkind]

Hi Marcelo,

Looks like you got this. Do note that the _P1_REQ and _P2_REQ types are L2 internal so you shouldn't see them on the NoC (and they could be used for other purposes on the NoC later). This GUI you're making looks really useful!

Thanks,

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/1e9220c3-e9c6-4d57-8263-4f02dde81221n%40googlegroups.com.

[Marcelo Ruaro]

Thanks,

About this GUI tool, it makes part of a bigger GUI project, which aims to port the Memphis graphical debugger to OpenPiton.

I just uploaded this video showing the V1 of the GUI running in OpenPiton:

https://www.youtube.com/watch?v=nFA5y7Bjpa8&ab_channel=MarceloRuaro

I am open to further discussion if your group is interested in integrate this tool to the project (in Memphis it has shown valuable to allow a comprehensive overview of many-core transactions).

Memphis graphical debugger papers: 
DOI: 10.1109/ISCAS.2014.6865688
DOI: 10.1109/ICECS.2016.7841277

Best,

Marcelo

You received this message because you are subscribed to a topic in the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpiton/r-cNi_WVxYI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/CAJm4tWaf0zHtreutjLVLD_eGyq%2BQg1odJF6Vh52jyZPZbkg5KA%40mail.gmail.com.

--

Ph.D. in Computer Science (Systems-on-Chip)

Scholar: https://scholar.google.com/citations?user=Iv9MppsAAAAJ&hl=en

CV Lattes: http://lattes.cnpq.br/8918320689728511

Tel.: +55 51 982685190

[Jonathan Balkind]

Wow Marcelo this is really interesting! We've had discussions in the past about having this kind of monitoring but we never had anyone who was sufficiently interested in doing the kind of UI programming needed for it. I think depending on the kind of research modifications that one is trying to make, this could be extremely useful. Does this debugger read out using some kind of cross-module refs in the RTL or does it parse from the textual logs?

Thanks,

Jon

[Marcelo Ruaro]

Hi Jonathan,

The tool just reads logs from the NoC routers. A simple RTL change inside the monitoring_newtork... file is necessary to dump the packets and its information. Just based on the packets's information it is possible to collect and interpret a big amount of information (cache behavior, communication load, running threads, etc) which can help to draw a comprehensive behavior of the many-core.

This graphical/comprehensive view gives a tremendous debugging power compared to waveform and logs.

Best,

Marcelo

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/CAJm4tWZuyO-4-7oEHqqZw%3DLZEDM0KDSSo_o3zQ%3DCz%2BGgJjWFCw%40mail.gmail.com.