Hi Colin,
Thanks for the hint.
With "4clk" it still doesn't work. But with "5clk" it does! :)
Could you please quickly explain what we did now and how it will influence the software running on the system?
Thank you!!
Simon
Secure boot using AES module not working
Hi Simon,
Great news that your device will now boot!
The network setup process works differently in secure boot than it does with un-secure boot...
In un-secure boot, the configuration of the slave nodes links is entirely driven by the master boot node. The master will take responsibility for setting both the width and speed of the links. It deliberately sets the link speed very slow on the first pass of configuration to allow for the fact that the slave nodes are operating much slower speed than the master as the pll register on the slave is not yet written. Once the pll registers are written the boot process then upgrades the links to the speed as defined in the XN file. Note that link delays of 0,1 would never work for the internal links on the L16. Looking at the SLICEKIT-L16.xn that ships with the tools (14.2.3) I note that the internal link delays are set to 2clk. In this scenario the device will boot as expected.
In secure boot, the slave node has it's OTP burned with a secure boot from channels bootloader. XBURN will patch into this bootloader the link width and speed as defined in the XN. The benefit here is that the network setup process no longer needs to configure the links on the slave node as this is already done! However, the secure boot process does not take into account that the slave node has not yet had its PLL register written. If you look at your xlreg output you will note that the master node is running at ~500MHz while the slave node is still only running at ~100MHz. This means that the slave node is missing the transitions on the links and hence you have a boot failure. We got round this by increasing the delays on your links in your XN which effectively means all your throughput on those links is slowed down. Unfortunately, once the pll register is written on the slave node, there is no mechanism to change the link speeds to run faster again within the boot process, they are running at the speed now defined in your XN! I have raised this as an issue to be considered for a future release of the tools.
You can get a bit more information on xlink performance for the L-series here: https://www.xmos.com/download/private/X ... 2.0%29.pdf
Best Wishes,
Colin
Great news that your device will now boot!
The network setup process works differently in secure boot than it does with un-secure boot...
In un-secure boot, the configuration of the slave nodes links is entirely driven by the master boot node. The master will take responsibility for setting both the width and speed of the links. It deliberately sets the link speed very slow on the first pass of configuration to allow for the fact that the slave nodes are operating much slower speed than the master as the pll register on the slave is not yet written. Once the pll registers are written the boot process then upgrades the links to the speed as defined in the XN file. Note that link delays of 0,1 would never work for the internal links on the L16. Looking at the SLICEKIT-L16.xn that ships with the tools (14.2.3) I note that the internal link delays are set to 2clk. In this scenario the device will boot as expected.
In secure boot, the slave node has it's OTP burned with a secure boot from channels bootloader. XBURN will patch into this bootloader the link width and speed as defined in the XN. The benefit here is that the network setup process no longer needs to configure the links on the slave node as this is already done! However, the secure boot process does not take into account that the slave node has not yet had its PLL register written. If you look at your xlreg output you will note that the master node is running at ~500MHz while the slave node is still only running at ~100MHz. This means that the slave node is missing the transitions on the links and hence you have a boot failure. We got round this by increasing the delays on your links in your XN which effectively means all your throughput on those links is slowed down. Unfortunately, once the pll register is written on the slave node, there is no mechanism to change the link speeds to run faster again within the boot process, they are running at the speed now defined in your XN! I have raised this as an issue to be considered for a future release of the tools.
You can get a bit more information on xlink performance for the L-series here: https://www.xmos.com/download/private/X ... 2.0%29.pdf
Best Wishes,
Colin
Hi Colin,
Great, thanks for the explanation!
I went over the document provided and assume that we are talking about the "Inter-Symbol Delay", right?
If so, the 5clk delay introduced will mean that between every "symbol" we are sending over a channel/interface we will have the link wait for 5clks, which would be 10ns @ 500MHz. To understand the implications of this it would be good to know how many transferred bits a "symbol" is...?
I also didn't quite get this:
Thanks a lot!
Simon
Great, thanks for the explanation!
I went over the document provided and assume that we are talking about the "Inter-Symbol Delay", right?
If so, the 5clk delay introduced will mean that between every "symbol" we are sending over a channel/interface we will have the link wait for 5clks, which would be 10ns @ 500MHz. To understand the implications of this it would be good to know how many transferred bits a "symbol" is...?
I also didn't quite get this:
Our devices are perfectly working with the 0,1 setup we had before changing to 5clk when no AES is used, which contradicts a bit with your statement. Could you please clarify?Note that link delays of 0,1 would never work for the internal links on the L16.
Thanks a lot!
Simon
Hi Colin,
An additional issue, I can't get our C22 (2xL16 on one PCB) to boot - no matter how much I increase the delay (tested up to 20clk).
Could you take a look at the XN as well as the xlreg output?
Thanks,
Simon
An additional issue, I can't get our C22 (2xL16 on one PCB) to boot - no matter how much I increase the delay (tested up to 20clk).
Could you take a look at the XN as well as the xlreg output?
Thanks,
Simon
- Attachments
-
- xlreg_C22.txt
- (4.42 KiB) Downloaded 272 times
xlreg_C22.txt- (4.42 KiB) Downloaded 272 times
-
- SOMANET-C22.xn
- (5.08 KiB) Downloaded 280 times
- SOMANET-C22.xn
- (5.08 KiB) Downloaded 280 times
Hi Simon,
There are 2 bits per symbol for a 5-wire link, 1 bit per symbol for a 2-wire link (with 2 symbols overhead per token [byte] for the 2-wire link).
The receiving processor cannot receive faster than one symbol per clock plus some uncertainty for the electrical transmission. So on the transmitting side the spacing between symbols should never less than the clock period of the receiving node plus, say, 2 ns margin. Hence, if the receiving node runs at 100 MHz, the transmitting symbol distance should be no less than 12 ns. Receiving node at 500 MHz - fastest you can transmit is 4 ns between edges. You can get more information from this document: https://www.xmos.com/published/xconnect-architecture
I'm still looking into the link delays 0,1 issue. It seems I was wrong when I said the writing 2clk is the same as writing 1,1. This is true for the XS2 but not for the XS1. When writing 2clk for XS1 it is the same as writing 0,1. I'll look into this further and get back to you when I have more information.
Best Wishes
Colin.
There are 2 bits per symbol for a 5-wire link, 1 bit per symbol for a 2-wire link (with 2 symbols overhead per token [byte] for the 2-wire link).
The receiving processor cannot receive faster than one symbol per clock plus some uncertainty for the electrical transmission. So on the transmitting side the spacing between symbols should never less than the clock period of the receiving node plus, say, 2 ns margin. Hence, if the receiving node runs at 100 MHz, the transmitting symbol distance should be no less than 12 ns. Receiving node at 500 MHz - fastest you can transmit is 4 ns between edges. You can get more information from this document: https://www.xmos.com/published/xconnect-architecture
I'm still looking into the link delays 0,1 issue. It seems I was wrong when I said the writing 2clk is the same as writing 1,1. This is true for the XS2 but not for the XS1. When writing 2clk for XS1 it is the same as writing 0,1. I'll look into this further and get back to you when I have more information.
Best Wishes
Colin.
Hi Simon,
With regard to your C22 boot failure, I'd like to see the status of the links after all the secure bootloaders have run out of OTP but before any of the network setup code has run from the boot image. To do this we need to put a debug break into the network setup code. You can do this by adding the xflash option --swstup-debug-stop when programming the flash. This will insert an infinite while loop before the network setup code runs. If you can then do an xlreg dump at this point and send it over so I can take a look. Note you may need to erase flash before you can program again with this option.
Best Wishes
Colin.
With regard to your C22 boot failure, I'd like to see the status of the links after all the secure bootloaders have run out of OTP but before any of the network setup code has run from the boot image. To do this we need to put a debug break into the network setup code. You can do this by adding the xflash option --swstup-debug-stop when programming the flash. This will insert an infinite while loop before the network setup code runs. If you can then do an xlreg dump at this point and send it over so I can take a look. Note you may need to erase flash before you can program again with this option.
Best Wishes
Colin.
Hi Colin,
Please find the xlreg output attached. The XN-File with 20clk delay was used.
Thanks,
Simon
Please find the xlreg output attached. The XN-File with 20clk delay was used.
Thanks,
Simon
- Attachments
-
- 2016-12-01_XLREG_C22.txt
- (4.41 KiB) Downloaded 274 times
- 2016-12-01_XLREG_C22.txt
- (4.41 KiB) Downloaded 274 times
Hi Simon,
Your second boot failure on the C22 is a tools issue. Unfortunately the secure boot from channels bootloaders have not enabled all of the links they should have and therefore the master node does not have a complete network for to communicate with the slave nodes. I have found the root cause of this and put in a fix in XBURN for it.
I also hope to put in a fix for your first boot issue. The plan is to slow the links right down on the master node when it is talking to the slave nodes before the pll has been programmed on the slave nodes. Once this phase is complete the master can then throttle the links back up to the speed defined in the XN (2clk /0,1), thus allowing your application to run at the same speeds it would in non-secure boot.
I hope to have a 14.2.4 pre-release at some point next week. Would you be willing to test and verify that this release resolves your AES boot issues before it is put on general release? It will involve you having to burn the OTP on new devices.
With regard to the 2clk/0,1 issue, It is my understanding that running the links at this speed will work providing that all the temperature variations, voltage variations and capacitance etc is the same on both ends of the link, which in an L16 device should be the case as the links are internal to the package. We do not guarantee the links will run at this speed if there are any of these variations between the links, hence the external link used by xscope is running with 4,4 (6clk,5clk) in your XN.
Thanks and best wishes
Colin.
Your second boot failure on the C22 is a tools issue. Unfortunately the secure boot from channels bootloaders have not enabled all of the links they should have and therefore the master node does not have a complete network for to communicate with the slave nodes. I have found the root cause of this and put in a fix in XBURN for it.
I also hope to put in a fix for your first boot issue. The plan is to slow the links right down on the master node when it is talking to the slave nodes before the pll has been programmed on the slave nodes. Once this phase is complete the master can then throttle the links back up to the speed defined in the XN (2clk /0,1), thus allowing your application to run at the same speeds it would in non-secure boot.
I hope to have a 14.2.4 pre-release at some point next week. Would you be willing to test and verify that this release resolves your AES boot issues before it is put on general release? It will involve you having to burn the OTP on new devices.
With regard to the 2clk/0,1 issue, It is my understanding that running the links at this speed will work providing that all the temperature variations, voltage variations and capacitance etc is the same on both ends of the link, which in an L16 device should be the case as the links are internal to the package. We do not guarantee the links will run at this speed if there are any of these variations between the links, hence the external link used by xscope is running with 4,4 (6clk,5clk) in your XN.
Thanks and best wishes
Colin.
Hi Colin,
Of course, I'm happy to test drive the pre-release over here with new devices.
Could you quickly let me know what the difference between the two notations "x,x" and "xclk" is? In the latest documents I can only find the "clk" notation.
Thanks,
Simon
Of course, I'm happy to test drive the pre-release over here with new devices.
Could you quickly let me know what the difference between the two notations "x,x" and "xclk" is? In the latest documents I can only find the "clk" notation.
Thanks,
Simon
Hi Simon,
Writing 2clk,2clk (or just 2clk) is saying that you want 2clk periods between each inter token and 2clk periods between each intra token. This will then be translated internally to 0,1 on the XS1 and 1,1 on the XS2 which are the values that are needed to be written into the xlink config register to give you these clk period delays. It is preferred that the clk values are used rather than the actual register values as they are clearer in their intent.
Colin.
Writing 2clk,2clk (or just 2clk) is saying that you want 2clk periods between each inter token and 2clk periods between each intra token. This will then be translated internally to 0,1 on the XS1 and 1,1 on the XS2 which are the values that are needed to be written into the xlink config register to give you these clk period delays. It is preferred that the clk values are used rather than the actual register values as they are clearer in their intent.
Colin.