You are not logged in.
Pages: 1
After studying the clock configuration of Rice's reference design V05, we have some questions that listed in the following.
About clock configuration hardware settings:
(1) The FPGA system clock input is changed from AH21 to AT20. However, AH21 (100MHz) is used by the 'fpga_0_clk_board_config_sys_clk_pin' of the pcore clock_board_config. Why this pcore needs a clk signal of 100MHz?
About clock selection for the reference design:
(2) Since the OPB is running at 40MHz, I guess the MIMO signal bandwidth of reference design V05 is 10MHz, right?
(3) PLB:OPB clock rate can be 1:1. So why in all reference designs Rice selects 2:1? Is there any consideration other than meeting FPGA timing constraints?
(4) Why in V05 the Power PC's clock is reduced? Can't you keep it at 200MHz by setting dcm_0's CLKFX to be 5?
About backward compatibility
(5) The R77 is not mounted on the new radio cards. Is it right that, without modifying cards, we can not reverse back to use FPGA clock to drive ADC and DAC?
About UCF difference
(6) There is a new constrain for the RSSI_ADC_D pins, i.e., each pin is added as PULLDOWN. Why?
About version difference
(7) The reference V05 is still using radio_controller_v1_08_a, while the default hardware IP version is now v1_09_a. Is there any hardware and software change we have to pay attention to while creating out own project, or the upgrading is transparent to users?
Thanks
Last edited by zrcao (2007-Aug-01 14:35:18)
Offline
Another question in addition to the ones above:
(8) If we set the speed of the OPB bus at 40Mhz, is it possible to run our pcore at a faster rate (such as 80Mhz)?
Offline
I can answer some of the questions you have.
(1) The clock configuration core requires the 100MHz clock so that the registers on the chip can be written so the correct clock is output to the FPGA. The FPGA now runs off this clock that comes from the clock board through its header.
(5) Yes, designs where the ADC and DACs use the clock from the FPGA cannot be used with the new radio daughtercards without modifying the boards themselves.
(7) The new version of the radio controller only provides more functions such as higher divider values for the SPI core. No major changes from 1.08. Everything from 1.08 should work just fine in 1.09 without changes.
Offline
(1) The FPGA system clock is now sourced by the clock board. But the clock board needs to be configured before it produces this clock. The clock_board_config core uses the free-running 100MHz clock to configure the AD9510's on the clock board. When this process is complete, the clock board's 40MHz signal starts, which feeds the DCM and boots the rest of the FPGA. There is a signal running from the clock_board_config core to the DCM's reset input. This signal is critical- without it, the system won't boot properly when powered on.
(2) Correct
(3) The Ethernet MAC core is attached to the PLB. This core requires a clock faster than 65MHz in order to operate at 100Mbps over the Ethernet interface.
(4) Base System Builder doesn't support that clock ratio. I suppose it would work, but you would have to configure it manually, and adjust any magic numbers in the MHS (the IOCM and DOCM controllers might care about the PPC:PLB clock ratios; I'm not sure).
(5) Correct. The DCM clock outputs have have a lot of jitter, which degrades the SNR realized by the ADC and DAC. The clock board driven 40MHz sampling clock is much better in this regard. This clock has to be terminated with 50ohm resistors on the radios, hence the new resistor configuration.
(6) This isn't strictly required, but is a good idea. These constraints handle the case of building a project with a single radio, our packet detector core and inadvertantly configuring the packet detector to listen to both radios. When the RSSI signals floating, the packet detector can detect RSSI events which aren't real.
(7) You should update any projects using the 1.08a controller to 1.09a (just change the HW_VER paramter in the MHS, and the VER paramter in the MSS). The interfaces and API are identical, but as Sid said above, there were some changes that may be useful in the future.
(8) Not if you created the pcore using sysgen2opb; these cores have a single clock input, which must be the OPB clock. Your best option is to run the OPB at 80MHz, and interpolate/decimate by an extra factor of 2 to maintain the same over-the-air bandwidth.
Offline
Thanks for the replies.
The questions (2), (3) and (8) in fact reflect our wondering that why the Rice reference designs adopt a signal bandwidth in 10 - 12.5 MHz, rather than 20MHz? If there are known issues with 20 MHz, we can also use a signal bandwidth of 10MHz and don't have to waste time on 20MHz.
We figured that, if using a 20MHz signal bandwidth, the OPB pcore is better running at 80MHz, which is somewhat pushing for timing.
Offline
Ease of timing closure is the only reason we're operating at 10MHz bandwidth. The OFDM core could run at 20MHz bandwidth, but it would mean doubling the system clock frequency (from 40 to 80MHz). I haven't tried this with the latest version, but I suspect there may be critical paths in the model that would fail timing without some tweaking. The radio (and ADC and DAC) all support bandwidths up to 40MHz; timing closure in the FPGA is the only constraint.
Offline
We tried clk_PLB=clk_OPB=80MHz on a simple DDS sine wave generator. Chipscope shows that the data are accurately generated before sending to DAC. However, there is no waveform output. We are worried about the radio_controller pcore and radio_bridge pcore. Since OPB is 80MHz, so the radio_controller_0 is running at 80MHz. We set radio_bridge to be running at 80MHz as well.
Now we are building another bit stream with radio_bridge at 40 MHz and radio_controller at 80MHz.
1. Can radio_controller running at 80MHz?
2. Since radio controller and radio_bridge have a lot connections, what is the clock requirement for radio_bridge in view of the connection with radio_controller?
3. Since radio_bridge interfaces with the radio card, what is the limitation on radio_bridge's clock configuration on this front?
===================================
We saw correct frequency and waveform output after set radio_bridge to 40MHz. However, the communication between radio_controller (80Mhz) and radio_bridge (40Mhz) breaks down. We can not change center frequency or change gains through software control. Maybe this this obvious, since these two pcores are running at different clock. Is there any easy way to work around?
Last edited by zrcao (2007-Aug-03 12:40:44)
Offline
The radio controller should be able to synthesize at 80MHz. However the bridge and the controller have to run at the same speed as SPI signals that go through the bridge core will be rendered useless when some data is lost (that is reason that you could not change center frequency for example in your 80MHz/40MHz project). The radio bridge drives out a clock to the radio board for the DAC and ADC. However the ADC can run at a maximum of 65MHz so the clock to that has to be at most 65MHz.
Offline
But the ADC/DAC is driven now by the twisted wire from clock configuration board, rather than the radio bridge.
Offline
There are actually a few issues all mixed together here:
a) The radio controller core has an SPI master which writes registers in both the MAX2829 and AD9777. The SPI interface has its own clock, which the radio controller synthesizes by dividing down the OPB clock. The SPI clock frequency is set using the function WarpRadio_v1_clkRatio(c) where c is an integer in [1,15]. For an OPB clock of 40 or 50 MHz, the default clkRatio value works (set to 1 in radio_prototypes.c). For an 80MHz OPB clock, you need to set the clock ratio to 2 (i.e. call WarpRadio_v1_clkRatio(2) before calling WarpRadio_v1_Reset() ). Without this, the SPI clock will be too fast, which means no software register write commands to the radio or DAC will work (hence not being able to set gains, center frequencies, etc.).
b) The radio bridge core has a clock input (converter_clock_in) that must be connected to the same clock used by the ADC/DACs. The bridge contains a bank of registers (which are eventually packed into the IOBs) that register the data and control busses going to the radio board. If you run the OPB at 80MHz, you still need to connect the bridge's converter_clock_in port to the 40MHz port (the CLK0 output) of the DCM.
c) If you run the OPB at 80MHz, it's a good idea to design your sysgen core with ADC/DAC gateways running at 40MHz (or 2x the system sample period). In other words, with sample time colors turned on, the OPB interface should be red and the ADC/DAC gateays (and related blocks) should be green. This way, the sysgen ports (running at 40) connect to the radio bridge ports (also running at 40, if you hook up converter_clock_in correctly), which drive the radio board's converters (also running at 40, via the twisted pair cable). You should build into your sysgen core whatever interpolation/decimation filters you need to achieve the over-the-air bandwidth you want to see.
Offline
Pages: 1