mjelahi
Joined: 08 Feb 2009
Posts: 8
|
 08 Feb 2009 23:25 oddr xilinx |
|
|
|
|
I have got Verilog code for a design that has been implemented on
Virtex-4. My target is take this design to an ASIC implementation. The
issues that I am having right now are related to porting an FPGA based
design to an ASIC. When I read this design into Cadence synthesis
tools, I get few unresolved references for IDELAYCTRL, ODDR, BUFG,
BUFR, BUFIO, BUFGMUX_VIRTEX4. These modules are placed in the design
as follows:
IDELAYCTRL - connected to DCM
ODDR - connected to DCM
BUFG - connected to DCM
BUFR - connected to SERDES
BUFIO - connected to SERDES
BUFGMUX_VIRTEX4 - connected to DCM
It seems that these modules as xilinx specific and are automatically
instantiated in the verilog code when DCM and SERDES components were
configured using xilinx tools. Can you please kindly guide on what
should I do about these componets as there is no code for these
modules in my code directory? Has anyone else experienced this sort of
issue before when moving an FPGA-based implementation to an ASIC?
Added after 1 minutes:
I have spend some time looking into the verilog code and xilinx virtex 4
documentation. Following are my findings and some related questions:
1)- BUFG
Simple clock in, clock out buffer. It seems that I can remove it for
the ASIC implementation as CTS can implement this itself.
2)- BUFIO
Simple clock in, clock out buffer. It seems that it can remove this
one too for the ASIC implementation without changing the functional
behavior and let CTS take care of it.
3)- ODDR
Double data rate register. But in the verilog code that I have, it is
just being used to forward a copy of the clock to the output (this
information can be verified in ug070.pdf - page 324). Note that ODDR
has been specifically configured such that D1 input is fixed to 1'b1
and D2 input is fixed to 1'b0. According to the documentation, xilinx
recommends using this scheme to forward clocks from the FPGA fabric to
the output pins.
Now, there are two questions that are disturbing me right now in
regards to ODDR. Firstly, what is the reason that xilinx recommend
using this scheme and what is the advantage to this approach?
Secondly, can somebody tell me if I need this ODDR for my ASIC
implementation (for forwarding clock to the output)?
4)- BUFR
Clock-in/clock-out buffer with the capability to divide the input
clock frequency. In my case, this buffer is just dividing the clock
frequency by two. The CE input pin is fixed to 1'b1 and CLR input pin
is open.
Now, my question is that what is the easiest and most efficient to
replace this for ASIC implementation? Can I just use a counter based
approach to divide the frequency by two or should I insert another DCM
for this one or is there any better way to solve this issue?
5)- BUFMUX_VIRTEX4
A clock buffer with two clock inputs, one clock output, and a select
line, which means that it is essentially a clock multiplexer. Note
that both the clocks are a factor of one another in this case (i.e.
clk1 is 200 MHz and clk2 is 400 MHz).
For this one, I can use a simple mux but it will cause glitches at the
output at the instant when the 'select line' changes. I found a good
resource on the web
(http://www.design-reuse.com/articles/5827/techniques-to-make-clock-
switching-glitch-free.html),
which present a technique to implement glitch free clock mux but I am
not sure if this the
recommended way to solve this problem. So, any guidance on this one is
highly appreciated.
6)- IDELAYCTRL
Unfortunately, I don't completely understand the purpose of this
module. In the documentation (ug070.pdf - you can easily find this doc
by just searching for it on google), the following is stated:
The IDELAYCTRL module provides a voltage bias, independent of process,
voltage, and temperature variations to the tap-delay line using a
fixed-frequency reference clock, REFCLK. This enables very acccurate
delay tuning.
But how exactly? This just keeps disturbing me as the description is
so limited in the documentation. Note that the output pin (RDY) is
left open in my case. The documentation also says that the
implementation tools allow RDY to be unconnected/ignored.
RDY - Ready
The ready (RDY) signal indicates when the IDELAY modules in the
specific region are calibrated. The RDY signal is deasserted if REFCLK
is held High or Low for one clock period or more. If RDY is deasserted
Low, the IDELAYCTRL module must be reset. The implementation tools
allow RDY to be unconnected/ignored.
But this just does not make sense to me. What the use of a module
whose
sole output is just left open? Or how can this module perform
calibration with an unconnected RDY port? Lastly, do you think if I
need this module for my ASIC implementation?
Any feedback is highly appreciated.
|
|
rberek
Joined: 23 May 2007
Posts: 65
Helped: 9
Location: Canada
|
09 Feb 2009 19:03 from fpga to asic |
|
|
|
|
It's hard to give advice to you, because which I/O and clocking features to choose is totally dependent on what is in your ASIC vendor's libraries. I know its not much of an answer, but you'll need to look at what your vendor offers, compare that functionality to what Xilinx provides, and make a choice.
I can't answer every one of your questions without reviewing the Xilinx I/O databook, but you often use a DDR pad for output clocks, because it forces clock tree to logic signal transition to occur at the I/O PAD and guarantees there is no timing delay to the PAD.
It sounds like you're currently using the Xilinx SERDES core. I think that is going to be the bigger issue when moving to an ASIC, as the SERDES hard macro won't be available at all in the new technology, and you'll have to modify your design to use the ASIC vendors SERDES core.
r.b.
|
|
