Skip to main content
added 314 characters in body
Source Link
K_T
  • 185
  • 6

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI in some way, as the FPGA must be using SPI to set its configuration data from the flash.

I.e. the flash is working to do re-configurations on the FPGA, but not to do the operation above - and so it seems that it should be a verilog issue on the software side rather than a hardware issue at the physical layer.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation, and not the physical hardware of the device?

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation, and not the physical hardware of the device?

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI in some way, as the FPGA must be using SPI to set its configuration data from the flash.

I.e. the flash is working to do re-configurations on the FPGA, but not to do the operation above - and so it seems that it should be a verilog issue on the software side rather than a hardware issue at the physical layer.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation, and not the physical hardware of the device?

added 47 characters in body
Source Link
K_T
  • 185
  • 6

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation, and not the physical hardware of the device?

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation?

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation, and not the physical hardware of the device?

added 15 characters in body
Source Link
K_T
  • 185
  • 6

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation?

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation?

From my previous post, I think I understand correctly the electronics side of the Read Manufacturer and Device ID Signal (Figure 11-1) Operation.

My current implementation of the operation on the FPGA does not return the expected response on the SO line - there is a discrepancy:

Instead of the expected response:

  • hex: 1F, 85, 01,

I am seeing:

  • hex: 00, 00, 00.

So now I want to narrow down the cause of this issue.

My hypothesis is that it is likely an issue with the Verilog implementation of the operation, as the issue seems unlikely to be a fault at the physical layer.

Why? Because the FPGA configuration is loaded to/from the first three 64kb of flash memory, and when I try compiling and uploading the customer example configs, the FPGA works well (buttons/leds are responding as expected). This suggests that the Flash and FPGA are at least able to communicate via SPI.

Would I then be correct in deducing from these facts that only thing that could cause this response discrepancy is the Verilog implementation of the operation?

added 46 characters in body
Source Link
K_T
  • 185
  • 6
Loading
added 213 characters in body
Source Link
K_T
  • 185
  • 6
Loading
Source Link
K_T
  • 185
  • 6
Loading