You are not logged in.
We're having problems when upgrading our XPS design from 9.1 to 10.1. Similar to your reference design 2x2 v5.2, we are using a plbv46 to plbv46 bridge, but we are also using BRAMs and the xps_intc v1.00.a. Why did you guys stop using these pcores?
The problem is that when and only when we add our custom physical layer pcores to the XPS project, the serial port would have problems displaying text. It would freeze up while printing text, usually at the same place in the code. Our pcores are connected to the slower, 40MHz bus, but the serial port is connected to the faster, 80MHz, primary bus, so it's a bit odd that they would interfere. Did you guys encounter issues with the serial port as well?
Offline
We switched from interrupts to polling in the reference design for two reasons:
(1)The latency in handling interrupts was big enough to be a bottleneck as our MAC implementation got faster. Polling registers directly in the PHY and timer removed a few levels of function calls.
(2)Every so often, our software design would hang for reasons we never identified directly. We even used the SDK's debugger to observe the state of the processor after a hang. It clearly indicated ISRs were involved, but we couldn't figure out why code execution stopped. Given (1), we punted on interrupts altogether.
One thing we did observe- if a core asserts an interrupt before the interrupt controller is fully setup, the results can be unpredictable. Maybe this is your problem too? Can you try holding every interrupt-generating core in reset until your code finishes setting up the interrupt controller?
Offline
We took your reference design and used that as a base system configuration for our pcores, and finally got it to work. In the process, we looked at WARPLab_2x2_v05_02_FPGAv1, OFDM_ReferenceDesign_FPGAv1_v14.1_public, and a basic one created using the Base System Builder.
We noticed that the mhs setup for some of the pcores are different, particularly that WarpLab's plbv46 is missing the line:
PORT SYS_Rst = sys_bus_reset
and both WarpLab's and Base System Builder's clock_board_config are missing the lines:
PARAMETER radio_clk_out4_mode = 0x1eff
PARAMETER radio_clk_out7_mode = 0x1eff
Can you tell us what these are for? These seem to be the lines that made the difference between a working Receiver and one that gives us jumbled packets (Tx worked before this).
Thanks,
Joshua
Offline
The secondary PLBv46 should have its SYS_Rst port connected to sys_bus_reset; we'll correct this in the next WARPLab design. We fixed it in the OFDM Referene Design (thanks to Gaurav finding it originally). However, we've used both designs without this connected (so SYS_Rst is tied to 0) without any apparent issues.
For the radio_clk_outX_mode parameters, 0x1eff enables the output while 0x01ff disables it. The outputs are labeled as on the corresponding clock buffer (the AD9510's on the clock board). On the clock board, radio_clk_out4 drives J12 and radio_clk_out7 drives J6 (see the users guide and schematics for the details). We usually connect the reference clocks for radios in slots 2 and 3 to J11 and J10 (radio_clk_out5 and radio_clk_out6), then disable the other two (unused) outputs.
The "magic" parameter values are actually values written via SPI to registers in the AD9510. The register address/value pairs are all hard-coded in the Verilog for the clock_board_config core.
Offline