TEMPERATURE SENSOR IP in STRATIX10 SX , READ INCORRECT VALUE

[JonWay_C_Intel]

hi, what is the value that you are reading? what is the expected temperature?

did you try the design in the how to video. https://www.youtube.com/watch?v=E5TaTxuOmOY&t=4s

Try downloading all the files in the youtube description. Run it and see if you still see any unexpected results. FYI, the design was tested working.

[WGith]

Hi,

I have the same issue as RYang6. The Voltage IP works fine for me, but the temperature IP for the Stratix 10 PCIE eval board gives extrememly sporadic or very weird readings. I have watched the youtube video and made sure my code is correct for decoding. i.e. one of the readings i get is 0xf240

[JonWay_C_Intel]

Hi WGith,

Lets try this out:

1) can you use the exact design files in the youtube description. i want to Make sure we are on the same page and looking at the same design.

DOwnload the files and all the tcl scripts. Run it and see if you are getting the same results as shown in the youtube.

2) If you still see the sporadic problem, elaborate further what is the device P/N you are using. what quartus version are you using? how many boards tested & how many boards are seeing this problem? what is the expected temperature? how sporadic is the reading? does this happen to all channel or certain channels? can this be recovered by resetting the IP/ power cycling device?

I will more details in order to help you.

[WGith]

So I tried the Intel project and that did work. SO I dug deeper and opened the s10temp.ip that was included in that project. The ip opens the block symbol for that design has cmd_data of (6:0). That really surprised me as I know the temperature ip auto generated by quartus 18.0 and 18.1 has cmd_data at (8:0). Now this may not make a difference, but it IS different.

I am next going to try and build my design using the .ip from the Intel project and see if that works. If it does, then something is definitely wrong with the current IP block.

[JonWay_C_Intel]

Hi @WGith​ 

Alternatively, use the Intel design that worked, upgrade the IP to 18.0 or 18.1. Confirm the bus width. Test it again. I think it is easier to debug from a working design.

Regards, jonway

[WGith]

Hi,

Here is my update. Using the IP from the working design with my code did work.....KIND OF. There is definitely something wrong with the IP block(S) and needs to be addressed soon. Using the working design IP, I was able to see the temperature for what I believe was the core logic temperature, but not the other Temperature I was requesting. Also I now see NONE of the voltage readings from the ADC, whereas before this was not an issue. So mixing the working temp IP with the working Voltage IP from Quartus do NOT work together. I had signal tap setup and in looking at the voltage output which is another block, I actually saw 2 of the voltage monitors sending data, but not int he voltage format, but in the temperature format. When I calculated them, these values appear to be valid, but slightly different temperautre readings than the temp IP block.

Now I know that the Voltage and Temperature IP all contact the ADC inside the FPGA. What I want to be able to do is have BOTH the Voltage and Temperature readings from the ADC. So, I'm not sure how to do that. I instantiated both blocks but they don't seem to be working together properly. Does the code to the ADC know to arbitrate between the two IP blocks correctly?

I will continue to work on this, but it would be good to have someone from Intel start looking at this in depth. I have using the S10 H-tile evaluation board.

Thank you,

Will

[WGith]

Hi,

Do I need to arbitrate between the Voltage IP and the Temperature IP blocks, meaning that only one of them can assert cmd_valid at a time, or does the IP blocks internally auto arbitrate?

I need to be able to find a combination of IP blocks that work so I can access both the voltage and temperature readings.

Any assistance you can provide in escalating this would be appreciated as there is definitely something not right with the current IP blocks.

[JonWay_C_Intel]

Hi @WGith,

Yes, you need to arbitrate the cmd_valid between both Voltage IP and Temperature IP. No, it doesnt auto arbitrate.

Regarding your earlier concern on additional 2 bits in the cmd_data. [6:0] to [8:0}. In 18.1, 2 channels are added for temperature sensing at HBM (for devices that supports it).

I hope this clears your doubt.

[WGith]

Thank you. I never saw this documented anywhere. I will give it a try. Will

[WGith]

Hi,

