You are not logged in.
Hi,
I created an own core (with some ports and memory mapped registers) that I want to make accessible from CPU low and high. I attached it to the shared AXI in 80211Design 1.3.0 and 1.4.0, but with no success. Software reads wrong values and cannot write values to the registers. I've enabled mb_low and mb_high to be masters for that core in XPS (similar to your pre-configured w3_userio core) and took care of a correct address range, i.e. non-overlapping with other cores. As soon as I connect it to either of the dedicated AXI buses, SW can successfully read and write values.
Do you have any hint on what I may have misconfigured?
Thanks
Christian
Last edited by Christian (2016-Feb-03 07:15:43)
Offline
Exactly what address are you using for the peripheral?
To have a peripheral on the shared AXI interconnect, the address must be between 0x8000_0000 and 0xFFFF_FFFF. See this post for more information.
Offline
we placed it at 0x8200_0000. Interestingly enough, having it on CPU low axi at the same address also works. I'll test around and try to reconfirm.
On a side note/question: one of the purposes of the core is to replace the UART dipswitch determination with a register based determination. In general this approach works, however I noticed a considerable amount of strange outputs on the terminal (especially shortly after boot a lot of the chars go missing, but no "wrong" symbols). I have the impression, that there is no consistent signal driven out of the core while booting up the node. What was the exact reason that you tied the uart to a dipsw?
Last edited by Christian (2016-Feb-03 10:32:17)
Offline
we placed it at 0x8200_0000. Interestingly enough, having it on CPU low axi at the same address also works. I'll test around and try to reconfirm.
Strange. Make sure you haven't changed the CPU configuration. In the MHS file, for mb_low and mb_high you should see the following parameters:
... PARAMETER C_USE_DCACHE = 1 PARAMETER C_USE_ICACHE = 0 ... PARAMETER C_DCACHE_BASEADDR = 0x80000000 PARAMETER C_DCACHE_HIGHADDR = 0xffffffff PARAMETER C_DCACHE_ALWAYS_USED = 1 ...
This indicates that each CPU will use the M_AXI_DC port for accesses with addresses in the range 0x8000_0000 - 0xFFFF_FFFF (and all other accesses will use the M_AXI_DP port).
What was the exact reason that you tied the uart to a dips?
There is only one USB/UART output. However, there are two CPUs that can print debug / status messages. Therefore, we wanted an easy way to toggle between the CPUs that was easily configurable. A dip switch seemed like a logical choice since it was easy to physically look at the node and determine what messages were being printed and change those messages during execution that did not affect any run-time code.
On a side note/question: one of the purposes of the core is to replace the UART dipswitch determination with a register based determination. In general this approach works, however I noticed a considerable amount of strange outputs on the terminal (especially shortly after boot a lot of the chars go missing, but no "wrong" symbols). I have the impression, that there is no consistent signal driven out of the core while booting up the node.
What are you writing your new module in? Straight verilog or are you using System Generator? Given that what you are trying to do is straight-forward, I would suggest that you should just write everything in verilog since it is a lot easier to control all of the conditions before / during / after reset. Also, it might make sense to just modify the w3_userio_axi pcore to add an extra register that could be used for this. You just need to make sure you update all the MPD file with any new ports so that you can connect them in the MHS file (Note: If you modify an existing pcore, you should probably bump the version so that there are no ambiguities about what the build is using. This means copying to a new directory with he correct version number and updating the PAO file).
Offline
Keep in mind there's a second layer of mux on the UART output via the boot_io_mux core. This core allows the w3_clock_controller core to control the UART and IIC EEPROM immediately after FPGA configuration. The w3_clock_controller core reads values from the EEPROM to configuration the clock buffers and prints its status to the UART. Once the clock configuration state machine is finishes the boot_io_mux switches the UART/EEPROM pins to their normal state (USB-UART connected to the uart_mux, EEPROM connected to the w3_iic_eeprom core).
If you want to control the uart_mux from software, it should be sufficient to connect the uart_mux.uart_sel port to a register bit. The easiest way would be to use a bit from the mb_high_sw_gpio axi_gpio instance. In the ref design port 1 of mb_high_sw_gpio only uses 4 bits for driving debug header pins. You could increase this to 5 bits and use the extra bit as the uart_mux.uart_sel control signal.
Offline
Thank you Eric and Patrick! You provided some interesting ideas.
I'll update the MHS file (which had other addresses for C_DCACHE_*ADDR. When opening the reference project, also the ethernet_axi bus is always listed as unmapped and has no address set. Just to confirm: I've set it to 0xb000_0000 and 0xb400_0000 and allocating 8M. Is that ok? I think it should be ok as it is not connected to the cpus?!
Offline
The C_DCACHE_BASEADDR param on both CPUs should be 0x80000000. Did you maybe click the Generate Addresses button in XPS? Unfortunately we've found this tool is not useful for dual-CPU designs. The address map in the 802.11 Ref Design is manually generated.
The unmapped addresses on the exernet_axi interconnect are ok (explanation here).
Offline
Yes, I clicked the generate addresses button as I was used to with the old designs. But that was the reason..
The only thing remaining is that I still have the impression that the uart output on the terminal is still affected by moving the uart selection to a register (as a noticeable amount of chars is missing at random positions in the print out)
But, thanks!
Offline