I appreciate the help you have been giving me, but there is still something not right with the design. I have updated the design to poll the voltage monitor ip and then the temperature ip and keep looping on that. This still doesn't work for me. I will try to find some time to generate a signaltap enabled image to give you additional information.

[JonWay_C_Intel]

Hi @Wgith,

Sure, keep me posted. Signaltaps would be helpful. Just a note, the SDM can only process 1 IP at a time. So you have to make sure both IPs is back at cmd_ready, and only assert cmd_valid for one of the the IPs (not both together). Hope this helps.

[WGith]

Hi,

Still having issues. I made sure to one enable one of the IP blocks at a time. I also have added very large waits between accesses. I have attached a zip file with my simple vhdl state machine that access the voltage and temperature IPs. I also included 4 signaltap screenshots which shows how I enable the voltage and temperature requests and how it shows the IP responding as expected, and then 2 screenshots which shows for the voltage IP it responds with 4 and not 5 requests and also the 2 requests that actually respond with data that is not zero is formatted in a way that is for temperature readings, not voltage readings. And then for the temperature IP response, I do get two responses, but the second response valid as you can see is 2 clock cycles too late for the second valid data response.

So, the temperature IP is almost working as expected, but the voltage IP is completely responding in a manner that makes no sense.

Note that I am running the IP blocks at 100 Mhz.

[JonWay_C_Intel]

Hi @WGith​ ,

Let me take a look at the STP, and I will get back to you.

It would be great if you could share with the me the simple design QAR.

Could I confirm with you that these IPs were working correctly individually?

[JonWay_C_Intel]

Hi @WGith​ 

I took a look at the STP, for voltage sensor, i see you set to read channel 2,3,4,6,9

The results came back for 2,3,4,6...9 is missing. Is that what you meant by "Voltage IP is responding in a manner that makes no sense"? If not, please elaborate.

Btw, what device PN are you using?

Could you share with me the simple design QAR.

[WGith]

JwChin, There are a couple things to note. 1. Yes the Voltage IP only responded with 4 out of 5 requests. 2. The results it did send back are completely incorrect. Channel 2 responded with a voltage of zero, Channel 3 responded with a voltage I can’t read from the signaltap, but I know it was incorrect. Channel 4 responded with 0x1D00 which in voltage conversion equals 0.113 volts, but in temperature conversion equal 29C, which makes sense. The last channel read 6 equals zero as well. There is no way I could be reading from the FPGA, if these were the actual voltages. It seems like the two blocks (temperature / voltage) get confused and the temperature data somehow outputs on the voltage request. We are using the following part: 1SG280HU2F50E2VGS1 It is a ES sample on the H-tile Intel Eval board. Is there an errata regarding this? I do not have a small QAR project at the moment, just our full design. I will try and find time to optimize everything out and send you a smaller version to test with. Thank you, --Will

[JonWay_C_Intel]

@WGith,

There is no errata regarding this.

When you have a simple design, send it over, i can help to check further.

[JonWay_C_Intel]

Hi @WGith​ 

I modified the youtube design example to make it simpler. Upgraded the IP to 18.1, recompiled. Attached file. can you test it?

In System Console, run the below scripts:

# Setting up ISSP

set issp_index 0

set issp [lindex [get_service_paths issp] 0]

set claimed_issp [claim_service issp $issp mylib]

#{cmd_valid, reset, cmd_data [6:0]}

issp_write_source_data $claimed_issp 0x17F

#0x80 TSinactive

#0x17F active

set issp_index 1

set isspVS [lindex [get_service_paths issp] 1]

set claimed_isspVS [claim_service issp $isspVS mylib1]

#{cmd_validVS, reset_VS, cmd_dataVS [15:0]}

issp_write_source_data $claimed_isspVS 0x2025C

#0x10000 VSinactive 

#0x2025C VSactive

[JonWay_C_Intel]

posted a file.

[WGith]

I haven't had a chance to look at your new example yet. It maybe a while, but here is an archived project of mine. In this design, teh voltage IP appears to work, but the temperature IP is not.

[WGith]

posted a file.